Confluence MCP: Connecting AI Assistants to Your Docs

To connect an AI assistant to Confluence, use Atlassian’s own remote MCP server, the Atlassian Rovo MCP Server at https://mcp.atlassian.com/v2/mcp. Add that address to Claude Code, Cursor, VS Code or another MCP client, sign in to Atlassian in the browser, and the assistant can search Confluence with CQL, read pages and their comments, create and update pages, and comment, all with your own Confluence permissions. It is the same server that carries Jira, so if you have already connected it for Jira you have Confluence too. It works with Atlassian Cloud only; for Data Center the options are a search connector or a community server you run yourself.

One server for Atlassian, not a Confluence server

There is no separate Confluence MCP server from Atlassian. The Rovo MCP Server covers Jira, Confluence, Jira Service Management, Bitbucket Cloud and more through one connection,, and your account’s access decides what each app’s tools can reach. Setup, sign-in and admin controls are therefore shared with Jira and are covered in detail in the Jira guides linked below. This piece is about what is specific to Confluence: its tools, the risks of letting an assistant write documentation, and the self-hosted options. The Jira side of the same server is in what the Jira MCP server can do.

The Confluence tools

Atlassian’s supported tools list↗ (opens in a new tab) groups Confluence tools by intent into read, write and search. A few are primary, always visible to the assistant; the rest are deferred, found at run time through the server’s discover tool. The primary ones cover most of a day’s work:

• getConfluenceContent: read any Confluence content, whether a page, blog post, live doc, comment, whiteboard, database or folder.
• searchConfluence: search Confluence with CQL, so “design docs in the PAY space updated this month” becomes a query.
• createConfluenceContent: create a page, blog post, live doc, whiteboard, database, folder or smart link.
• updateConfluenceContent: update a doc, whiteboard or database, by replacing it or by granular edits.
• search: a cross-product semantic search, in beta, across Jira, Confluence and connected apps.

The deferred tools go much further. On the read side: list spaces and the content in them, list and read comments, list versions and diff two of them, read attachments, export content, and check a page’s permissions and restrictions. On the write side: create a comment or reply to one, footer or inline; resolve a comment; add labels; copy, move, archive and unarchive content; restore an earlier version; change a page’s permissions and restrictions; and switch on a link that opens a page to people outside your organisation. The list names no tools for deleting Confluence content. Treat your client’s own tool list as the final word, because Atlassian changes this one.

Setting it up in each client

Every client uses the same address and the same browser sign-in; Atlassian’s getting-started guide↗ (opens in a new tab) gives the steps per client. In one or two lines each:

• Claude Code: run the command below, then /mcp in a session and sign in. Scopes, headless sign-in and pre-approving tools are in Jira MCP with Claude Code.
• Cursor: install the Atlassian plugin from the Cursor Marketplace, or add the URL to .cursor/mcp.json. Allowlisting read tools in permissions.json is in Jira MCP in Cursor.
• VS Code with GitHub Copilot: search @mcp Atlassian in the Extensions view and install, or add an http server to .vscode/mcp.json, then use it from a Local session with Agent selected, since the Copilot harness can currently reach only local MCP servers that don’t need authentication. Details in Jira MCP with GitHub Copilot.
• ChatGPT: install the Atlassian Rovo app from the Plugin Directory and sign in; it carries Confluence as well as Jira. See ChatGPT connectors for Jira.

claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp
# then, inside a session:
/mcp

Then check it with a read: “Which Atlassian sites can you see, and which Confluence spaces can I read?” If an answer comes back empty, the usual cause is the site: the sign-in covers the sites you picked on the consent screen.

Whose permissions it uses, and what admins control

Yours. Atlassian’s overview of the MCP server↗ (opens in a new tab) says access is scoped to the user’s existing permissions, so an assistant cannot open a space or a restricted page you could not open in the browser. The other side follows: whatever you can edit, the assistant can edit. If your account can change a page’s permissions, so can the assistant. There is no separate, narrower identity for the assistant inside Confluence; its edits are made with your account.

