Jira MCP Setup: Connect Atlassian OAuth and Start Read-Only
Use Atlassian’s official remote v2 Jira MCP endpoint, https://mcp.atlassian.com/v2/mcp, with OAuth 2.1. Confirm the Jira site and project, verify search and issue reads, and keep creation, transitions, and updates gated until the connected user’s permissions and administrator-controlled domain and IP policies are understood.
Use Atlassian’s official remote v2 Jira MCP endpoint, https://mcp.atlassian.com/v2/mcp, with OAuth 2.1. Confirm the Jira site and project, verify search and issue reads, and keep creation, transitions, and updates gated until the connected user’s permissions and administrator-controlled domain and IP policies are understood.
Table of contents
- Which Jira MCP server should you use?
- How do you connect the official Atlassian endpoint?
- How do you choose the correct Jira site and project?
- How do you verify issue search and reads first?
- How do you gate issue creation, transitions, and updates?
- How do you fix OAuth, domain, permission, and stale-endpoint failures?
- FAQ
Which Jira MCP server should you use?
Use Atlassian’s official remote v2 server at https://mcp.atlassian.com/v2/mcp and authenticate with OAuth 2.1. For a practical reference, see MCPtrove’s Atlassian Rovo MCP server entry.
The official server is the appropriate starting point because it is designed for Atlassian access and follows the connected user’s Jira permissions. It also operates within organization-level IP allowlists and allowed-domain settings. Read the Atlassian MCP security and access guidance before enabling actions that can change Jira data.
| Choice | Use it when | First check |
|---|---|---|
| Official v2 endpoint | You want the current Atlassian connection | OAuth 2.1 and the intended Jira site |
| API-token authentication | An administrator has deliberately enabled this advanced option | Admin approval and token handling |
Legacy /v1/sse endpoint | Not for new connections | Replace it with /v2/mcp |
OAuth 2.1 is the recommended default. API-token authentication is an administrator-controlled advanced option, so it should not be treated as the normal setup path. New connections use Streamable HTTP at /mcp; the legacy /v1/sse endpoint stopped being supported after June 30, 2026. The official Atlassian MCP documentation provides the current endpoint context.
How do you connect the official Atlassian endpoint?
Connect by adding https://mcp.atlassian.com/v2/mcp to an MCP-compatible client, then complete the Atlassian OAuth 2.1 authorization flow. Use Streamable HTTP at /mcp, not the retired /v1/sse path.
- Open the remote-server configuration in your MCP client.
- Add the official endpoint exactly as supplied.
- Select OAuth 2.1 when the client presents authentication choices.
- Sign in with the Atlassian account that should perform the Jira work.
- Approve access only after confirming the account, organization, and intended Jira site.
- Return to the client and confirm that the connection is available.
Do not invent command-line flags or substitute a local URL. The setup depends on the client’s own remote MCP configuration, so follow its connection form while preserving the official endpoint. If you use Claude, the Claude MCP client guide is the practical next step for client-specific configuration.
Atlassian’s OAuth 2.1 settings documentation explains the administrator-side controls. If OAuth is not offered, or the authorization page rejects the connection, check those controls before changing the endpoint.
How do you choose the correct Jira site and project?
Choose the Jira site and project that match the work you intend to read or change, and confirm both before using any write-capable action. The connected account must also have access to that site and project.
Use this short checklist:
- Confirm the Atlassian organization and Jira site.
- Confirm the project name and project key.
- Confirm that the signed-in account is the intended account.
- Start with a project where a known issue can be read.
- Keep separate sites and projects distinct when the account can access more than one.
The site answers “which Jira environment?” The project answers “which work area?” Treating them as interchangeable can produce a valid OAuth connection pointed at the wrong destination. The official server respects the connected user’s Jira permissions, so successful authentication does not mean every project or issue is available. Atlassian describes these access boundaries in its MCP security and access documentation.
How do you verify issue search and reads first?
Verify read access by searching for a known issue and then opening that issue from the result before attempting any write. Confirm that the returned site, project, issue key, summary, and status match your expectation.
A read-first sequence is:
- Search within the intended Jira site or project for a known issue.
- Select one result and read its details.
- Compare the issue key and project with the task you intended to perform.
- Repeat with a second known issue if the account spans multiple projects.
- Record any missing fields, denied access, or unexpected project context.
Do not infer Jira access from OAuth approval alone. MCP separates the host, client, and server, so the client may be connected while the server still enforces Jira permissions and organization policy. The MCP architecture documentation explains those roles and helps clarify where a connection problem may occur.
For client configuration issues, MCPtrove’s Config Doctor can be the next practical check after the endpoint and account have been confirmed.
How do you gate issue creation, transitions, and updates?
Gate issue creation, transitions, and updates behind deliberate approval, and enable them only after read verification and permission checks succeed. Keep the initial workflow read-only until the intended Jira site, project, and account are confirmed.
Use separate gates for each action:
- Create: confirm the target project, required fields, and the connected user’s permission.
- Transition: confirm the issue, desired workflow state, and permission to move it.
- Update: confirm the exact issue and fields that may change.
- Bulk work: require an explicit scope and approval before applying changes across issues.
The official server does not replace Jira’s own authorization model. The connected user’s Jira permissions, organization IP allowlists, and allowed-domain settings continue to matter. For broader guidance on access boundaries and consent, see MCPtrove’s MCP security guide and the MCP security best practices.
A successful read proves that a resource can be viewed. It does not by itself justify changing that resource. Treat each write as a separate decision with a clear target and an accountable user.
How do you fix OAuth, domain, permission, and stale-endpoint failures?
Fix failures by checking the endpoint version, OAuth 2.1 configuration, intended site, user permissions, and administrator domain or IP restrictions in that order. Replace any stale /v1/sse connection with https://mcp.atlassian.com/v2/mcp using Streamable HTTP.
| Symptom | Likely check | Corrective action |
|---|---|---|
| OAuth does not start | Client endpoint or OAuth settings | Confirm the v2 endpoint and administrator OAuth 2.1 settings |
| Site or project is missing | Account scope or Jira permissions | Sign in with the intended account and confirm access |
| Domain or network denial | Allowed-domain or IP allowlist policy | Ask the administrator to review the applicable control |
Connection uses /v1/sse | Stale configuration | Replace it with /v2/mcp |
| Reads succeed but writes fail | Jira action permission | Keep the workflow read-only and verify the required permission |
Do not disable TLS, authentication, or permission checks to make a connection succeed. If the client retains an old configuration, remove that stale entry through the client’s normal settings and add the current endpoint. When the endpoint and account are correct but access remains denied, the administrator controls described in Atlassian’s security and access guidance are the relevant place to investigate.