Your agent needs to work with Atlassian. It has to pull the issues blocking a release, read the spec in Confluence that explains why a ticket exists, transition tickets when a deploy lands, and do all of it on behalf of the engineer who asked. Atlassian now ships two ways to get there: the official Rovo MCP Server and the Atlassian Cloud REST APIs your integrations have called for a decade. They overlap, but not evenly, and the seams are in places you only find in production. Here is the decision framework.
These are two different surfaces over the same permission model. Rovo MCP is a managed tool layer that Atlassian hosts and versions. The Cloud APIs are the raw product surfaces, one per app, that the MCP server itself calls underneath. Knowing which object you are building against changes what you can promise your users.
The Rovo MCP Server is Atlassian's official, Atlassian-hosted remote MCP server. It reached general availability on February 4, 2026, and covers Jira, Confluence, Jira Service Management Ops, Bitbucket Cloud, and Compass through a single endpoint at https://mcp.atlassian.com/v1/mcp. Atlassian recommends pointing custom clients at /v1/mcp/authv2; the legacy Server-Sent Events endpoint at /v1/sse was scheduled to stop being supported after 30 June 2026.
An Atlassian Cloud site is a hard prerequisite. Tools are organized into permission groups by product and intent, and organization admins grant or revoke access at the group level rather than the tool level. Official reference: the Atlassian Rovo MCP Server product page and the supported tools list.
There is no single "Atlassian API." There are several, and an agent builder has to reason about each one separately: the Jira Cloud platform REST API (/rest/api/3/), the Jira Software Agile API, the Jira Service Management API, the Confluence Cloud REST API, the Bitbucket Cloud API, and Compass, which is a GraphQL surface rather than a REST one.
Authentication accepts OAuth 2.0 three-legged (3LO) tokens for per-user delegation, Basic auth with a personal API token, Bearer auth with a service account API key, and the Forge and Connect app frameworks. Endpoint coverage is complete: every capability the MCP server exposes exists in REST, plus a large surface it does not touch. Official reference: the Jira Cloud platform REST API documentation.
Four dimensions decide this: what the agent can do, what credential it holds, what you own when something breaks, and which scenario you are actually in. The Atlassian answer differs from the Notion or Salesforce answer in one important way, so the auth dimension is where the interesting reading is.
The Rovo MCP surface is built for record-level and knowledge-level interaction: search, read, create, comment, transition. That covers a large share of what a practical Atlassian agent does day to day. The gaps show up the moment an agent needs to configure the org, move data in volume, or react to something happening.
Two gaps matter more than the rest. The first is administration. An agent that provisions a project, creates a custom field, or edits a permission scheme has no path through Rovo MCP, and that is not a missing tool; it reflects what the server was scoped to do.
The second is events. If your agent needs to react when an issue transitions or a page changes, that requires the REST path. Jira lets Connect and OAuth 2.0 apps register dynamic webhooks at /rest/api/3/webhook with a JQL filter, and those registrations expire after 30 days unless you call the extend operation. Rovo MCP has no event subscription surface at all, so an MCP-only agent polls or waits.
This is where Atlassian breaks the pattern set by other hosted MCP servers. OAuth 2.1 is the primary and recommended mechanism, with an interactive consent flow scoped to the user's existing Atlassian permissions. But Atlassian also documents authentication via API token for non-interactive clients, using either a personal API token over Basic auth or a service account API key over Bearer auth.
That single fact removes the usual "MCP cannot run headless" objection. It replaces it with a subtler one.
Authentication method and capability are coupled on this server, which is unusual and easy to miss until a tool call returns nothing. Jira Service Management and Bitbucket Cloud tools are available only on API token sessions. Compass tools are available only over OAuth 2.1. Some Compass tools are disabled entirely under API token auth because the required product scopes cannot currently be granted to personal API tokens or service account keys.
The practical consequence: there is no single credential that reaches all five products through Rovo MCP. An agent that needs Compass and Bitbucket together needs two connections with two different auth types, or it needs the REST path for one of them.
Atlassian publishes three limitations on the API token path, and each one is a production concern rather than a footnote. Tool availability shrinks, as above. Tokens are not bound to a specific cloudId, so clients must pass the correct site ID on every call; that enables cross-site workflows and also means a wrong parameter writes to the wrong Atlassian site. And because there is no OAuth redirect, redirect-based domain allowlist checks cannot run, so API token traffic is governed only by your IP allowlist.
There is an identity cost on top of the three limitations. A service account API key is a shared credential, so every action the agent takes is attributed to the service account rather than to the engineer who triggered it, and the audit trail your security team reviews shows a machine name.
Service accounts are also typically provisioned generously for convenience, which gives the agent more reach than any individual user has. What the user cannot do, the agent should not be able to do; a shared service account inverts that principle by default. This is exactly the kind of issue covered in depth when thinking about credential ownership across agent tool-calling patterns.
On the MCP path, Atlassian owns hosting, tool schemas, and permission enforcement. Access is granted only to data the authenticated identity can already see, and project roles, issue security levels, and space restrictions all hold. Admins control which client domains may connect, and MCP usage logs give visibility into how AI is touching Jira and Confluence. That is a genuine governance advantage, not marketing.
What you still own on the MCP path: per-user token storage, refresh, revocation, tenant isolation, and the admin dependency itself. API token authentication has to be switched on by an organization admin in Atlassian Administration before any headless client works, and Bitbucket tools additionally require the workspace to be linked to an Atlassian organization.
On the REST path, Jira Cloud enforces three independent rate-limiting systems simultaneously, with enforcement of the newest one live since March 2, 2026. Your agent has to handle all three, and each returns a different RateLimit-Reason header on a 429.
Two details matter for agent design. Reads cost points per object returned, so a wide JQL search is far more expensive than a single issue fetch; identity reads such as users and groups cost 2 points per object rather than 1. And API token traffic is explicitly excluded from the points model, remaining governed by the existing burst limits. Full detail is in the Jira Cloud rate limiting guide.
Atlassian publishes no rate-limit numbers for the Rovo MCP endpoint. Not in the auth docs, not in the troubleshooting guide, not in the server repository. Issue 171 on Atlassian's official MCP server repository reports 429 responses after roughly 20 parallel calls, with only a Retry-After header and none of the X-RateLimit-* headers the REST documentation describes.
Atlassian also has not documented how MCP tool calls interact with the tenant's points-based quota, so if you are running both paths you cannot currently model combined consumption. For a deterministic pipeline where an unplanned throttle is an incident, that is a real argument for REST. Understanding why MCP can be more expensive than CLI is relevant context here.
Two Teamwork Graph tools, getTeamworkGraphContext and getTeamworkGraphObject, are in beta and free today. Atlassian's supported tools page states that when they reach general availability they will be billed at a minimum of 1 Rovo credit per call, with calls involving AI inferencing or multi-step graph queries billed higher, and at least 90 days of notice before charges take effect.
If your agent's differentiator is cross-product context traversal, that is a per-call cost line that does not exist on the REST path. Model it before you build the product around it.
Both lists below are specific to Atlassian rather than generic MCP advice, because the deciding factors here are Atlassian's own constraints.
Use the Atlassian Rovo MCP Server when:
Use the Atlassian Cloud APIs directly when:
Recommended Reading: for product-level depth, see Build an Engineering Standup Agent - GitHub, GitLab, Jira, Slack and explore how agent tool observability applies across both paths.
Whichever path you choose, a multi-tenant Atlassian agent ends up holding one credential per user. Rovo MCP's OAuth 2.1 flow gives you a token per user. The REST path's 3LO flow gives you a token per user. Neither path gives you a vault, rotation logic, or a revocation flow.
Take a realistic shape: 60 engineers across 5 customer organizations, each with their own Atlassian account. That is 60 access tokens to store encrypted and isolated per tenant, 60 refresh tokens to rotate, and 60 grants to revoke on offboarding. Multiply by connector if the agent also touches Bitbucket or Jira Service Management on a separate credential.
Atlassian uses rotating refresh tokens. Every refresh returns a new refresh token and disables the one you just used. Store the old one and your next refresh fails with invalid_grant. Run two agent threads that refresh concurrently and one of them races the other into the same failure.
Each new refresh token is valid for 90 days, so an integration that sits idle past that window forces the user back through consent. Access tokens last roughly an hour, which means a long-running job refreshes mid-run whether you planned for it or not. On the API token path, personal tokens are capped at one year, so every token you issue has a dated failure. This is precisely why handling token refresh for AI agents requires dedicated infrastructure rather than ad hoc code.
Scalekit's Atlassian connectors handle the OAuth flow, per-tenant encrypted token storage, rotating-refresh handling, and revocation for both paths, so the MCP versus API decision does not change what you build at the credential layer. Credentials never touch the agent runtime or the LLM context; the agent calls a tool, gets a result, and never sees a token.
Scalekit ships both paths as first-class connectors, which is why the decision above stops being an infrastructure decision and becomes a capability decision. The setup differs slightly between them, and the difference is worth knowing before you start.
The Atlassian Rovo MCP connector proxies the official Rovo MCP server over OAuth 2.1 with Dynamic Client Registration. The Jira connector wraps the Jira Cloud REST API over OAuth 2.0 (3LO), with sibling Confluence, Jira Service Management, and Bitbucket connectors for the other surfaces. The marketing overview lives on the Atlassian Rovo MCP connector page.
One structural note that follows directly from the auth analysis above: because the Rovo connector authorizes over OAuth 2.1, and Bitbucket Cloud and Jira Service Management tools are only available on API token sessions, the atlassianmcp tool list contains no Bitbucket or JSM tools. It covers Jira, Confluence, Compass, Teamwork Graph, and search. For Bitbucket or JSM, the delegated path is the dedicated REST connector.
Atlassian Rovo MCP uses Dynamic Client Registration, so there is no client ID or secret to create. In the Scalekit dashboard, go to AgentKit, then Connections, then Create Connection, find Atlassian Rovo MCP, and copy the redirect URI. Then in Atlassian Administration, open Rovo, Rovo access, Rovo MCP server, select the Domains tab, and add that redirect URI as an allowed domain. Organization admin access is required.
After that, Scalekit registers the OAuth client through DCR and handles token management for every user who authorizes. Install the SDK and authorize a user:
The connection_name string is the single most common integration error. If it does not match the dashboard exactly, the call fails with a connection lookup error rather than an auth error, which sends people debugging the wrong layer.
Before showing the agent loop, it is worth being precise about what happens next. The agent is not loading the connector catalog. It is loading the tools this specific user's connected account is authorized to call, filtered further to the subset this agent role needs. That distinction is what separates a per-user agent from a shared-credential agent.
It matters numerically too. The Rovo connector publishes 39 tools. At roughly 200 tokens each, handing all of them to the model burns close to 8,000 tokens before the agent does any work, and the model is picking from a decision space it handles badly at that size. Scoping to six tools cuts the overhead by roughly 85%. The fix is not better prompting. It is surface reduction.
actions.langchain.get_tools() returns native StructuredTool objects, so there is no schema reshaping between Scalekit and LangChain. Bind them and run the loop.
One Atlassian-specific detail belongs in the system prompt rather than the code: Atlassian documents getAccessibleAtlassianResources as the required first call, because tool calls need a cloudId. Tell the model that explicitly or it will guess.
Every one of those calls resolves the authorizing user's Atlassian credential server-side. The transition shows up in Jira's history as that engineer, and the issue security levels and project permissions that apply to them apply to the agent. For a deeper look at how LangChain tool calling works and where it stops, see LangChain Tool Calling: How It Works, Where It Stops, and How Scalekit Completes It.
When the agent needs boards, attachments, or administration, the same identity model runs over the REST connector. Here it is with the Anthropic SDK, scoping the surface the same way.
listScopedTools returns schemas already shaped as input_schema, which is the exact format Anthropic's tool use API expects. The loop below is complete: message construction, the messages.create call with tools, the stop_reason check, tool result construction, and the message append.
The capability table above lists webhooks as REST-only. That is still true, and it is the case where a prebuilt tool catalog would normally stop being useful. actions.request proxies a raw authenticated call through the same connected account, so the credential model does not change just because the endpoint is unusual.
Scalekit resolves the Jira {{cloud_id}} in the path from the connected account configuration, so you write the site-relative path and nothing else.
The Python equivalent is actions.request(connection_name=..., identifier=..., path=..., method=...), which returns the raw response object.
Most real Atlassian agents are not Atlassian-only. A release-notes agent reads Jira and writes Confluence. An incident agent reads Jira Service Management, checks Compass ownership, and posts to Slack. The moment there is more than one connector in play, the tool surface and the credential isolation problem both get worse at the same time.
Virtual MCP Servers address both. You declare exactly which connections and which tools a given agent role can see, and you get one static mcp_server_url that serves every user. There is no MCP server to deploy, host, or maintain.
Create the configuration once, not once per user. Tool names come from each connector's tool list in the docs or from AgentKit, Catalog in the dashboard.
The agent now has four tools. Not 39 from the Rovo connector, not the full Confluence catalog, and no ability to transition an issue or delete a page regardless of what a prompt asks it to do. What you leave out never reaches the model, so no prompt injection can call it.
Runtime is two steps: confirm the user's connections are still active, then mint a short-lived token bound to that user. Never reuse a token across runs.
Set the expiry longer than the expected run duration. The endpoint is static; the identity is per-user.
The active-connection check is not boilerplate here. Atlassian refresh tokens rotate on every use and expire after 90 days of inactivity, and a user can revoke a grant at any time from their Atlassian account. Checking before the run turns a mid-task failure into a re-auth prompt, which is the difference between an agent that looks broken and an agent that asks for permission.
It also closes the service account question. If you were tempted to run headless Rovo MCP on a shared service account API key, the alternative is a Virtual MCP server with a per-user session token minted before each scheduled run. Same headless execution, correct per-user attribution, no shared credential.
Atlassian gives you good visibility into its own boundary. MCP usage logs show how AI clients are interacting with Jira and Confluence, and organization audit logs capture Atlassian-side events. That covers what happened inside Atlassian.
They cannot tell you which of your agents made the call, which end user in your product triggered it, which tool the model selected, or why an authorization failed before the request ever left your infrastructure. When an agent posts a comment to the wrong issue at 3am, "a token belonging to this user did it" is where the Atlassian trail ends.
They also cannot correlate across connectors. If the agent read Jira, checked Compass, and posted to Slack in one run, that is three separate audit systems with no shared identifier. This is the gap that makes audit trails for agent auth in B2B SaaS a first-class infrastructure concern.
Scalekit logs every tool call at the auth layer: who triggered it, which tool ran, which connected account resolved, and what came back. Because the log is keyed on the connected account rather than the raw token, every entry links back to the authorization event that created it, and the trail is exportable to Datadog, Splunk, or any SIEM without instrumenting your agent code.
That is what makes the debugging loop tractable. A 429 from Atlassian, a revoked grant, and a scope the user never consented to all look identical from inside the agent runtime. They look completely different in the auth log.
The question that decides it is not whether your agent runs headlessly, because Rovo MCP can. It is whether the work your agent does lives at the record layer or above it.
If your agent is interactive and user-present, and its job is finding, reading, authoring, and moving work items, build on the Atlassian Rovo MCP Server. Atlassian maintains the tool schemas, the permission model is already enterprise-grade, and Rovo's semantic search plus Teamwork Graph traversal give you capabilities that have no REST equivalent.
If your agent administers the org, touches attachments or boards, reacts to events through webhooks, moves data in volume, or needs Bitbucket and Jira Service Management on the same delegated credential, build against the Atlassian Cloud APIs. The MCP ceiling there is architectural, and the undocumented rate limits make it a poor foundation for a deterministic pipeline.
Most production Atlassian agents end up on both, with the interactive assistant on Rovo MCP and the scheduled pipeline on REST. The token type differs. The credential management infrastructure required does not, and that is the part that needs a production-grade answer before either path ships. The secure token management for AI agents at scale problem is the same regardless of which surface you choose.
If you are building on either path and want to compare notes on Rovo MCP's auth coupling, the undocumented throttling, or per-user credential isolation at scale, join the Scalekit Slack community. If you need an answer today, talk to an engineer.
Browse the Scalekit Atlassian Rovo MCP connector or read the connector documentation.
