How to set up the Atlassian MCP server

Atlassian MCP exposes the Jira and Confluence content that the authorized Atlassian account can access. OAuth is the recommended user-delegated method; use an API token only for an approved non-interactive client.

This is the vendor-side setup guide for Atlassian's hosted MCP server. It prepares Jira and Confluence for any compatible MCP client. The Atlassian agent template comes afterwards; it deploys the Dome workspace, agent, model, tools, and rules, but it does not create the Atlassian authorization described here.

Choose a connection method

Choose OAuth when the connection should follow an Atlassian user's Jira and Confluence access. Choose an API token only for a named non-interactive identity where the client cannot use OAuth. Atlassian's remote MCP setup guide documents the current endpoint and client requirements.

Prepare these prerequisites before configuring the vendor-side MCP server.

• Prepare a test Jira project, a test Confluence space, and a test Atlassian account with access only to those resources.
• Use OAuth 2.1 for interactive access, authenticated as the person whose Jira and Confluence permissions should apply.
• Use Atlassian's API-token path only when the MCP client cannot complete OAuth, and only with a deliberately owned, narrowly permissioned service identity.

Allow the MCP client at the Atlassian site

Complete these organization-level requirements before authorizing the MCP client.

• Ask an organization administrator to allow the MCP client redirect URL before a user starts consent.
• For Dome, allow this exact URL for the target *.atlassian.net site:

https://api.domesystems.ai/oauth/callback

• In Atlassian Administration, follow the site's MCP or OAuth consent policy to add the redirect URL and permit the client domain.
• If your organization restricts which AI tools may use Atlassian MCP, also allow the client domain under that policy.
• Treat this as a site-level control: starting OAuth as an end user cannot bypass it.

Recommended: Authorize through OAuth

1. Configure your MCP client with Atlassian's current hosted MCP endpoint from the Atlassian MCP setup guide.
2. Start the OAuth flow and sign in as the dedicated Atlassian test user.
3. Select the intended *.atlassian.net site when Atlassian asks for a site.
4. Review the consent screen. It should reflect the test user's existing Jira project and Confluence space access; OAuth does not make that account an administrator.
5. Complete consent and retain the authorization only for the client that needs it.

Alternative: API token for a non-interactive client

If OAuth is unavailable in the client, create an Atlassian API token for a dedicated, least-privileged account. Follow Atlassian's API-token MCP instructions exactly, including its required authorization header format. Do not substitute a personal administrator token: the API-token route grants the MCP server the same access as its owner.

• Open the vendor's credential documentation as the dedicated least-privileged identity.
• Create a named credential for the intended test workspace, project, organization, or account—never reuse an owner or administrator credential.
• Select the minimum scopes, repositories, projects, or resources the MCP server needs; begin read-only whenever the product supports it.
• Copy the secret once into the MCP client's secret store, record its owner and rotation date, then test both an allowed record and a denied boundary.

Verify Atlassian MCP

Use this checklist to confirm the MCP server is connected with the intended access.

• Connect the MCP client using the approved OAuth grant or dedicated API token.
• Confirm that Jira and Confluence MCP tools are discovered.
• Search a known issue and a known Confluence page in the test project and space.
• Try to read an issue or page outside that scope; it should be unavailable.
• Confirm that the test account has no project-administration or Confluence-space-administration permissions.

Troubleshooting

If the setup does not work as expected, check these common causes.

• If the consent screen says that an organization administrator must authorize the redirect URL, the callback has not been allowlisted for that site.
• If consent works but expected Jira or Confluence content is absent, check the test user's product and project/space permissions before changing authentication.
• Consult Atlassian's OAuth 2.1 configuration guide and MCP troubleshooting guide for current endpoint and policy changes.

Next steps

Deploy the Atlassian agent template to create a governed agent in Dome that can work with the approved Jira and Confluence resources, with the template's included model, tools, and rules.