Jira (Atlassian Cloud)

Slug jira-oauth
Category ITSM / Collaboration
Maturity Beta
Auth Type OAuth 2.1 (3LO, authorization code + PKCE) — with Atlassian scoped API token fallback for headless / CI

Summary

This integration is a dynamic MCP proxy, not a static-tool plugin. Strike Construct connects to the upstream Atlassian Cloud MCP gateway, discovers tools via tools/list at startup (and periodically thereafter), and forwards tools/call requests transparently while managing the OAuth 2.1 token lifecycle. The set of tools advertised to a Prospector Studio agent matches whatever Atlassian's gateway publishes for the connected account — typically Jira (issues, projects, boards, sprints), Confluence (pages, spaces, search), and Compass (components, scorecards, dependencies).

Tools are exposed under a jira_* prefix (e.g. upstream search_issues becomes jira_search_issues) to avoid collisions with similarly-named tools on other plugins.

This integration is read-write for any product the connected token has write scopes for. The default OAuth scope set requested by the proxy includes write access to Jira issues and Confluence content. Bind it to agents only when that level of authority is intended.

Capabilities

  • Dynamically forward every Jira, Confluence, and Compass tool published by the upstream Atlassian MCP gateway.
  • Manage the full OAuth 2.1 lifecycle on behalf of the integrator: browser-based authorization, code exchange, token injection, automatic refresh on 401.
  • Fall back to Atlassian scoped API tokens for headless / CI use, where the host combines the email and token into an Authorization: Basic egress header.
  • Surface upstream changes (newly added or removed tools) automatically on the next discovery refresh — agents see the updated catalog without redeploying the plugin.

Required Headers

The proxy supports two auth modes; one of them must be satisfied.

OAuth 2.1 (primary, browser-based)

Header Required Description
X-Atlassian-Client-Id yes Atlassian OAuth 2.0 (3LO) client ID for your registered app.
X-Atlassian-Client-Secret yes Matching client secret. The host performs the authorization-code exchange against auth.atlassian.com/oauth/token and attaches the issued bearer token to outbound calls; refresh on 401 is automatic.

API token (fallback, headless / CI)

Header Required Description
X-Atlassian-Email yes Atlassian account email associated with the API token.
X-Atlassian-Api-Token yes Atlassian scoped API token (created at id.atlassian.com). The host combines email + token into an Authorization: Basic base64(email:token) egress header.

The API-token fallback applies to direct Atlassian REST hosts (e.g. *.atlassian.net). The upstream MCP gateway at mcp.atlassian.com itself only accepts OAuth bearer tokens, so an API-token-only deployment cannot use the dynamic-discovery path against mcp.atlassian.com — it must point at a REST host directly.

Credential Permissions

Atlassian Cloud OAuth 2.0 (3LO) issues bearer tokens whose effective permissions are the scopes consented to during authorization, intersected with the calling user's actual permissions inside the connected Atlassian site. Scopes are declared in the OAuth app's Permissions page in the Atlassian developer console and consented to by the user at authorization time; the issued access token can call only those scopes. The proxy requests the following default scope set:

  • read:jira-work · write:jira-work · read:jira-user
  • read:confluence-content.all · write:confluence-content · read:confluence-space.summary

For read-only agent behavior, register an OAuth app that omits every write:* scope; for narrower deployments (e.g. Jira-only), drop the Confluence scopes from both the app config and the consent flow. Note that scopes set the ceiling — the actual access is further restricted by what the consenting user can do in the Atlassian site (project permissions, space restrictions, board memberships).

For the API-token fallback, scopes are defined per-token at creation time at id.atlassian.com → Security → API tokens. Atlassian scoped API tokens use the same scope vocabulary as OAuth, so the same narrowing recipes apply.

References: Jira REST API authentication · OAuth 2.0 (3LO) for Atlassian Cloud apps.

Allowed Hosts

mcp.atlassian.com · auth.atlassian.com · api.atlassian.com

Tools

Tools are discovered dynamically from the upstream gateway and are not enumerated in this manifest. The current set published by Atlassian's MCP gateway covers:

  • Jira — issue search and CRUD, comments and worklogs, projects, boards, sprints, JQL search.
  • Confluence — page CRUD, search, spaces, content properties, attachments.
  • Compass — components, scorecards, metrics, dependencies.

To enumerate the live tool list visible to a given Construct deployment, call MCP tools/list against the running plugin. Tools advertised by the gateway carry their own input schemas; agents bind them through Studio's normal tool-grant flow.

Operational Notes

  • Dynamic discovery cadence. The proxy re-discovers the upstream tool list every 300 seconds by default. Set lower for development environments where you're iterating on the upstream MCP server, higher for production stability.
  • Stale-on-error behavior. If mcp.atlassian.com is unreachable at refresh time, the plugin keeps serving the last known tool list with a staleness marker. New tools added upstream during the outage will not appear until connectivity is restored.
  • Tool prefix. All forwarded tools are prefixed with jira_* to prevent name collisions with similarly-named tools on other plugins (e.g. multiple plugins exposing search_issues).
  • OAuth refresh. The proxy refreshes tokens automatically on upstream 401. Refresh-token failures (e.g. user revoked the app, refresh token expired) surface as a 401 to the agent on the next call — the integrator must re-authorize.
  • Reference docs. Atlassian MCP Server (GitHub) · Jira Cloud REST API v3.