Which Documentation Platforms Host MCP Servers Out of the Box

This piece compares something narrow and specific: documentation platforms that run a vendor-hosted MCP endpoint a user can connect to immediately, against every other flavor of MCP integration that asks for a binary, a local process, or a self-hosted server before an agent can read a single page. A vendor-hosted endpoint means the company itself keeps a server running at a public URL, handles the authentication flow, and takes on the job of keeping that server up, patched, and reachable. The Model Context Protocol's March 2025 spec revision (2025-03-26) introduced Streamable HTTP and replaced the older SSE transport, and that change is what let vendors build a server once so any compliant client could connect to it over the network instead of spawning it locally; none of this was possible at scale before then. Because that transport question is now settled across the ecosystem, and because clients like Claude, Cursor, and others speak the same protocol regardless of which platform sits on the other end, the thing that actually separates one platform's offering from another's is no longer how an agent connects. It's what the vendor decided to put on the server, and the sections that follow map exactly that.

Evaluating a Hosted MCP Endpoint

Judging a hosted MCP endpoint comes down to five questions, and the answers to those questions are what the platform sections below actually compare. Transport is the first and most basic: Streamable HTTP is the current standard for a remote connection, and a platform still shipping only the older stdio transport is asking a user to run something locally, which defeats the point of calling an integration "hosted. Tool surface is the second: what operations can the agent actually call, read, search, create, update, delete, and which of those a vendor chose to leave out. Scope constraints matter just as much: does the hosted server expose the full platform API, or has the vendor drawn a line around a subset, limiting access to certain content types or certain deployment tiers. Authentication model decides whether the endpoint fits the workflow a team actually needs, since OAuth suits a human sitting at a keyboard but says nothing about an unattended pipeline. And deprecation posture rounds out the picture: whether a vendor is actively steering users away from a self-hosted alternative toward the hosted path, or running both in parallel indefinitely. You can read each platform below through these same five lenses, in order.

Notion's hosted MCP: tool surface and gaps

Notion's hosted MCP server operates at the page level and ships with a fixed set of tools, and it leaves out block-level REST API endpoints: GET, PATCH, and DELETE calls against /blocks/{block_id} are simply absent from the hosted surface. An agent connected to the hosted server can read and work with pages, but it cannot reach into a document and manipulate individual blocks the way Notion's own REST API allows. That capability still exists in the self-hosted, open-source Notion MCP server, which ships a larger tool set that includes those block-level endpoints and accepts Integration Token authentication. Notion has soft-deprecated that self-hosted server anyway, describing the hosted remote server as the one receiving active support and ongoing improvement, which tells a reader something about Notion's intent for the product's direction. Notion built block-level editing into the server it now discourages people from using, so it can expose that capability remotely if it wants to; it likely chose otherwise because of token cost and context size, since block-level editing tends to load far more granular content into an agent's context window than page-level operations do. The hosted path also closes a door for a specific kind of workflow: it requires OAuth and gives no way to authenticate with a bearer token, so any pipeline meant to run unattended, without a human present to click through an authorization screen, cannot use it and has to fall back to the local server Notion is actively trying to retire. On top of the tool and auth questions, the hosted server inherits Notion's standard API rate limits, which matters directly for any agent workflow that calls it frequently.

Atlassian's Rovo MCP: broad platform coverage with a hard Cloud boundary

Atlassian took a different approach to scope than Notion did: rather than narrowing the tool surface, it built one of the broadest hosted MCP endpoints among any documentation-adjacent platform. The v2 endpoint reached general availability on September 8, 2026, and from a single OAuth 2.1 connection at mcp.atlassian.com, it reaches across Jira, Confluence, Jira Service Management, Bitbucket Cloud, Compass, Loom, Goals, Projects, Teams, Focus, and Talent. Teams still running the earlier v1/SSE endpoint had a hard deadline to deal with: Atlassian announced that transport as no longer supported after June 30, 2026, so a team had to migrate onto the newer transport whether or not it was ready. Authentication runs through OAuth 2.1 or an API token, and the server itself is built on Cloudflare's Agents SDK, which supplied the OAuth handling, the Streamable HTTP transport, and the serving layer.

The constraint that actually matters here is the deployment model, not the tool surface, which is generous: the official Atlassian server only works against Atlassian Cloud, and there is no path to authorize it against Confluence Server or Confluence Data Center. An enterprise running an on-premises Atlassian instance cannot point this server at it, full stop on the mechanism, not on the willingness. Connecting to the hosted server costs nothing extra for a team already on Atlassian Cloud, but that Cloud-only boundary isn't a temporary rollout gap waiting to be filled in a future release. It reflects a structural choice about what the hosted architecture is built to reach, and it's the detail that reappears later in this piece when the conversation turns to when self-hosting a server actually becomes the right call.

Other platforms with vendor-hosted MCP endpoints: Cosmic, Box, and Context7

Beyond Notion and Atlassian, three other platforms meet the same out-of-the-box bar established above, and each one serves a different kind of workflow. Cosmic, a headless CMS, runs a hosted MCP endpoint where a user passes bucket credentials as headers and the agent gets full content access without any deployment step on the user's end; it's built for teams managing structured content in a headless system. Box runs its own hosted endpoint that lets an agent search and work with files over OAuth without the user ever handling raw file payloads directly, and it already supports connections from Anthropic's Claude, Microsoft Copilot Studio, Microsoft Azure API Center, and Mistral's Le Chat; Box has deprecated the community-built self-hosted server that used to fill this role, mirroring the pattern seen with Notion. Context7, built by Upstash, is the dominant hosted endpoint for feeding library reference documentation to coding agents, maintaining a registry of tens of thousands of libraries that includes Next.js, React, MongoDB, Supabase, Django, and FastAPI, and delivering version-specific documentation. Setup runs through a single command, npx ctx7 setup, which handles OAuth authentication, generates an API key, and walks through interactive client configuration in one pass.

