Atlassian MCP: set up Jira and Confluence access

A Jira issue and a Confluence page may belong to the same organization while having different access permissions. Treat them as two test cases when setting up MCP. This guide separates site selection, authorization and individual read operations. Prepare a known test issue and a non-sensitive test page. Record their complete URLs so that a similarly named result from another site cannot accidentally count as a successful test.

Verify endpoint and authorization at the source

The Atlassian instructions accessed for this guide specify https://mcp.atlassian.com/v2/mcp for the connection. They describe OAuth and an optional API-token path. Follow the instructions for your intended client and check the endpoint version when reviewing an older configuration. A server status listed in the registry is not a live availability measurement of this endpoint. The client response and documented authorization flow establish what happened during your connection attempt.

Compare the configuration format with the client overview. The Atlassian registry search finds projects using that term; the Jira search may uncover further implementations. Check the publisher and project source in each case. A local third-party package and the provider’s remote service do not automatically expose the same tools.

Identify the site and resource precisely

Before connecting, open both resources directly in a browser with the same account. If direct access already fails, resolve that access first. If both resources are accessible directly but only one appears through MCP, record the outcomes separately. Avoid changing every permission as a precaution. Instead, identify the exact operation and resource used in the failed step. That distinction keeps a narrow permission problem from turning into an unnecessary full reinstall.

Test Jira and Confluence independently

1. Record the client version, site and intended account. Prepare a separate expected response for each product.

2. Complete authorization and inspect the available tools. Compare the configured endpoint with current provider instructions.

3. Read the test issue first, then the test page. For each, compare URL, identifier and selected content with the direct view.

4. Record both results individually. Test edits, comments or new issues later using dedicated test objects.

Diagnose failures without unnecessary changes

Atlassian states that access respects the user’s existing permissions. Successful authorization therefore does not independently expand project or space access. Use troubleshooting for HTTP errors. If only search is empty, try retrieving a known resource directly when an available tool supports that operation. Record whether the tool list itself is missing or the individual operation fails after tools have already been discovered.

Does an active registry status prove availability?

No. It describes a source declaration. Check the current connection in your own environment.

Does a Jira read establish Confluence access?

No. Test both resources separately, even when they belong to the same site.

Can I immediately create comments?

A read test does not establish writing. Use a dedicated test issue and inspect the saved comment.

What belongs in the test record?

Site, resource, client version, operation, time, expected result and observed result. Keep credentials out of the record.

Provider documentation accessed on 1 October 2026. Test procedures are editorial suggestions.

1. Atlassian: Get started with the MCP server
   Show retrieval command

   curl -s https://support.atlassian.com/atlassian-ai-gateway/docs/get-started-with-the-atlassian-remote-mcp-server/

All posts