Jun 23, 2026

Confluence MCP vs Confluence API for AI Agents (2026)

TL;DR

The official Atlassian Rovo MCP server exposes 12 Confluence-specific tools (7 read, 4 write, 1 search). Attachments, blog posts, page restrictions, version history, labels, space administration, and webhooks are REST-only surfaces. The MCP does not expose them.
The MCP server supports OAuth 2.1 for interactive use and API token auth for headless scenarios. API token support was added in March 2026, but it requires an org admin to enable it in Atlassian Administration before your agent can use it. The Confluence REST API accepts OAuth 2.0, API tokens, and JWT without any admin prerequisite.
For multi-tenant B2B agents, both paths require one credential per user. Neither path handles storage, rotation, or revocation at scale. That infrastructure problem is identical regardless of which path you choose.
MCP is the right path for interactive agents where the user is present and OAuth consent is natural. The REST API is the right path for headless pipelines, event-driven automation, and any capability the MCP does not expose.
Scalekit handles OAuth, token storage, and credential lifecycle for both paths, so the MCP vs. API decision does not change your auth infrastructure.

Your agent needs to read and write Confluence. You have two paths: the official Atlassian Rovo MCP server, which reached general availability in February 2026 with 12 Confluence-specific tools over OAuth 2.1 and API token auth, and the Confluence REST API v2, which covers the full surface with no license dependency and no admin-toggle required for headless access. They cover overlapping but not identical territory. The auth paths are different. The operational implications for a multi-tenant B2B agent are significant. Here is how to pick.

What the Atlassian Rovo MCP Server and the Confluence REST API actually are

The Atlassian Rovo MCP Server

The Atlassian Rovo MCP Server is Atlassian's official, cloud-hosted Model Context Protocol server. It entered beta in May 2025 and reached general availability on February 4, 2026. It is built and maintained by Atlassian, hosted on Cloudflare infrastructure, and covers Jira, Confluence, Compass, Bitbucket Cloud, and Jira Service Management in a single endpoint.

The MCP server endpoint is https://mcp.atlassian.com/v1/mcp. The older /sse path is deprecated and unsupported after June 30, 2026. Authentication supports OAuth 2.1 as the primary path and API token auth as a secondary option, which must be enabled by an organization admin.

Confluence-specific tools ship across three permission groups: read_confluence, write_confluence, and search_confluence.

Resource: Official Atlassian docs & GitHub

The Confluence REST API

The Confluence Cloud REST API v2 is versioned, cursor-paginated, and covers the full data model: pages, blog posts, spaces, attachments, labels, comments, restrictions, versions, content properties, and more. Authentication accepts OAuth 2.0 (3LO), API tokens via Basic Auth, and JWT for Forge apps.

The v1 REST API remains accessible but is in the process of deprecation. New agent integrations should target v2.

Official docs: developer.atlassian.com/cloud/confluence/rest/v2

What tools the Atlassian Rovo MCP server exposes for Confluence

The official Confluence tool list

From the official Atlassian supported tools documentation, the following Confluence tools are available on the Rovo MCP server. These are grouped by permission set, which org admins grant or revoke at the group level.

read_confluence (7 tools, available via OAuth 2.1 and API token):

Tool

What it does

getConfluencePage

Get a Confluence page or live doc by ID

getConfluencePageDescendants

List descendant pages under a parent page

getConfluencePageFooterComments

List footer comments on a page

getConfluencePageInlineComments

List inline comments on a page

getConfluenceCommentChildren

List child comments (replies) of a comment

getConfluenceSpaces

List Confluence spaces

getPagesInConfluenceSpace

List pages in a space

write_confluence (4 tools, available via OAuth 2.1 and API token):

Tool

What it does

createConfluencePage

Create a new Confluence page or live doc

updateConfluencePage

Update an existing Confluence page or live doc

createConfluenceFooterComment

Create a footer comment or reply on a page

createConfluenceInlineComment

Create an inline comment tied to selected text

search_confluence (1 tool, available via OAuth 2.1 and API token):

Tool

What it does

searchConfluenceUsingCql

Search Confluence content using CQL