One detail about Context7 points toward a cost that runs through the rest of this piece: in January 2026, the company sharply cut its free tier request allowance.

Content Quality, Reliability, and Headless Auth

Every platform covered so far solves the same problem: a developer no longer needs to run a binary, manage a local process, or stand up infrastructure to get an agent talking to Notion, Atlassian, Cosmic, Box, or a library's documentation. That's a real and substantial improvement in setup friction, and it shouldn't be understated. But setup friction is only one of three things that determine whether an agent-powered workflow holds up in production, and the other two, content quality and endpoint reliability, sit entirely outside what a hosted endpoint can touch.

Content quality is invisible at the MCP layer. A Confluence MCP server, hosted or not, will hand an agent a stale runbook, a duplicate page, or a superseded spec with exactly the same confidence it hands over the current, accurate version. The server has no editorial judgment built into it, and no architecture decision, hosted or self-hosted, changes that fact. The server has no mechanism to flag one document over another, so the agent treats every document it returns as equally trustworthy.

Endpoint reliability raises a related but separate concern across the broader remote MCP ecosystem. Vendor-operated servers for major platforms like the ones covered here sidestep the worst of this simply by being professionally run and maintained, but the wider pattern across community-built servers is a reminder that "hosted" by itself promises nothing about uptime or stability. A server being reachable at a public URL says only that someone is running it, not that it's being run well.

And headless authentication remains a gap the hosted model, as it stands, has not closed. Notion's hosted server requires a human to click through an OAuth flow and offers no bearer token option, so a team building a fully automated, unattended pipeline cannot use that hosted path at all and has to drop back to a local or self-hosted variant, even one the vendor is actively trying to retire. That tension, between the vendor's push toward hosted infrastructure and the operational reality of unattended agents, doesn't resolve cleanly in 2026.

Self-Hosted MCP: When It's the Right Answer

None of this is an argument against hosted MCP. It's an argument for recognizing the specific situations where a hosted endpoint simply isn't an option, and those situations are more common than the marketing framing around "out of the box" tends to suggest. Consider a team running Confluence Server or Confluence Data Center rather than Atlassian Cloud: the official hosted server, as established earlier, cannot authorize against that deployment. That isn't a gap Atlassian is expected to close next quarter; it's a structural limit of the Cloud-only architecture. These aren't workarounds for an impatient team. They fit a deployment model the official server was never built to reach.

Data sovereignty and network isolation requirements push in the same direction. A hosted endpoint, by definition, means documentation content transits through the vendor's own infrastructure before it reaches the agent, which is simply incompatible with an air-gapped environment or a strict data-residency policy that a regulated industry might require. Headless pipelines raise the same question from a different angle, since a workflow with no human present to complete an OAuth handshake needs an authentication model a hosted endpoint doesn't offer.

The good news for any team facing one of these situations is that the tooling for building a self-hosted MCP server has gotten considerably easier to work with. FastMCP 3.0, released in February 2026, handles schema generation, validation, and documentation through a single decorator, cutting down meaningfully on the engineering work required to stand up a custom server. Google Cloud Run added first-party support for remote MCP servers and reached general availability in April 2026, giving teams a documented, supported path to production. And a handful of infrastructure platforms now exist specifically to host remote MCP servers without requiring anyone to manage Kubernetes: Modal offers serverless, GPU-capable Streamable HTTP endpoints billed per second; Prefect Horizon provides an MCP registry alongside a gateway with tool-level role-based access control and audit logging; Cloudflare Workers runs edge-distributed isolates with fast cold starts and its own access controls. None of these three is the right choice for every team, and choosing between them depends on the specific workload, compliance requirement, or latency budget a team is working against, but together they mean self-hosting a server in 2026 no longer requires the heavy infrastructure lift it once did.

How documentation quality determines what any MCP endpoint delivers

Choosing between a hosted endpoint and a self-hosted one answers whether an agent can reach the platform, under what authentication model, with what tool surface. It says nothing about whether what the agent reads once it gets there is accurate, current, and useful. Every platform mapped in this piece, Notion, Atlassian, Cosmic, Box, Context7, solves access. None of them change the underlying documentation itself, because that's not what an MCP server is built to do. An agent connected through a perfectly configured hosted endpoint, with the right transport, the right scope, the right auth model, will still produce unreliable output if the pages it's reading are stale, duplicated, or scattered across silos nobody has reconciled.

That makes MCP hosting and documentation quality two separate investments a team has to make together, not interchangeably. Spending effort perfecting the hosted connection while leaving the underlying content a mess caps what the agent can do just as surely as the reverse: clean, current documentation sitting behind a broken or absent MCP connection never reaches the agent. The connection is the conduit. The content moving through it is the signal, and no transport upgrade, OAuth flow, or GA announcement changes that. Teams evaluating which platform to connect to next would do well to ask not only whether the endpoint is hosted, but whether what sits behind it is worth an agent reading.