The two servers, and who stands behind them#
The Atlassian Rovo MCP Server is registered as com.atlassian/atlassian-mcp-server by atlassian.com, at version 2.0.0. Atlassian's own description is: "Connect to Atlassian Jira, Confluence, Loom, and more to search, create, and manage your work." Worth noting for anyone scoping a project: the description names Jira, Confluence and Loom, while the scope list the server publishes names Jira, Confluence and Compass, plus two scopes -- read:all:twg and write:all:twg -- whose product is not expanded anywhere in the metadata we read.
The Notion server is registered as com.notion/mcp by notion.com, at version 1.0.1, with the one-line description "Official Notion MCP server". The registry record carries no website URL and no repository.
Both are classed vendor-verified, and both clear the namespace check on the same basis: com.atlassian maps to atlassian.com with the host mcp.atlassian.com inside that domain, and com.notion maps to notion.com with mcp.notion.com inside it.
Their curation scores differ -- 100 for Atlassian, 80 for Notion -- and it is worth seeing where the gap comes from, because it is not about runtime behaviour. Both earn exactly the same three components: verified domain (+50), reachable endpoint (+15), and a well-formed spec auth chain (+15). Atlassian adds two more, both tied to the repository its record declares: an OSI licence, Apache-2.0 (+10), and a release three days before the check (+10). Notion's record declares no repository, so neither repository component can be scored for it. The 20-point difference is a difference in what the record points at, not in how the two servers responded to us.
Authentication: the same handshake, very different grants#
On the authentication mechanics the two records are near-identical. Each returned HTTP 401 to an unauthenticated initialize -- Atlassian at 17:17:09 UTC and Notion at 17:17:16 UTC on 19 September 2026 -- a definitive auth-required response, which is why both earn the reachable component rather than counting as unresponsive. Both publish OAuth protected resource metadata, both publish authorization server metadata, both send a WWW-Authenticate header, and both expose a dynamic client registration endpoint: https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3/dcr/register for Atlassian, https://mcp.notion.com/register for Notion. All four compliance bits are true on both sides. Every one of these findings is tier observed -- our own unauthenticated probe, not a vendor claim.
Then the two diverge sharply. Atlassian's protected resource metadata advertises 22 scopes, quoted here verbatim: 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.
Grouped: four identity and session scopes, two for Jira, eight for Confluence, six for Compass, and two unexpanded. Six of the 22 begin with write:.
Notion's protected resource metadata advertises one scope, quoted verbatim: default.
Our recorded evidence for Notion's scope separation is blunt about what that implies: "scopes_supported is [\"default\"] -- no separate read-only scope is offered".
What a read-only grant actually buys you#
This is the part that matters when the assistant is pointed at a knowledge base rather than a scratchpad. Confluence and Notion spaces in a food business hold the documents that people are careful with: allergen changeover procedures, supplier approval runbooks, specification histories, the notes behind a label claim. The question a reviewer asks is not "can the assistant find this?" but "could the assistant have changed it?"
With Atlassian, the grant itself can carry that distinction. A token request can include search:confluence, read:space:confluence, read:page:confluence, read:comment:confluence, read:hierarchical-content:confluence and read:confluence-user, and leave out write:page:confluence and write:comment:confluence. The distinction lives in the credential rather than in prompt design or tool configuration, which is what makes it something a reviewer can inspect. Be clear about the limit of our evidence: we read the published metadata from an unauthenticated probe and never held a token, so we can report what the grant can express, not what the server does when presented with one.
With Notion, a single default scope means the OAuth layer does not express that distinction. The consent flow cannot offer "read but not write", and the resulting token does not carry the difference. Be precise about what this is and is not: it is not evidence that the Notion server writes to everything, and it is not a shortcoming in how the server implements OAuth, which is otherwise complete on all four compliance bits. It means that if you want the grant to state a read-only limit, it will not, and you have to establish what else constrains the integration -- which is a conversation with Notion, not something this page's evidence settles.
Two practical qualifications on the Atlassian side. First, granularity is something on offer, not a default: the server advertises 22 scopes, but your MCP client decides which ones it asks for. A client that requests everything on offer produces a broad token regardless. Check the scopes your client actually requests before you assume you have least privilege. Second, the breadth cuts both ways. The same list reaches Jira and Compass, so a connection made for Confluence still puts Jira and Compass scopes in front of whoever approves the grant. You can narrow it -- but only if someone does the narrowing.
Transport, hosting, and where the content goes#
Neither server can be run inside your own network on this evidence. Both registry records declare an empty package list, both resolve to self-hosting unsupported with the same evidence -- "no installable package declared" -- and both are hosted remotes operated by the vendor.
Atlassian declares two endpoints, both streamable HTTP: https://mcp.atlassian.com/v1/mcp/authv2 and https://mcp.atlassian.com/v2/mcp. SSE is recorded as unsupported at registry tier, on the evidence "no sse remote declared". Notion declares two as well, but of different types: https://mcp.notion.com/mcp over streamable HTTP and https://mcp.notion.com/sse over SSE. If you are working with an older client that only speaks SSE, Notion's record declares an endpoint for it and Atlassian's declares none. If you are pinning a client to Atlassian, record which of the two versioned endpoints you pointed it at, because both are declared in the record and they are not the same URL.
For egress control, the MCP endpoints sit on one hostname each: mcp.atlassian.com or mcp.notion.com. Do not stop there on the Atlassian side -- its authorization server metadata puts dynamic client registration on a separate host, auth.atlassian.com, so an allowlist covering only mcp.atlassian.com would not cover the OAuth chain our probe observed. In both cases the content the assistant retrieves leaves your network to a vendor-operated endpoint. What happens to it there -- where it is held, for how long, and what is logged about it -- is not documented for either server, which is the subject of the next section.
What neither server documents#
Four control claims resolve to unknown for both servers, each with the recorded reason not documented: audit logging, access control, data residency and retention. Unknown here means we found nothing to cite in the sources we check. It does not mean the control is absent. Both vendors may well operate all four at product level. The consequence for you is narrower and quite specific: if a customer audit asks what the MCP connector logs or where it holds data, neither server's record gives you a citable answer, and you will be working from the vendor's general compliance documentation instead.
Two more claims are unknown for both with a different recorded reason -- never attempted rather than not documented. Declared secrets and package deprecation are package-level questions, and neither record declares a package.
Neither page here can show you a tool inventory. Our probe stops at the 401, so the tool list is null for both and the tool count is null in the catalogue. The scope lists are the nearest proxy we have for what each server reaches, which is why the contrast matters: Atlassian's 22 scopes name products and verbs, and Notion's single default names neither.
One asymmetry left. Atlassian's record points at source at https://github.com/atlassian/atlassian-mcp-server, licensed Apache-2.0, last pushed three days before our check. Notion's registry record declares no repository, so licence and maintenance activity are both unknown and the record gives your security team no source to start from. If code review of the connector is part of how you approve integrations, that is a real difference in what the record lets you do.