Two beta platform tools (searchAtlassian, fetchAtlassian) provide Rovo-powered natural language search across Jira and Confluence combined. These are in beta and are billed separately in the future.

Comparing them where it matters for agents

What your agent can actually do

The Rovo MCP server covers the retrieval and authoring surface well for most knowledge agent workflows. The gaps become significant when an agent needs to process anything beyond page content, or react to changes.

Capability

Atlassian Rovo MCP

Confluence REST API

Get a page by ID

Yes

List pages in a space

Yes

List descendant pages

Yes

Create a page

Yes

Update a page

Yes

Get page footer comments

Yes

Get page inline comments

Yes

Create footer and inline comments

Yes

Search via CQL

Yes

List spaces

Yes

Create blog posts

Yes

Read and update blog posts

Yes

Manage attachments (read, upload, delete)

Yes

Manage page labels

Yes

Get page restrictions (read or update)

Yes

Set page restrictions

Yes

Get page version history

Yes

Manage content properties (key-value metadata)

Yes

Create new spaces

Yes

Manage space permissions

Yes

Webhook event subscriptions

Yes (via app descriptor for Cloud)

Export pages to PDF

Yes

Delete pages

Yes

Where the MCP ceiling is visible

The gap matters most for agents doing anything beyond read-and-create workflows. A documentation agent that needs to read all on-call runbooks, check which have attachments, apply labels to outdated pages, and delete obsolete content cannot do this on the MCP path alone. Each of those last three operations requires the REST API. An agent that needs to react to Confluence events, such as a page being created or updated, needs webhooks, which are REST-only for Cloud.

Blog posts are a separate content type in Confluence. The MCP server tools handle pages and live docs; they do not expose create, read, update, or delete operations for blog posts. If your agent is writing weekly team updates or incident postmortems as blog posts, not pages, the REST API is the only path.

The auth path each one puts you on

MCP: OAuth 2.1 as primary, API token as opt-in

The Rovo MCP server uses OAuth 2.1 as its primary auth mechanism. When a user connects an MCP client to the server, they complete a browser-based consent flow that grants the client scoped access to their Atlassian data. Tokens are managed by the client.

API token auth was added in March 2026 as a secondary option for headless and machine-to-machine use cases. Two credential types are supported: personal API tokens via Authorization: Basic <base64(email:api_token)> and service account API keys via Authorization: Bearer <api_key>.

The constraint that matters for production agents: API token auth is off by default. An org admin must explicitly enable it in Atlassian Administration under Rovo, then Rovo MCP server settings. If your agent targets multiple customer orgs, that means enabling API token auth in each one. You cannot assume it is on.

REST API: No admin prerequisite

The Confluence REST API accepts OAuth 2.0 (3LO) for user-context calls, API tokens via Basic Auth, and JWT for Forge app context. No org-level toggle is required. A background agent using an API token can connect immediately without requiring any admin action in the target Confluence org.

For multi-tenant B2B agents, this distinction is concrete. An agent running nightly documentation audits across 30 customer Confluence orgs needs each org's admin to enable API token auth on the MCP server before the MCP path is usable. The REST API path has no such dependency.

What you own in production

On the MCP path

Atlassian manages the server, tool schemas, and infrastructure. The operational benefit is real: you do not deploy, patch, or version a server.

What you still own: token storage per user, refresh handling, revocation when users disconnect, and adaptation when Atlassian updates tool schemas. Tool schemas on the MCP server are not versioned by your client; when Atlassian updates the server, your agent picks up the changes. For interactive development tools this is often desirable. For deterministic scheduled pipelines, it can be a source of unexpected behavior.

One notable constraint for enterprise deployments: org admins control which MCP client domains are allowed to connect when OAuth 2.1 is used. Your agent's domain must be on the Atlassian-supported domain list or a custom allowlist. API token auth bypasses domain controls but is subject to IP allowlists.

On the REST API path

You own the full stack: endpoint selection, request construction, cursor-based pagination (v2 uses cursors, not offsets), error handling, retry logic, token lifecycle, and version management.

The Confluence REST API v2 does not publish exact rate limit numbers, but enforces per-user request limits on Cloud. Agents running high-volume operations, such as bulk label updates or full-space content audits, need explicit pagination handling and backoff logic.