Organisation admins have several controls. Under Atlassian Administration, Rovo, Rovo MCP server, the Permissions tab↗ (opens in a new tab) switches read, write and search on or off, per app, so an admin can allow Confluence reads and searches while blocking Confluence writes. Changes apply at once, and a blocked call returns a message that the organisation admin has not authorised that permission. Admins also decide which AI clients may sign in, by domain, whether API tokens are allowed, and which IP addresses may connect, and can filter the audit log for MCP activity. Some calls, such as Rovo search and Teamwork Graph, use Rovo credits from the organisation’s pool.

Confluence Data Center

The Rovo MCP Server does not reach Confluence Data Center or Server. Atlassian offers one bridge: an admin can connect Confluence Data Center to Teamwork Graph↗ (opens in a new tab), which indexes pages, blog posts, comments and attachments so Rovo can find them, respecting Confluence permissions. It needs an Atlassian Cloud organisation and Confluence 9.4 or later, or 9.2.6 LTS and later. It is a search index, not a way for an assistant to write to your Data Center site.

To read and write a self-hosted instance, the working route is a server you run yourself. The most widely used is mcp-atlassian↗ (opens in a new tab), a community project, not an Atlassian product, that supports Confluence Server and Data Center 6.0 and later with a personal access token. It has a read-only mode, a filter to limit it to named spaces, and a setting to expose only the tools you list. A personal access token carries your full permissions with no scopes, so read-only has to come from the server’s settings or from a narrower account. Where to run such a server and what the token carries is covered for Jira in Jira MCP for Data Center, and the same reasoning applies to Confluence.

{
  "mcpServers": {
    "confluence": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "CONFLUENCE_URL": "https://confluence.your-company.com",
        "CONFLUENCE_PERSONAL_TOKEN": "<your personal access token>",
        "CONFLUENCE_SPACES_FILTER": "ENG,OPS",
        "READ_ONLY_MODE": "true"
      }
    }
  }
}

Prompts that work well

• “Find the design doc for the export service in the ENG space and summarise the decisions it records, with the page link.”
• “Compare the current version of the Onboarding page with the one from a month ago and tell me what changed.”
• “Read the open inline comments on the API guidelines page and list the unanswered questions.”
• “Draft release notes for 4.2 from these commits and show me the text. Do not create anything yet.”
• “Create a child page under Runbooks called ‘Restarting the export worker’ with the text I approved above.”

The pattern is read first, draft in the chat, write only after you have seen the text. Asking for the page link in every answer makes it easy to check the source rather than trusting the summary.

What never to let an assistant publish on its own

A wrong Jira field is visible and easy to fix. A wrong paragraph in a policy page is read, trusted and copied before anyone notices. Keep these on approval in your client, and treat each as a person’s decision:

• Changes to page permissions or restrictions, and anything that opens a page to people outside your organisation.
• Edits to pages other people own or rely on: policies, runbooks, onboarding, anything customers or auditors read.
• Moving or archiving pages, which breaks links and changes who can find them.
• Restoring an old version over someone’s recent work.
• Bulk changes across many pages, such as relabelling or rewriting a section everywhere.
• Resolving other people’s comments, which ends a conversation they started.
• Anything written after reading an untrusted page. Page text can contain instructions aimed at the assistant; the risk is explained in MCP security risks.

In practice: pre-approve getConfluenceContent and searchConfluence, keep create, update and every deferred write on ask, and never trust the whole server at once. If your organisation wants that enforced rather than hoped for, an admin can block Confluence writes for everyone on the Permissions tab; the wider policy question is in MCP governance.

Docs in Confluence, work on a board

Confluence is where the spec, the decision record and the runbook live. What it is not is a list of who is doing what next. A common pattern is an assistant that reads the spec in Confluence and files the work somewhere smaller. fenbs is one such place: the same assistant, connected to both servers, reads the design page and creates fenbs tasks with fenbs_create_item, the problem in each task’s note and a link back to the page, then moves them through To Do, Next Up, In Progress and Completed as the work happens. Unlike Confluence, fenbs records every change in History under the assistant’s name, on your behalf, and you can give an assistant a narrower role of its own on a board.