Atlassian Cloud

For: tenant administrators and plugin users.

Connect Jira, Confluence and Jira Service Management on Atlassian Cloud through Atlassian's Rovo MCP server. The connector uses your tenant's own OAuth client.

An Orchestrator Zero connector that wraps Atlassian's remote MCP server (Rovo, https://mcp.atlassian.com/v2/mcp): two tools on the same server, atlassian on the connection atlassian-cloud (a person's OAuth sign-in) and atlassian_jsm on the connection atlassian-cloud-jsm (a service account's API key, because Rovo's JSM tools take no OAuth sign-in), and one delegate agent, atlassian, that other plugins hand their work on Atlassian Cloud to. For Jira and Confluence Data Center, use atlassian-dc.

Sources, read 2026-10-17: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/getting-started-with-the-atlassian-remote-mcp-server/, https://support.atlassian.com/atlassian-rovo-mcp-server/docs/supported-tools/, https://support.atlassian.com/atlassian-rovo-mcp-server/docs/configuring-authentication-via-api-token/, https://github.com/atlassian/atlassian-mcp-server and the server's own OAuth metadata (https://mcp.atlassian.com/.well-known/oauth-protected-resource/v2/mcp).

Functions

Every function takes the site's cloudId, which getAccessibleAtlassianResources lists.

Rovo lists more (Bitbucket, Loom, Goals, deletes, the Teamwork Graph). The connections give those no token, so they cannot run; a new version of this connector pins more when a job needs them.

Connect it

Jira and Confluence (atlassian-cloud). Rovo's sign-in is OAuth 2.1 with PKCE at auth.atlassian.com. Atlassian documents no developer-console app for Rovo; its authorization server takes a client ID metadata document, a JSON file the tenant hosts at an https:// URL of its own, whose URL is the client ID. Orchestrator Zero registers no client at Atlassian.