The API is versioned; breaking changes follow Atlassian's deprecation process, and you control when to migrate. The v1 API remains available but should not be used for new development.

When to use MCP, when to use the REST API

Use the Atlassian Rovo MCP server when:

The agent is interactive and user-present: a Claude Code integration, Cursor plugin, or VS Code extension where the user completes the OAuth consent flow naturally
The core workflow is page search, retrieval, and creation, without needing attachments, blog posts, labels, or restrictions
You want Atlassian to own schema updates and server maintenance rather than tracking API changes yourself
You are building for a single org or a small set of orgs where you can confirm API token auth is enabled, or where OAuth per user is acceptable
The agent needs Rovo-powered semantic search across Jira and Confluence in a single tool call

Use the Confluence REST API directly when:

The agent runs headless on a schedule, without a user session: nightly documentation audits, automated changelog generators, stale page detectors
The workflow requires blog posts, attachments, labels, page restrictions, version history, space creation, or space permissions
You cannot depend on org admins enabling API token auth across customer orgs before your agent runs
The agent handles high-volume operations where you need explicit control over pagination, rate limits, and retry behavior
Schema stability matters: you need to pin an API version and migrate on your own schedule

The credential problem that exists on both paths

Both the MCP server and the REST API give you a credential per user. The MCP OAuth flow gives you an OAuth 2.1 token scoped to that user's Atlassian account. The REST API gives you an OAuth 2.0 token or API key. In neither case does the path itself handle what happens after the credential is issued.

What neither path provides

Storage: credentials need to live somewhere outside agent runtime, encrypted at rest, isolated per tenant. Rotation: OAuth tokens expire and must be refreshed proactively; waiting for a 401 in a background agent creates race conditions across threads. Revocation: when a user leaves a customer org or disconnects their Atlassian account, you need a way to surface and invalidate that credential without affecting any other tenant.

In a multi-tenant B2B product serving 25 engineering teams, each with their own Confluence workspace, that is 25 credentials, each with its own expiry, each requiring independent revocation handling. The MCP path and the REST API path both produce this problem. The token type differs; the infrastructure required is the same.

Scalekit's Confluence connector handles the OAuth flow, token storage, automatic refresh, and revocation for both paths, so the MCP vs. API decision does not change your credential infrastructure.

Connecting Confluence agents via Scalekit

Scalekit ships two connectors relevant to this choice.

The Confluence connector targets the REST API directly. It exposes tools including confluence_search, confluence_page_get, confluence_page_create, confluence_page_update, confluence_spaces_list, and confluence_comments_list, with per-user token isolation and a 90-day audit trail.

The Atlassian Rovo MCP connector connects through the official Atlassian Rovo MCP server. It exposes Rovo-powered search, page retrieval, page creation, and natural language knowledge queries against your Atlassian workspace, with the same vaulted credential model.

For both connectors, what the user cannot do in Confluence, the agent cannot do. Scope is derived from the user's Atlassian permissions at authorization time.

Connecting via LangChain (Node.js)

This uses the Scalekit Node.js SDK with the Confluence connector. listScopedTools returns only the tools the current user's connected account is authorized to call. Tool surface is reduced before the agent loop begins.

import { ScalekitClient } from "@scalekit-sdk/node"; import { DynamicStructuredTool } from "@langchain/core/tools"; import { createReactAgent } from "@langchain/langgraph/prebuilt"; import { ChatAnthropic } from "@langchain/anthropic"; import { z } from "zod"; const sk = new ScalekitClient( process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET ); // Retrieve only the tools the current user is authorized to call. // connection_name must match the name configured in your Scalekit dashboard. const { tools } = await sk.tools.listScopedTools("user_123", { filter: { connectionNames: ["confluence"], toolNames: [ "confluence_search", "confluence_page_get", "confluence_page_create", "confluence_page_update", ], }, pageSize: 100, }); const lcTools = tools.map( (t) => new DynamicStructuredTool({ name: t.tool.definition.name, description: t.tool.definition.description, schema: z.object({}).passthrough(), func: async (args) => { const { data } = await sk.tools.executeTool({ toolName: t.tool.definition.name, identifier: "user_123", params: args, }); return JSON.stringify(data); }, }) ); const llm = new ChatAnthropic({ model: "claude-sonnet-4-6" }); const agent = createReactAgent({ llm, tools: lcTools }); const result = await agent.invoke({ messages: [ { role: "user", content: "Find all on-call runbooks updated in the last 30 days.", }, ], });

