Confluence MCP: How to Connect Confluence to Your AI Coding Agent (2026)
Connect Confluence to your AI agent in ~2 minutes via Atlassian's official server, then handle the token tax and the 46% AI-distrust trap.

Bottom line: connecting Confluence to your agent is a two-minute OAuth flow against Atlassian's authv2 endpoint. The real work comes after: pruning the tool definitions you pay for on every turn, and recognizing that an agent reading a page cannot tell whether that page is current. The reason a page exists lives in the threads and pull requests around it, which is what a context layer adds.
You can connect Confluence to your AI coding agent in a couple of minutes by pointing it at Atlassian's official remote MCP server and approving an OAuth prompt. The moment you do, though, you hit a problem Jira does not have as badly: Confluence is where docs go to get stale, and a Confluence MCP server will hand your agent the half-finished drafts, the duplicate pages, and the superseded runbooks with exactly the same confidence as the one page that is actually true.
That staleness is not a small problem. Atlassian's own research found employees at large companies spend roughly 2.4 billion hours a year searching for information, with about a quarter of the workday lost to the hunt and nearly half of teams unknowingly duplicating work (Atlassian State of Teams 2025, 2025). An access protocol pointed at that mess inherits all of it. What helps underneath is a layer that reconciles conflicts across your docs, so the page your agent gets back is the one that is actually current.
This guide gives you the current config for each client, set after the June 2026 endpoint cutover, plus the official-versus-self-hosted decision. It also covers the two things every Confluence MCP walkthrough skips: the token tax you pay on every turn, and the gap between reading a page and knowing whether that page is current.
What is a Confluence MCP server, and what can your agent do with it?#
The Model Context Protocol now runs more than 10,000 active public servers and draws over 97 million monthly SDK downloads (Model Context Protocol, 2025). MCP is the open standard that lets an AI client call external tools, and a Confluence connector exposes Confluence operations as those tools.
In practice, your agent can search pages, read a page's full body, list spaces, post a comment, or create and update content, all through tool calls instead of copy-pasting. It acts under your own Confluence permissions, so it cannot read a space you cannot.
Why does that beat a plain API script? The agent decides when to call which tool, mid-task, without you wiring the sequence. Ask it to draft a release note, and it searches the space and reads the linked design doc on its own.
Two servers matter: Atlassian's official remote one and the community self-hosted one. Which you pick depends on whether you run Cloud or on-prem.
Which Atlassian MCP server should you use, official or community?#
There are two real options, and the choice is close to binary. Atlassian's official Rovo MCP Server reached general availability on February 4, 2026: remote, hosted, Cloud-only, and built on OAuth 2.1 (Atlassian, 2026). The community route is self-hosted and reaches on-prem.
The official server respects each user's permissions and now spans Jira, Confluence, Compass, Bitbucket Cloud, and Jira Service Management, broader coverage than it shipped with. If your team lives in Atlassian Cloud, this is your answer. (It is the same server family covered in our Jira MCP setup guide; the Confluence tooling rides along with it.)
The community sooperset/mcp-atlassian project carries roughly 5,500 GitHub stars and ships 72 tools across Jira and Confluence (GitHub, 2026). It runs in Docker and, unlike the official server, supports both Cloud and Confluence Server or Data Center v6.0+.
The rule of thumb: Cloud teams use the official server, Server or Data Center teams use the community one. The full side-by-side sits a couple of sections down.
How do you connect Confluence to Claude Code, Cursor, and VS Code?#
One date breaks the old guides. After June 30, 2026, the legacy https://mcp.atlassian.com/v1/sse endpoint is no longer supported, and you must use /v1/mcp/authv2 instead (Atlassian Community, 2026). Every snippet below already uses the current endpoint.
Setup takes about two minutes once you have an Atlassian Cloud site and a supported client. If you copied config from an older walkthrough, the endpoint line is the thing to change.
VS Code#
Add the server to .vscode/mcp.json:
json{"servers":{"atlassian-mcp-server":{"url":"https://mcp.atlassian.com/v1/mcp/authv2","type":"http"}}}Cursor#
Add it to ~/.cursor/mcp.json:
json{"mcpServers":{"Atlassian-MCP-Server":{"url":"https://mcp.atlassian.com/v1/mcp/authv2"}}}On older Cursor builds that cannot reach a remote server directly, bridge through npx mcp-remote@latest <url> instead.
Claude Code#
Run one command, then authorize:
bashclaude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2Then run /mcp inside Claude Code to trigger the browser OAuth flow.
The first connection opens a browser-based OAuth 2.1 consent screen. Once you approve, the agent acts under your own Confluence permissions, so its reach matches your existing access rather than a shared service account. One note for capacity planning: these MCP calls count against your underlying Confluence Cloud API rate limits, so heavy multi-agent runs draw down the same budget as the rest of your integrations.
How do you self-host a Confluence connector for Server or Data Center?#
If you run Confluence on-prem, the official server cannot help, because it is Cloud-only (Atlassian, 2026). The community sooperset/mcp-atlassian server is the supported route, covering Confluence Cloud and Confluence Server or Data Center v6.0+.
The workflow is straightforward. Run the server in Docker, then authenticate: an API token on Cloud, a personal access token on Server or Data Center, or OAuth 2.0 if you prefer. Once it is running, point your client at the local server URL exactly as you would any other MCP server.
The tradeoff is ownership. You host it and patch it, and you decide which toolsets to enable for tighter scope. In return you get on-prem coverage the official endpoint cannot offer. What you give up is Atlassian support, since the project is community-maintained and labels itself as not official.
For a regulated team that cannot send page data to a hosted endpoint, that ownership is worth the operational work: container updates, credential rotation, and monitoring all land on you.
Official Rovo MCP vs the community server: how they compare#
Most Cloud teams will reach for the official Rovo server, which spans five Atlassian products, while on-prem teams have one option: the community server with its 72 tools (GitHub, 2026). The table below lines them up on the dimensions that actually decide the call.
| Atlassian Rovo MCP Server (official) | sooperset/mcp-atlassian (community) | |
| Hosting | Remote, hosted by Atlassian | Self-hosted (Docker) |
| Auth | OAuth 2.1 / API token | API token (Cloud) / PAT (Server-DC) / OAuth 2.0 |
| Products | Jira, Confluence, Compass, Bitbucket Cloud, JSM | Jira, Confluence |
| Cloud vs Server/DC | Cloud-only | Cloud and Server / Data Center v6.0+ |
| Endpoint | /v1/mcp/authv2 (/v1/sse ends Jun 30, 2026) | Local server URL |
| Official support | Yes | No |
The read-out: official for Cloud, community for on-prem. The row people miss is the cost both share. Each one makes your agent pay for its full tool-definition schema on every turn, and neither can tell the agent which of two conflicting pages is the current one. Those are the next two sections.
Why does a Confluence MCP server cost more tokens than you think?#
Your agent pays for a server's tool definitions on every turn, before it reads a word of your request. Anthropic's engineering team reported agents processing hundreds of thousands of tokens before reading a request, with one code-execution pattern cutting a workload from 150,000 to 2,000 tokens, a 98.7% drop (Anthropic, 2025).
That tax is invisible because it never throws an error. It shows up as a smaller working budget. When Unblocked measured the official GitHub server, its tool definitions alone came to roughly 42,000 tokens before the first prompt, around a fifth of a 200,000-token window. A broad Atlassian toolset, or the community server's 72 tools, is the same shape of cost.
The practical move is to run fewer, leaner servers and enable only the toolsets you actually call, so your context window funds the work rather than the schema. You keep the integration; you just stop paying for tools you never touch. For the full accounting of how that per-turn cost compounds across a stack of servers, the numbers add up faster than most teams expect.
Does a Confluence MCP give your agent understanding, or just the page?#
A connector returns the page text; it cannot tell the agent whether that page is true. Developer distrust of AI accuracy climbed to 46% in 2025, up from 31% the year before, and 66% say they lose time fixing answers that are almost right (Stack Overflow, 2025).
A Confluence connector hands the agent a page's title, body, and last-edited date. It does not tell the agent which of three overlapping pages is authoritative, that the current architecture doc was quietly overruled in a Slack thread, or that half the space is abandoned drafts. Confluence is where staleness accumulates, and Atlassian's own data shows nearly half of teams duplicate work and lose about a quarter of their time searching (Atlassian State of Teams 2025, 2025). An access protocol can pull a page back. Reconciling two pages that disagree is beyond it.
The reason a page exists, and the decision that superseded it, lives in the threads and pull requests around it, not in the page body. This is the gap between reading a page and understanding it. Closing it takes a context layer that resolves conflicts across your docs, unifying pages, threads, and pull requests into one synthesized answer: decision-grade context rather than raw page text. This is the approach a context engine like Unblocked takes: it unifies Confluence with Slack and pull requests and returns the reconciled answer, so the agent reads the decision that is current, not just the newest-edited page.
Unblocked is the first MCP queried for everything we look up. It's not just checking the code — the code could be wrong. It pulls the Confluence docs, the feature planning documents, the Slack conversations. We can't use the Slack MCP for legal reasons, so Unblocked is the only way we can access that context. For an engineering manager trying to understand a platform fast, that's the difference.
— Sam Younger, Engineering Manager, UserTesting
That is the shift from access to understanding: a context layer beneath MCP that knows which page to trust, where a connector only knows how to fetch.
Frequently asked questions about Confluence MCP#
Here are the questions teams ask most about wiring Confluence into an agent, answered against the current product facts: the official server reached general availability on February 4, 2026, and is Cloud-only (Atlassian, 2026).
Is there an official server for connecting Confluence to an agent?#
Yes. Atlassian's Rovo MCP Server reached general availability on February 4, 2026 (Atlassian, 2026). It is Cloud-only, uses OAuth 2.1, and covers Confluence alongside Jira, Compass, Bitbucket Cloud, and Jira Service Management. For Server or Data Center, the community sooperset/mcp-atlassian project is the route instead.
How do I connect Confluence MCP to Claude Code?#
Run claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2, then run /mcp inside Claude Code to authorize through the browser OAuth 2.1 prompt. The agent then searches and reads Confluence under your own permissions. Use the authv2 endpoint, since the legacy /v1/sse endpoint stops working after June 30, 2026.
How do I set up Confluence MCP in Cursor?#
Add the authv2 URL to ~/.cursor/mcp.json as {"mcpServers":{"Atlassian-MCP-Server":{"url":"https://mcp.atlassian.com/v1/mcp/authv2"}}} and approve the OAuth consent screen on first connection. Older Cursor builds that cannot reach a remote server directly should bridge through npx mcp-remote@latest pointed at the same URL.
Does Confluence MCP work with Server or Data Center?#
The official server does not; it is Cloud-only (Atlassian, 2026). For Confluence Server or Data Center v6.0+, self-host the community sooperset/mcp-atlassian server in Docker and authenticate with a personal access token. It also supports Confluence Cloud if you want a single self-managed server across both.
Why doesn't my agent trust the Confluence page it read?#
Because an MCP returns text, not currency. The connector hands over a page's body and edit date, but it cannot tell which of several overlapping pages is authoritative or whether a Slack decision quietly overruled it. Developer distrust of AI accuracy hit 46% in 2025 (Stack Overflow, 2025) for related reasons.
Is a Confluence MCP enough, or do you need a context engine?#
A Confluence MCP is enough to read pages under your own permissions. It is not enough when pages are stale or contradict each other, because it returns text without resolving which one is authoritative. A context engine like Unblocked unifies Confluence with Slack and pull requests and returns the reconciled answer, so the agent acts on the current decision rather than the newest-edited doc.
Where the Real Context Lives#
If you are on Atlassian Cloud, connect the official remote server today; the setup runs about two minutes against the authv2 endpoint. If you are on Server or Data Center, self-host sooperset/mcp-atlassian instead. Either way, prune the toolset so your agent is not paying for 72 tools it never calls, a cost that can run to tens of thousands of tokens before the first prompt (Anthropic, 2025).
Then know the ceiling. A connector gets your agent the page. Whether that page is current, and what decision overruled it, lives in the threads and pull requests around it, where Atlassian's research says a quarter of the workday already disappears into searching (Atlassian State of Teams 2025, 2025). A layer that unifies and reconciles those sources is what turns page access into page understanding. That is the difference between an agent that fetches a page and one that knows which page to believe.


