What each server is, and who stands behind it#
The GitLab entry is published under the registry name com.gitlab/mcp by gitlab.com, described by its publisher as "Official GitLab MCP Server", at declared version 0.0.1. The record carries no website URL. Its namespace com.gitlab resolves to the claimed domain gitlab.com at tier verified-domain, and the endpoint host, gitlab.com, sits inside that same domain.
The Linear entry is app.linear/linear, published by linear.app, described as "MCP server for Linear project management and issue tracking", at declared version 1.0.1, with a website URL of https://linear.app. Its namespace app.linear resolves to linear.app, also at tier verified-domain, and its endpoint host mcp.linear.app is within linear.app.
Both are classified vendor-verified in the category collaboration-and-productivity. Both hold a curation score of 80 in the published bucket, and in both records the score comes from the same three components: +50 for the verified domain, +15 for probe.reachable on the evidence "endpoint returned a definitive response (auth-required)", and +15 for probe.spec_auth_chain on the evidence "publishes OAuth discovery metadata or a well-formed initialize result". Neither carries a bulk flag or an ineligibility reason.
This matters more than it looks. The headline score does not separate these two servers at all. If you are trying to choose between them, the curation number gives you nothing; the scope list does. The version strings are worth noting as declarations rather than as judgements — 0.0.1 and 1.0.1 are what the publishers chose to declare, and nothing in either record attaches a stability or support commitment to either number.
Authorisation: what our probe actually saw#
Both servers require credentials. For each, the claim auth.required is tier observed — that is our own unauthenticated probe on 19 September 2026, not a publisher statement. The recorded excerpts are identical in wording: "POST initialize without credentials -> HTTP 401", against https://gitlab.com/api/v4/mcp at 17:17:12Z and against https://mcp.linear.app/mcp at 17:17:08Z.
Both records show all four discovery compliance bits set. wwwAuth, prm, as and dcr are true for both. GitLab publishes protected-resource metadata at https://gitlab.com/.well-known/oauth-protected-resource/api/v4/mcp (HTTP 200); Linear publishes it at https://mcp.linear.app/.well-known/oauth-protected-resource/mcp (HTTP 200).
Both also advertise dynamic client registration, recorded as auth.dcr supported, tier observed. GitLab's authorization-server metadata gives "registration_endpoint": "https://gitlab.com/oauth/register"; Linear's gives "registration_endpoint": "https://mcp.linear.app/register". A registration endpoint is what a compliant MCP client uses to obtain its own client credentials programmatically, rather than waiting for an OAuth application to be hand-provisioned. Neither record says anything about what the authorisation step itself requires, so treat the gate on who may connect as a question for the vendor rather than something this evidence settles.
So on the authentication signals we captured the two are level. There is nothing here that would let you tell a reviewer one is more rigorously gated than the other.
Scope granularity: one scope versus two#
This is the real difference, and it is small in the data and large in consequence.
GitLab's protected-resource metadata declares, verbatim: "scopes_supported": ["mcp"]. One scope. Our record therefore sets auth.scope_separation to unsupported, with the observed excerpt: "scopes_supported is [\"mcp\"] -- no separate read-only scope is offered".
Linear's declares, verbatim: "scopes_supported": ["read","write"]. Our record sets auth.scope_separation to supported, with the excerpt: "scopes_supported enumerates both read and write: [\"read\",\"write\"]". Both of these are tier observed — read off the live metadata documents, not taken from anyone's marketing page.
The practical consequence for an evaluator: GitLab's metadata advertises no scope narrower than mcp, so at the scope layer the published evidence offers you nothing to narrow. Any narrowing you want has to be sought elsewhere — most obviously in the permissions of the account whose consent you use, or in which tools the client is configured to surface. Linear's metadata does advertise a read scope distinct from write, so there is at least a documented basis for requesting a read-only grant for a summarising or triage assistant and keeping write for a separate, deliberately narrower integration.
Two caveats, both important. First, we read the advertised scope list; we did not mint a read-only token and attempt a write. Advertised separation is not tested enforcement, and nothing in our evidence states what either scope permits. Second, toolNames is null in both probe records — no tool list was captured from an unauthenticated probe — so neither record tells you which operations sit behind write, or what the single mcp scope reaches once granted.
For a food or CPG organisation the distinction is worth the attention. A development tracker can hold supplier names, formulation change requests, retailer launch dates and QA incident threads, and the names read and write are the only published signal either record gives you about the shape of a grant over that content. Of these two servers, only Linear's metadata advertises the scopes that would let you attempt that line at the token — subject to the caveats above.
Deployment and where the traffic goes#
Both records declare exactly one remote — deploy.hosted_remote is supported for both on the excerpt "1 remote endpoint(s) declared" — and both are type streamable-http. GitLab's is https://gitlab.com/api/v4/mcp on host gitlab.com. Linear's is https://mcp.linear.app/mcp on host mcp.linear.app. For both, transport.sse is recorded as unsupported, tier registry, on the evidence "no sse remote declared" — so a client that speaks only SSE is not covered by either declaration.
Neither declares an installable package. Both packages arrays are empty, and deploy.self_host is unsupported for both on the evidence "no installable package declared". There is no artefact in either record that you could run inside your own network. Whichever you choose, the assistant's tool traffic on the declared endpoint leaves your perimeter and terminates on the vendor's host.
The hostnames differ in a way that affects your network team. Linear's endpoint is on mcp.linear.app, a different host from linear.app, the website URL in its record. An egress rule written for one hostname will not cover the other, and MCP traffic to Linear can therefore be allowed, logged and rate-limited as its own destination.
GitLab's endpoint is a path, /api/v4/mcp, on gitlab.com — the same host as the rest of that record's claimed domain. So it adds no hostname beyond gitlab.com, and by the same token MCP traffic to GitLab is not separable from other traffic to gitlab.com at the hostname level. If your control story depends on isolating assistant traffic at the network edge, the Linear record suits it better; if it depends on adding no new egress destination, the GitLab record does.
One thing the GitLab record does not settle: the single declared remote is on gitlab.com. If your GitLab runs on your own infrastructure, this record says nothing about whether the same /api/v4/mcp path exists there. That is a question for GitLab, not something to infer from here.
Source availability#
GitLab declares a repository. The claim repo.public is supported, tier registry — the publisher's own declaration in its registry record — with the evidence https://gitlab.com/gitlab-org/gitlab. Note what that URL is: the gitlab-org/gitlab project, not a repository dedicated to the MCP server. The record does not say where within that project the server code sits, so if your review process involves reading the connector's code, you have a starting point and a locating problem.
Linear declares none. Its repository field is null and repo.public is recorded as unsupported, tier registry, on the evidence "no repository declared in the registry record". Read that precisely: the registry record points at no source. That is not a statement that no source exists anywhere, and it is certainly not a statement about code quality. It means an evaluator working from the published record has nothing to open.
For both servers, repo.license and repo.maintained are unknown, and the recorded reason is never_attempted — this build did not run those checks. That gap is ours, not the publishers'. Do not read it as either publisher withholding a licence. pkg.deprecated is likewise unknown with reason never_attempted, and with no packages declared by either there is nothing there to check in any case.
So on source availability the honest summary is: GitLab's record gives you a repository URL, Linear's gives you none, and neither record states a licence for either — because we did not check, not because no licence exists. If code review is a hard gate in your procurement process, the difference in what is published is a real one to weigh alongside the scope difference above.
What neither of them documents#
Four control claims are identical and empty across both records: controls.audit_logging, controls.access_control, controls.data_residency and controls.retention. All four are unknown on both servers, and in every case the recorded reason is not_documented. That means we found no publisher statement to cite. It does not mean the control is missing — a vendor may well have retention and residency commitments that simply are not surfaced in the MCP registry record or the discovery metadata we read.
secrets.declared is unknown for both, with reason never_attempted. And as noted, toolNames is null in both probe records, so this page cannot tell you what either server can do once connected.
Add these up and the position is this: the questions a security reviewer at a food manufacturer will ask first — where is this processed, how long is prompt and issue content retained, who inside our organisation is allowed to grant this, and is the grant logged — are answered by neither record. Ask the vendor in writing and keep the answer. A directory records what is published; this is not published.
The one lever the evidence does hand you is the authorisation layer itself. Both servers require authentication, and both publish a complete OAuth discovery chain, so the identity you authorise with is where the published evidence puts the boundary — which is precisely why GitLab's single mcp scope leaves more of that boundary resting on account permissions than Linear's advertised read/write split does.
Finally, currency. Every claim here was verified on 19 September 2026. Protected-resource metadata is a live document and can change without a release note. Re-read both .well-known endpoints before you go to production, and in particular re-check whether GitLab has since added a second scope.