1. Host a client ID metadata document (for example at https://oz0.example.com/oauth/atlassian.json):

   {"client_id": "https://oz0.example.com/oauth/atlassian.json", "client_name": "Orchestrator Zero",
    "redirect_uris": ["<the redirect URL `oz0 connection start atlassian-cloud` shows>"],
    "grant_types": ["authorization_code", "refresh_token"], "response_types": ["code"],
    "token_endpoint_auth_method": "none"}
   

   A client ID Atlassian issued you works the same way.
2. An org admin allows the edge's domain under Atlassian Administration, Rovo, Rovo MCP server (domain controls).
3. Connect:

   oz0 connection set atlassian-cloud --param client_id=https://oz0.example.com/oauth/atlassian.json
   oz0 connection start atlassian-cloud   # opens Atlassian's sign-in; the edge keeps and refreshes the token
   

The scopes asked for are read:me, read:, write: and search:jira:agent-interface, the same three for Confluence, search:rovo:agent-interface and offline_access; never delete: or manage:jira:agent-interface. Each person's token can do what that person can do in Jira and Confluence, no more.

JSM Operations (atlassian-cloud-jsm). Rovo's JSM tools take only an API token.

1. An org admin allows API tokens under Atlassian Administration, Rovo, Rovo MCP server, Authentication.
2. Create a service account with the JSM Operations scopes and an API key for it.
3. oz0 connection start atlassian-cloud-jsm opens the edge's page, where you paste the key. It is kept as the tenant secret ATLASSIAN_CLOUD_JSM_API_KEY and sent only to Rovo's host.
4. The JSM tool's functions join the plugin's tool snapshot when they first list, as the OAuth tool's did, so they need no approval of their own; a listing that changes after that waits for oz0 plugin approve-tools atlassian, like any function whose listing changed.

Both tools reach only mcp.atlassian.com; the edge's sign-in and refreshes reach only auth.atlassian.com.

Develop and re-pin

uv lock && uv sync                        # the tests' dependencies; the connector runs no code of its own on nodes
uv run pytest                             # the contract tests, against the fake in tests/fake_server.py
uv run python tests/snapshot.py --check   # the pinned snapshots match the fake's listing
oz0 plugin lint --verified .              # the house rules, as verified plugins are held to them
oz0 plugin test .                         # the delegate's eval, from its recorded answer

The snapshots were written from Atlassian's documented tool list; the input schemas, descriptions and hints in tests/rovo_tools.json are this project's until someone with an Atlassian account saves Rovo's own listing (POST https://mcp.atlassian.com/v2/mcp?tools=all, tools/list, once with the OAuth sign-in and once with an API key) and writes the snapshots from it: uv run python tests/snapshot.py --write --from listing.json --auth oauth --listed-from "<where>, read <date>". Then change tests/rovo_tools.json to match and review the difference.

Limits

• Writes ask a person by default, through the plugin's suggested policy, which an admin may switch with a reason: createJiraIssue, editJiraIssue, addOrEditJiraIssueComment, transitionJiraIssue, createConfluenceContent, updateConfluenceContent, createConfluenceComment and updateJsmOpsAlert. Up to 1.0.0 they were under requires_approval; an update from it keeps asking about each until an admin switches it.
• The AI label: Rovo reads nothing Orchestrator Zero sends beside the call, so the node puts the tenant's label at the start of the text people read, after the approval: createJiraIssue's description, addOrEditJiraIssueComment's comment, createConfluenceContent's and updateConfluenceContent's body, createConfluenceComment's comment and updateJsmOpsAlert's note. With the tenant's label turned off, everything is posted as written.
• Not labelled: text that editJiraIssue and transitionJiraIssue set. Both take an issue's fields as one open object (fields), and the label can only be pointed at a text argument the server's listing names, so a new description or summary set through them is posted without the label. Both ask a person by default, who sees the text as it will be posted. To have an issue's description labelled, have the agent create the issue (createJiraIssue) or comment on it (addOrEditJiraIssueComment) rather than rewrite its fields.
• Rovo credits: atlassian.search spends the tenant's Rovo credits, from the organisation's shared pool. Atlassian documents 1 to 10 a call and reports none, so each successful call is counted as 10 credits on the job's usage, where budgets see it. Other Rovo tools that spend credits (the Teamwork Graph, Confluence infographics) are not pinned.
• Results: getAccessibleAtlassianResources, searchJiraIssuesUsingJql, getJiraIssue, listJiraIssueTransitions, searchConfluence, getConfluenceContent and getJsmOpsAlerts have declared output schemas, which the node checks a structured result against; if Rovo answers one of them in text only, it stays text. The other functions answer in text.
• Writes are not safe to repeat: Rovo takes no idempotency key, so a retried addOrEditJiraIssueComment comments twice. A transition made twice is one change. The platform makes each write once.
• A call over Atlassian's rate limit (HTTP 429) is not made. A read is called again after the wait Atlassian asks for, once your tenant approved the listing; a write is not tried again by the platform: the agent reads an error that says it is retryable and how long Atlassian asks to wait.
• JSM: the API key must be a service account's, sent as a bearer token. A personal API token (Basic email:token) is not supported, because a connection's token goes in Authorization: Bearer. Rovo's JSM tools are Operations only (alerts, on-call, teams): service requests are Jira issues, read and commented on with the atlassian tool.
• The client: no dynamic client registration. The tenant brings a client ID metadata document's URL or a client ID Atlassian issued; Atlassian's domain controls must allow the edge's callback domain.
• Region: Rovo has one endpoint, mcp.atlassian.com, and documents no regional one, so calls do not stay in an EU region by choosing a host. Where the data is processed is Atlassian's to say.
• Installing or updating runs the delegate's eval as the quality gate, on the tenant's own models (one model call per case), not from its recorded answer.
• Tested against a fake of Rovo's server, shaped from Atlassian's documentation, not against the live service. "Verified" means this project tested, pinned and secured the connector; Atlassian does not endorse it.