What each server is, and what our evidence covers#
Both are first-party connectors. The Atlassian Rovo MCP Server is published under the registry name com.atlassian/atlassian-mcp-server by atlassian.com at version 2.0.0, described in the registry as "Connect to Atlassian Jira, Confluence, Loom, and more to search, create, and manage your work." Linear is published under app.linear/linear by linear.app at version 1.0.1, described as "MCP server for Linear project management and issue tracking". Both carry a maintainer type of vendor-verified and a verified-domain namespace: the publishing namespace matches the claimed domain, and the serving host sits inside it in each case.
Our curation scores are 100 for Atlassian and 80 for Linear, and it is worth being precise about where that 20-point gap comes from, because it is not about runtime behaviour. Both servers scored identically on the three rules that describe how the endpoint actually behaves: verified domain (+50), reachable with a definitive response (+15), and a well-formed spec auth chain (+15). Atlassian's additional 20 points come entirely from two repository-derived rules: an OSI licence (Apache-2.0, +10) and a recent release (+10, "release 3 days ago" at the time of the 19 September 2026 build).
Linear's registry record declares no repository, so repo.public resolves as unsupported on the evidence "no repository declared in the registry record", and both repo.license and repo.maintained are unknown because we never had a repository to attempt them against. Read that as an absence of source transparency in the registry record, not as evidence about the quality or upkeep of the service, and not as a finding that no source exists elsewhere. An evaluator who cares about reading the connector's code has a declared repository in one case and none declared in the other; an evaluator who only cares about how the endpoint behaves under authentication has two servers that measured the same.
One boundary on the Atlassian evidence matters later. The registry declares two remote endpoints, https://mcp.atlassian.com/v1/mcp/authv2 and https://mcp.atlassian.com/v2/mcp. Every observed claim below, including the scope list, came from a probe of the first. We did not independently observe the second.
The scope lists, verbatim#
This is the substance of the comparison, so here are both lists exactly as our probes read them from each server's Protected Resource Metadata on 19 September 2026.
Atlassian advertises 22 scopes: read:me, read:account, offline_access, email, read:jira-work, write:jira-work, search:confluence, read:confluence-user, read:page:confluence, write:page:confluence, read:comment:confluence, write:comment:confluence, read:space:confluence, read:hierarchical-content:confluence, write:component:compass, read:component:compass, read:scorecard:compass, write:scorecard:compass, read:event:compass, read:metric:compass, read:all:twg, write:all:twg.
Linear advertises two: read, write.
Both resolve auth.scope_separation as supported, meaning read and write are enumerated separately in each list. That is the headline both vendors can claim, and it is true of both. It is also where the similarity ends.
Group the Atlassian list by the product suffix in each scope name and the shape becomes clear. Four carry no product suffix and name identity or session concerns (read:me, read:account, email, offline_access). Two cover Jira. Eight cover Confluence. Six cover Compass. Two are read:all:twg and write:all:twg, which are all-shaped and which our record does not expand or map to a named product.
The granularity is therefore uneven, and unevenly distributed against this particular decision. Confluence is decomposed to the object level: pages, comments, spaces and hierarchical content each have their own scope, and search is named separately from retrieval via search:confluence. Jira is not decomposed at all. It is read:jira-work and write:jira-work, and nothing else. No per-project, per-board or per-issue-type scope is advertised, and no Jira equivalent of search:confluence appears.
So for the narrow question of reading issues, Atlassian's advertised read grant is exactly as coarse as Linear's: one scope, with no narrower dimension advertised beneath it. Twenty-two scopes buys you nothing inside Jira. What it buys you is a way to name what sits outside it.
What a read grant actually asks for#
The useful question when delegating access to an agent is not only what a token can do but what the grant declines to ask for. On that measure the two advertised lists differ sharply, and not in the direction the raw scope counts suggest.
With Atlassian, a token carrying read:jira-work plus the identity scopes it needs, and none of the Confluence or Compass scopes, is a grant that requests no Confluence or Compass access. What we observed is the advertised list, not the enforcement: our probe was unauthenticated, so we hold no evidence of what the server does with a token whose scopes are omitted. Subject to confirming that in a pilot, the practical value is that the intent can be written into the grant. For a food, beverage or CPG organisation the Jira/Confluence line is usually the one that matters. Jira tends to hold work items; Confluence tends to hold the documents attached to that work — supplier terms, specification and formulation pages, incident write-ups, contract summaries. Expressing "keep the agent out of that material" as a scope string, rather than as a policy note, is the concrete governance benefit of Atlassian's list. It is also the reason to read the list carefully rather than accept a client's default consent screen.
The two twg scopes deserve attention for the same reason. read:all:twg and write:all:twg use the all form, and our record carries no expansion of the abbreviation and no mapping to a product surface. An all scope you cannot map to a system is exactly the sort of thing to resolve with the vendor before it appears on a consent screen your engineers will click through.
With Linear, the same delegation is read. The advertised list has no axis beneath it — no per-team, per-project or per-object scope appears. Whether that matters depends entirely on what your Linear workspace contains. Where the workspace is the issue tracker and nothing else, the material behind a single read scope may be narrower than what a broadly granted Atlassian token reaches; which is the smaller real surface depends on what each system holds, not on the scope counts. Where Linear is also used for planning documents, customer escalations or anything commercially sensitive, read offers no advertised way to carve that out.
One asymmetry worth noting in passing: offline_access appears in Atlassian's advertised list and not in Linear's. Our record lists the scope name and does not expand what it grants. Its absence from Linear's list does not mean Linear lacks long-lived sessions — only that no such scope is advertised and the mechanism is not documented in our record.
Both cases share a limit that no scope string resolves on the evidence we hold. The advertised list describes what a token can ask for. Neither record documents what the server then allows, nor how a grant interacts with the permissions of the account that authorises it. Neither server documents server-side access control — both resolve controls.access_control as unknown for want of documentation — so we cannot tell you whether an admin can constrain the connector beyond the grant. Delegating through a purpose-made service identity with deliberately narrow product permissions is the prudent plan on both, and it is something to establish in a pilot rather than assume.
Hosting, transport and where traffic goes#
Neither server can be run inside your own network on the evidence available. Both resolve deploy.self_host as unsupported with the registry evidence "no installable package declared", and both have an empty packages array. Both resolve deploy.hosted_remote as supported: two endpoints for Atlassian (https://mcp.atlassian.com/v1/mcp/authv2 and https://mcp.atlassian.com/v2/mcp), one for Linear (https://mcp.linear.app/mcp). Every request and every response crosses the perimeter to a vendor-operated host in both cases.
Transport is the same on both: streamable HTTP supported, SSE resolved as unsupported on the registry evidence "no sse remote declared". A client that speaks only SSE has no declared endpoint to connect to in either case.
The authentication chain is complete on both. Each probe recorded all four compliance bits as present — WWW-Authenticate challenge, Protected Resource Metadata, authorisation server metadata, and dynamic client registration. A standards-compliant client has the discovery metadata it needs to complete authentication against either without hand-configured endpoints. That is a modest but real operational positive, and it is the part of each service our evidence is strongest on, because we observed it directly rather than reading it from a registry declaration.
The registration endpoints differ in a way that shows up in firewall rules. Atlassian's is https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3/dcr/register — a different host from the resource server, so an egress allow-list needs both mcp.atlassian.com and auth.atlassian.com. Linear's is https://mcp.linear.app/register, the same host as the resource, so one entry covers it.
Both records resolve auth.dcr as supported because each authorisation server advertises a registration endpoint. We read that metadata; we did not attempt a registration, so whether registration is open to any client or gated by the vendor is not something our evidence settles. If your standard for connector adoption assumes an administrator gates OAuth client creation, put that question to both vendors rather than treating the published endpoint as an answer either way.
What neither vendor documents#
Four control questions come back unknown for both servers, each with the reason recorded as not documented: controls.audit_logging, controls.access_control, controls.data_residency and controls.retention. Unknown here means undocumented in the sources we check. It is not a finding that these controls are missing, and it should not be written up internally as one.
It is, however, a finding about procurement. Both connectors are hosted-only, so residency and retention are decided by the vendor and are not observable from outside. If your organisation operates under EU data residency commitments, or has a retention position it has to evidence to auditors, those four answers have to come from Atlassian and Linear in writing. They are the right questions to put into a security review, and neither server's public record answers them.
secrets.declared and pkg.deprecated are also unknown for both, with the reason recorded as never attempted, and neither server declares a package that could have been examined.
Both probes also returned toolNames as null. Each server answered an unauthenticated initialize with HTTP 401, which earns both the reachability and auth-chain credit, but it means our probe never saw a tool list. Neither the number of tools nor their names is evidence we hold for either server. Any claim you encounter about what these connectors can do at the tool level did not come from an unauthenticated observation, and a short authenticated pilot in a sandbox is the only reliable way to establish it.
For Linear specifically, the absence of a declared repository propagates: licence and maintenance recency are both unknown because no repository was declared for us to check. For Atlassian, the repository is public at github.com/atlassian/atlassian-mcp-server under Apache-2.0, with a last push three days before our 19 September 2026 build.