Connecting via the Anthropic SDK (Node.js)

This wires the Scalekit Confluence tools directly into the Anthropic messages API. The tool loop continues until the model stops calling tools.

import { ScalekitClient } from "@scalekit-sdk/node"; import Anthropic from "@anthropic-ai/sdk"; const sk = new ScalekitClient( process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET ); const anthropic = new Anthropic(); // Retrieve the authorized tool surface for this user. // The connection_name "confluence" must match your Scalekit dashboard configuration. const { tools } = await sk.tools.listScopedTools("user_123", { filter: { connectionNames: ["confluence"], toolNames: [ "confluence_search", "confluence_page_get", "confluence_page_create", "confluence_page_update", ], }, pageSize: 100, }); const llmTools = tools.map((t) => ({ name: t.tool.definition.name, description: t.tool.definition.description, input_schema: t.tool.definition.input_schema, })); const messages = [ { role: "user", content: "Find all on-call runbooks updated in the last 30 days.", }, ]; let response = await anthropic.messages.create({ model: "claude-sonnet-4-6", max_tokens: 1024, tools: llmTools, messages, }); // Run the tool loop. while (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find((b) => b.type === "tool_use"); const { data } = await sk.tools.executeTool({ toolName: toolUseBlock.name, identifier: "user_123", params: toolUseBlock.input, }); messages.push({ role: "assistant", content: response.content }); messages.push({ role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(data), }, ], }); response = await anthropic.messages.create({ model: "claude-sonnet-4-6", max_tokens: 1024, tools: llmTools, messages, }); } console.log(response.content[0].text);

Connecting via the Anthropic SDK (Python)

This is the Python equivalent using the Scalekit Python SDK and the Anthropic Python client.

import os import json import anthropic from scalekit import ScalekitClient sk = ScalekitClient( os.environ["SCALEKIT_ENV_URL"], os.environ["SCALEKIT_CLIENT_ID"], os.environ["SCALEKIT_CLIENT_SECRET"], ) client = anthropic.Anthropic() # Retrieve the authorized tool surface for this user. # connection_name must match your Scalekit dashboard configuration. scoped = sk.tools.list_scoped_tools( "user_123", filter={ "connectionNames": ["confluence"], "toolNames": [ "confluence_search", "confluence_page_get", "confluence_page_create", "confluence_page_update", ], }, page_size=100, ) llm_tools = [ { "name": t.tool.definition.name, "description": t.tool.definition.description, "input_schema": t.tool.definition.input_schema, } for t in scoped.tools ] messages = [ { "role": "user", "content": "Find all on-call runbooks updated in the last 30 days.", } ] response = client.messages.create( model="claude-sonnet-4-6", max_tokens=1024, tools=llm_tools, messages=messages, ) # Run the tool loop. while response.stop_reason == "tool_use": tool_use = next(b for b in response.content if b.type == "tool_use") result = sk.tools.execute_tool( tool_name=tool_use.name, identifier="user_123", params=tool_use.input, ) messages.append({"role": "assistant", "content": response.content}) messages.append( { "role": "user", "content": [ { "type": "tool_result", "tool_use_id": tool_use.id, "content": json.dumps(result.data), } ], } ) response = client.messages.create( model="claude-sonnet-4-6", max_tokens=1024, tools=llm_tools, messages=messages, ) print(response.content[0].text)

Connecting via the Atlassian Rovo MCP connector (MCP path)

For interactive agents where the user is present and the Rovo MCP server is the right choice, Scalekit's Atlassian Rovo MCP connector provides a user-scoped token that gates access to the MCP endpoint. No raw Atlassian OAuth credentials touch your agent code.

