Skip to main content
Connect your Atlassian Cloud site to let CloudThinker agents search Jira issues and Confluence pages, read the ticket behind a code change, and create or update issues and pages through your approvals. One connection covers both Jira and Confluence: it signs in with OAuth through the Atlassian MCP server (formerly Rovo MCP Server) and acts with the permissions of the person who authorizes it.

​
Prerequisites

  • A CloudThinker workspace on the Scale plan or above. On lower plans the button reads Upgrade to Connect.
  • An Atlassian Cloud site with Jira, Confluence, or both.
  • An Atlassian organization admin for the one-time domain step, if your organization hasn’t done it yet.
  • The Atlassian MCP server (formerly Rovo MCP Server) available on your organization. If Connectors → Atlassian MCP server doesn’t appear in Atlassian Administration, sort that out with Atlassian first.
  • Permission to manage connections in your CloudThinker workspace.
This connection doesn’t reach Jira Service Management alerts or on-call schedules. Atlassian only exposes those through an API token, so they have their own Jira Service Management connection.

​
Setup

1

Allow the CloudThinker domain in Atlassian

An organization admin goes to admin.atlassian.com, opens Connectors → Atlassian MCP server, and clicks Add domain. Enter:
Type it exactly. The /** wildcard allows every CloudThinker callback path under that domain.
Atlassian Administration, Rovo MCP Server page, with https://app.cloudthinker.io/** listed under Your domains
Success state: the domain appears in the list of allowed domains. You only do this once per Atlassian organization.
2

Start the connection in CloudThinker

In the sidebar, click More → Workspace settings → Connections, stay on the Builtin Connections tab, select Atlassian, and click Connect. Atlassian opens in a new window. If your browser blocks it, a dialog appears instead: click Open Atlassian.
3

Authorize access

Sign in with the Atlassian account agents should act as, pick the site, and approve access. The window closes on its own.Success state: Atlassian shows a Connected status in CloudThinker.

​
Connection details

There are no fields to fill in. Atlassian issues the OAuth tokens and CloudThinker stores them. A workspace holds one Atlassian connection. To switch accounts, disconnect it and connect again with the other account.

​
Required permissions

  • Organization admin, once, to add the CloudThinker domain.
  • After that, agents see and change only what the authorizing account can in Jira and Confluence. If that person can’t open a project or space, neither can the agent.
Authorize from a dedicated Atlassian account that belongs only to the projects and spaces agents need. Connecting with a personal account ties the connection to that person’s access and job. The dedicated account needs Jira and Confluence product access, so it counts as a user on your Atlassian plan.

​
Agent capabilities

Changes go through Approvals. The Atlassian MCP server doesn’t expose Jira automation rules, board settings, or Confluence space permissions, so agents can’t review those. Other parts of CloudThinker use the same connection:

​
Verify the connection

Expect your projects by key with a few recent issues. If a project is missing, the authorizing account can’t open it. In prompts, “me” and “I” mean that account, not the person chatting.

​
Example prompts

The last prompt creates an issue, which counts as a change in Jira. Every change an agent makes goes through your workspace’s Approvals first. On the default Auto · Rules + AI · Ask me mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on Rule enforcement for your workspace. Choose Manual to approve every change yourself.

​
Troubleshooting

Your CloudThinker plan doesn’t include the Atlassian connection. It needs the Scale plan or above. See Pricing.
The CloudThinker domain isn’t allowed in your organization. Ask an organization admin to check Connectors → Atlassian MCP server and confirm https://app.cloudthinker.io/** is in the list of allowed domains, then click Connect again.
Your organization enforces an IP allowlist. Those rules are managed in Atlassian Administration, separate from the MCP server settings, and apply to these requests too. Have your admin add CloudThinker’s egress IP addresses to that allowlist. These docs don’t publish CloudThinker’s egress IP list: ask your CloudThinker contact, or contact us.
The OAuth grant expired or was revoked, or the authorizing account was deactivated, for example when that person left. Reconnect Atlassian from More → Workspace settings → Connections, ideally with a dedicated account. The account owner can also revoke the grant in their Atlassian profile under Connected apps.
Agents act as the authorizing account. Give that account access to the project or space in Atlassian, then ask again. No reconnect is needed.
That’s expected. Alerts and schedules need the separate Jira Service Management connection.

​
Security

  • Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
  • Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
  • Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
  • Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.
  • User-bounded access: every read and write runs as the authorizing account, so its Jira and Confluence permissions are the real limit.
  • Domain control stays with you: an organization admin can remove the CloudThinker domain from the Atlassian MCP server page at any time to cut off access.

Jira Service Management

Add alerts and on-call with a separate API token connection.

Resolve Triggers & Outcomes

Turn on Jira follow-up tickets and Confluence postmortems.