Connecting Jira to Claude Code with an MCP Server
A Jira MCP server lets Claude Code read tickets, list sprints, and pull context directly from your project board — all without leaving the terminal. Instead of copying ticket descriptions into your prompt, you point Claude at a ticket ID and it fetches everything it needs to start coding.
Why bother?
Most development workflows involve a round trip: open Jira in a browser, read the ticket, mentally translate acceptance criteria into code changes, then switch to the terminal. An MCP server for Jira collapses that loop. Claude Code can read the ticket itself, ask clarifying questions about the requirements, and start implementation with full context on what the ticket demands.
This is especially useful for tickets with long descriptions, linked sub-tasks, or acceptance criteria buried in comments. Claude can ingest all of that in one shot and reference it throughout the session.
Available MCP servers
There is no official Atlassian-maintained MCP server for Jira at the time of writing. The community has filled the gap with several open-source options:
- georgi-io/jira-mcp — A focused server that supports reading issues, searching with JQL, listing projects, and fetching sprint data. Written in TypeScript.
- StevenStavrakis/jira-mcp — Another popular option with similar coverage: issue lookup, transitions, comments, and search.
- atlassian-labs/mcp-remote — An experimental proxy from Atlassian Labs that can expose Atlassian APIs as MCP tools, though it requires more setup.
Check the README and open issues on any community server before adopting it. These projects vary in maintenance status and feature coverage.
Configuration
MCP servers are configured in .claude/settings.json at the project level or ~/.claude/settings.json globally, the same way you would configure a Postgres MCP server or any other MCP connection. Here is an example using georgi-io/jira-mcp:
{
"mcpServers": {
"jira": {
"command": "npx",
"args": ["-y", "@anthropic/jira-mcp"],
"env": {
"JIRA_BASE_URL": "https://yourcompany.atlassian.net",
"JIRA_API_TOKEN": "your-api-token",
"JIRA_USER_EMAIL": "you@yourcompany.com"
}
}
}
}
Replace the server package name with whichever MCP server you choose. The environment variables are standard across most Jira MCP implementations since they all hit the same Atlassian REST API underneath.
Getting an API token
- Go to id.atlassian.com/manage-profile/security/api-tokens.
- Create a new token with a descriptive label like "Claude Code MCP."
- Copy the token immediately — Atlassian will not show it again.
Store the token outside of version control. You can reference environment variables in your shell profile rather than hardcoding them in settings:
{
"env": {
"JIRA_API_TOKEN": "${JIRA_API_TOKEN}"
}
}
Then export the variable in your .zshrc or .bashrc.
Example workflows
Fetch a ticket and start coding
> Use the Jira tool to read PROJ-1234, then implement the changes described in that ticket.
Claude fetches the ticket summary, description, acceptance criteria, and any comments. It then plans and implements the work based on the full ticket context.
List current sprint tickets
> Show me all in-progress tickets assigned to me in the current sprint.
The MCP server runs a JQL query behind the scenes, something like assignee = currentUser() AND sprint in openSprints() AND status = "In Progress". Claude presents the results and can dive into any individual ticket from there.
Triage a backlog
> List the top 10 unestimated tickets in the PROJ backlog and summarize each one in a sentence.
This is useful for sprint planning prep. Claude reads each ticket and gives you a quick digest without opening a single browser tab.
End-to-end ticket implementation
> Read PROJ-567, implement it, write tests, and commit with the ticket ID in the commit message.
Claude reads the ticket, writes the code, adds tests, and creates a commit like PROJ-567: Add rate limiting to the /api/upload endpoint. The ticket context stays active throughout the session, so Claude can check its work against the acceptance criteria before finishing. For complex tickets, consider using plan mode to break the work into steps before implementation.
Security considerations
Jira API tokens carry the full permissions of the user account that created them. A few things to keep in mind:
- Use a service account if possible. Create a dedicated Jira user with read-only access to the projects Claude needs. This limits blast radius if the token leaks.
- Read-only is usually enough. Most workflows only need Claude to read tickets, not modify them. If the MCP server supports write operations like transitioning issues or adding comments, make sure that is intentional.
- Scope project access. Jira Cloud does not support fine-grained token scoping at the API token level, but you can restrict what the service account can see through Jira project permissions.
- Never commit tokens. Use environment variables or a secrets manager. If settings.json is checked into your repo, use variable references rather than raw values.
- Rotate tokens periodically. Treat the API token like any other credential in your workflow.
Limitations
MCP servers for Jira are still early. Expect some rough edges:
- No real-time sync. The server fetches data on demand. It does not stream updates or watch for ticket changes.
- Attachment handling is limited. Most servers can read text fields but will not download or parse images or file attachments on tickets.
- Rate limits apply. Atlassian Cloud enforces API rate limits. Heavy querying during sprint planning may hit those limits.
- JQL support varies. Not every MCP server exposes the full power of JQL. Check which query capabilities your chosen server supports.
- Write operations are risky. Some servers support transitioning tickets or adding comments. Be deliberate about enabling those capabilities — Claude acting on stale context could move tickets incorrectly.
Despite these limitations, a Jira MCP server removes a meaningful amount of friction from ticket-driven development. You can also extend Claude Code's capabilities further with plugins and subagents. The setup takes five minutes and the payoff is immediate: Claude reads the ticket, understands the requirements, and starts working with real context instead of whatever you remembered to paste into the prompt.