jira-mcp
This server provides MCP access to Jira Cloud for reading and managing issues, comments, attachments, workflows, and related resources.
Read: search issues via JQL, list projects/boards/sprints, fetch issues, comments, transitions, and users (read-only).
Write: create/update issues, add comments, link issues, log work, and upload attachments (non-destructive).
Execute: trigger state changes such as transitioning issues, assigning, and unassigning.
Delete: remove issues, comments, links, and attachments (destructive/irreversible).
Dynamic operations: call any group with
operation="help"to list operations and signatures, oroperation="schema"to get JSON Schema for a specific operation.Server info:
jira_versionreturns the server version and service status.Deployment: runs over stdio by default, or as streamable HTTP via
--http; can also be imported and used programmatically with per-request context.
Provides tools for managing Jira Cloud issues, comments, transitions, attachments, and more via the Jira API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@jira-mcp show me the details of issue PROJ-123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
jira-mcp
MCP server for Jira Cloud — issue tracking, comments, transitions, attachments.
Install
{
"mcpServers": {
"jira": {
"command": "uvx",
"args": ["--refresh", "--extra-index-url", "https://nikitatsym.github.io/jira-mcp/simple", "jira-mcp"],
"env": {
"JIRA_URL": "https://myteam.atlassian.net",
"JIRA_EMAIL": "you@example.com",
"JIRA_TOKEN": "your-api-token",
"MCP_JIRA_BRIEF_MAX": "100"
}
}
}
}Get an API token at https://id.atlassian.com/manage-profile/security/api-tokens
HTTP
jira-mcp --http serves streamable HTTP at http://127.0.0.1:8000/mcp (--host, --port) instead of stdio, same environment variables. No authentication: put a gateway in front.
The package can also be imported: mcp, Settings, the client class, and client_var (a ContextVar the host sets per request) let one process serve several instances.
Related MCP server: Jira Cloud MCP Server
Groups
Tool | Description |
| Search, list projects/boards/sprints, fetch issues/comments/transitions (read-only) |
| Create/update issues, comments, links, worklogs, attachments (non-destructive) |
| Trigger state changes: transition, assign, unassign |
| Delete issues, comments, links, attachments (destructive) |
Call any group with operation="help" to list operations and their typed signatures; operation="schema" returns JSON Schema for one op (params={"op": "OpName"}).
Environment
Var | Required | Default | Purpose |
| yes | — | Atlassian site URL, e.g. |
| yes | — | Atlassian account email (basic-auth pair with token) |
| yes | — | API token from id.atlassian.com |
| no |
| Max length of |
Gotchas
parent_key vs Epic Link customfield. Team-managed (next-gen) projects accept parent_key="STS-1" and turn it into fields.parent={"key": "STS-1"}. Company-managed (classic) projects with Epic Link enabled require custom_fields={"customfield_NNNNN": "STS-1"} where NNNNN is the Epic Link field id (varies per site — see jira_read.ListFields). parent_key will not error in this case but the link won't be drawn either; the brief idea is to use custom_fields when working with classic projects.
ADF. description, environment, and comment bodies are converted from plain text to Atlassian Document Format. No markdown is rendered — *bold* stays literal. Roundtrip is lossy (the body returned by Jira is normalized ADF, not your input text), so _verify_top_level skips body from the verify pass.
accountId vs username/email. Jira Cloud accepts only accountId (e.g. 5e9c3a99...) for assignee/reporter/etc. Email or username will be silently rewritten or rejected. Look up accountIds with jira_read.SearchUsers.
<brief> requirement on create_issue.description. When MCP_JIRA_BRIEF_MAX > 0 (default 100), the description must contain <brief>one-line summary</brief>. Set MCP_JIRA_BRIEF_MAX=0 in env to disable. Brief is enforced on description only (not on comment bodies).
Verify-writes. After every write that returns a resource, jira-mcp does either zero extra RTT (update_issue uses ?returnIssue=true, comment ops use the POST response) or one slim follow-up GET (create_issue/transition_issue/assign_issue/unassign_issue, with ?fields=<sent keys>). The verify pass catches dropped fields — Jira silently ignored what we sent. It does NOT catch substituted values — if Jira swaps an invalid priority="Highest" for the project default, the key is present but the value differs. Strict-equality checks (assignee accountId, unassign null) are done inline as separate raises.
Resolution on update. update_issue rejects resolution in custom_fields because most workflow screens drop it silently. Use jira_execute.TransitionIssue(..., resolution=...). If the workflow screen still rejects the fields.resolution shape with a 400, retry passing the value via the update= parameter: update={"resolution": [{"set": {"name": "Done"}}]}.
upload_attachment reads any local file. The op passes file_path straight to open(...). An agent with this tool can read and POST any file the MCP process can read. Treat reach as equivalent to the process's filesystem scope; do not run jira-mcp with elevated privileges or wider filesystem access than you'd grant the model.
download_attachment path-traversal hardening. The path is None branch sanitizes the server-supplied filename via os.path.basename(...) or f"attachment_<id>", caps it at 255 chars, and saves into a fresh per-call mkdtemp("jira_mcp_") directory. Explicit path=... is the caller's responsibility.
Development
Tested against a real Jira Cloud sandbox. Unit tests use httpx.MockTransport (no network); integration tests are gated on env vars.
tests/test_swagger_conformance.py reads every registered op off its own AST and asserts method, path, query-param names and top-level body-field names against Atlassian's published OpenAPI documents, vendored gzipped under tests/specs/. It needs neither network nor credentials; its module docstring carries the refresh commands for the vendored copies.
uv sync
npm run test # unit tests, no network
npm run jira:bootstrap # verify tests/.env against your sandbox
npm run test:integration # end-to-end against real Jiratests/.env (gitignored) must contain JIRA_URL/JIRA_EMAIL/JIRA_TOKEN/JIRA_TEST_PROJECT. CI runs the integration job against the same secrets when set on the repo.
Available Tools
5 toolsjira_deleteA
Delete Jira resources (destructive, irreversible).
Call with operation="help" to list all available delete operations. Otherwise pass the operation name and a JSON object with parameters.
Example: jira_delete(operation="DeleteIssue", params={"issue_key": "PROJ-123"})
Inputs: operation (required), params.
jira_executeA
Trigger Jira state changes (transition, assign, unassign).
Distinct from write because these are side-effects on existing issues rather than resource creation.
Call with operation="help" to list all available execute operations.
Example: jira_execute(operation="TransitionIssue", params={"issue_key": "PROJ-1", "transition_id": "31"})
Inputs: operation (required), params.
jira_readA
Query Jira data (safe, read-only).
Call with operation="help" to list all available read operations. Otherwise pass the operation name and a JSON object with parameters.
Example: jira_read(operation="SearchIssues", params={"jql": "project = PROJ AND status = Open"})
Inputs: operation (required), params.
jira_versionA
Get the Jira MCP server version and service status.
Inputs: no named parameters.
jira_writeA
Create or update Jira resources (non-destructive).
Call with operation="help" to list all available write operations. Otherwise pass the operation name and a JSON object with parameters.
Example: jira_write(operation="CreateIssue", params={"project_key": "PROJ", "issue_type": "Task", "summary": "Fix login bug"})
Inputs: operation (required), params.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 5 tools
Each tool targets a distinct operation category: status, write/update, state transitions, delete, and read. There is no overlap in purpose, making it easy for an agent to select the correct tool.
All tools follow a consistent 'jira_' prefix with a clear verb (version, write, execute, delete, read). The pattern is uniform and predictable.
Five tools is an appropriate scope for a Jira integration, covering all major actions without unnecessary granularity or fragmentation.
The tool set covers CRUD operations (write, read, delete), state transitions (execute), and service info. The reliance on 'help' sub-operations limits immediate discoverability but the surface is otherwise complete.
Maintenance
Related MCP Connectors
One MCP server for all your work accounts: Slack, Teams, Google Chat, Jira, ClickUp, digest, tasks.
MCP Server for JFrog, providing tools for development and artifact management.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server for integrating with Jira Server instances, enabling natural language interactions to create, update, search, and manage issues and comments.1,667 npm1MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for interacting with Jira Cloud instances. Enables issue management, JQL queries, project and sprint management, and batch operations via natural language interfaces.141 npm4MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for JIRA integration enabling issue management, search, comments, and linking via natural language.Apache 2.0
- FlicenseNot gradedqualityDmaintenanceMCP server for Jira Server/Data Center, enabling issue management, comments, attachments, JQL search, and more through natural language.-