import { Agent } from "@google/adk/agents"; import { MCPToolset, StreamableHTTPConnectionParams, } from "@google/adk/tools/mcp"; import { ScalekitClient } from "@scalekit-sdk/node"; const sk = new ScalekitClient( process.env.SCALEKIT_ENV_URL, process.env.SCALEKIT_CLIENT_ID, process.env.SCALEKIT_CLIENT_SECRET ); // Resolve a short-lived, user-scoped session token for this user's // Atlassian Rovo MCP connected account. // connection_name must match your Scalekit dashboard configuration. const { token } = await sk.connections.getToken( "atlassianrovomcp", "user_123" ); const toolset = new MCPToolset({ connectionParams: new StreamableHTTPConnectionParams({ url: "https://mcp.scalekit.com/atlassianrovomcp", headers: { Authorization: `Bearer ${token}` }, }), }); const agent = new Agent({ name: "confluence-knowledge-agent", model: "gemini-2.0-flash", tools: await toolset.getTools(), });

For Claude Code and Cursor, you can also wire the Scalekit Confluence connector as a Virtual MCP server:

// ~/.cursor/mcp.json { "mcpServers": { "confluence": { "url": "https://mcp.scalekit.com/confluence", "headers": { "Authorization": "Bearer $SCALEKIT_TOKEN" } } } }

Why multi-tenant Confluence agents need Scalekit

A shared Confluence integration token looks correct in a demo. In production, every page edit and space write is attributed to a service account, not the user who triggered the agent. Space permission scoping breaks. Page ownership is wrong. The audit trail shows a bot, not a person.

Scalekit resolves the actual authorized user's credential on every tool call. Every action in Confluence is attributed to the user who authorized it. Every call is logged with the user identity, the tool called, and the result: 90 days of history, SIEM-exportable.

For teams building agents that act across more than one customer's Confluence workspace, each customer's credentials live in an isolated vault namespace. Cross-tenant credential access is blocked at the infrastructure layer, not enforced in your prompt.

If Scalekit does not yet have the specific Confluence capability your agent needs, you can request a new tool or connector from the Scalekit team: Join the Scalekit Slack community or talk to the team directly.

Which one to build against

If your agent is interactive, user-present, and focused on page search, retrieval, and creation, the Atlassian Rovo MCP server is a legitimate path. Atlassian owns the server maintenance, OAuth is handled at connection time, and Rovo's semantic search gives the agent a meaningful advantage over raw CQL queries for knowledge retrieval tasks.

If your agent runs headless, touches attachments or blog posts or labels, depends on per-page restriction checks, or needs to react to Confluence events, build against the REST API directly. The 12 tools on the MCP surface do not cover these capabilities, and they are not on a roadmap that is visible or versioned from your agent's perspective.

Most production Confluence agents end up on both paths. The interactive assistant runs on MCP. The background documentation auditor, the stale-page reporter, the attachment processor — these run on the REST API. Either way, the credential management problem is structurally identical, and that is what needs production-grade infrastructure before your agent ships.

Next steps:

Explore the Scalekit Confluence connector.
Explore the Scalekit Atlassian Rovo MCP connector.
Scalekit's Confluence connector docs.

No items found.

On this page

Introduction
‍

This is some text inside of a div block.

Confluence MCP vs Confluence API for AI Agents (2026)

TL;DR

What the Atlassian Rovo MCP Server and the Confluence REST API actually are

The Atlassian Rovo MCP Server

The Confluence REST API

What tools the Atlassian Rovo MCP server exposes for Confluence

The official Confluence tool list

Comparing them where it matters for agents

What your agent can actually do

Where the MCP ceiling is visible

The auth path each one puts you on

MCP: OAuth 2.1 as primary, API token as opt-in

REST API: No admin prerequisite

What you own in production

On the MCP path

On the REST API path

When to use MCP, when to use the REST API

The credential problem that exists on both paths

What neither path provides

Connecting Confluence agents via Scalekit

Connecting via LangChain (Node.js)

Connecting via the Anthropic SDK (Node.js)

Connecting via the Anthropic SDK (Python)

Connecting via the Atlassian Rovo MCP connector (MCP path)

Why multi-tenant Confluence agents need Scalekit

Which one to build against

Acquire enterprise customers with zero upfront cost