Which integrations are available for this server?

Provides tools for managing Jira Cloud issues, comments, transitions, attachments, and more via the Jira API.

How do I use jira-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. 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

by nikitatsym

Overview Schema Source Related Servers Discussions Admin

Python

Local

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

Related MCP server: Jira Cloud MCP Server

Groups

Tool	Description
`jira_read`	Search, list projects/boards/sprints, fetch issues/comments/transitions (read-only)
`jira_write`	Create/update issues, comments, links, worklogs, attachments (non-destructive)
`jira_execute`	Trigger state changes: transition, assign, unassign
`jira_delete`	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
`JIRA_URL`	yes	—	Atlassian site URL, e.g. `https://myteam.atlassian.net`
`JIRA_EMAIL`	yes	—	Atlassian account email (basic-auth pair with token)
`JIRA_TOKEN`	yes	—	API token from id.atlassian.com
`MCP_JIRA_BRIEF_MAX`	no	`100`	Max length of `<brief>` summary on issue descriptions. `0` disables enforcement

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 Jira

tests/.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 tools

jira_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"})

ParametersJSON Schema

Name	Required	Description	Default
`params`	No
`operation`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses the key behavioral traits: destructive and irreversible. This is critical for a deletion tool, though it lacks mention of authentication or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with clear front-loading: 'Delete Jira resources (destructive, irreversible).' Every sentence serves a purpose—identifying action, usage hint, and example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing output schema and no description of return values or error handling. The help mechanism partially compensates, but for a destructive tool, more context on success/failure would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds an example (DeleteIssue with issue_key) but does not explain the structure of params or list all operations. It provides a help mechanism but no detailed parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes Jira resources and emphasizes it is destructive and irreversible. It distinguishes from siblings like jira_read, jira_write, and jira_execute by focusing solely on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance to call with operation='help' to list available delete operations, and includes a concrete example. However, it does not specify when not to use this tool or alternatives for non-destructive actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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"})

ParametersJSON Schema

Name	Required	Description	Default
`params`	No
`operation`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states these are side-effects on existing issues, indicating mutational behavior. Without annotations, it carries the burden and does so adequately. However, it does not detail authorization needs or specific impacts beyond 'state changes', which would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences plus an example, all front-loaded with the core purpose. Every sentence adds value: purpose, sibling differentiation, help suggestion, and illustrative example. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only 2 parameters and no output schema, the description covers the main usage pattern and provides a discovery mechanism (help). It could mention return values or list common operations, but it's mostly complete for initial use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains that params is a flexible object depending on the operation and provides a concrete example with 'issue_key' and 'transition_id'. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool triggers Jira state changes (transition, assign, unassign), with a specific verb and resource. It distinguishes itself from siblings by explicitly contrasting with jira_write as side-effects on existing issues rather than resource creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use advice: 'Distinct from write because these are side-effects on existing issues rather than resource creation.' It also suggests calling with operation='help' to list all available operations, guiding the agent on how to discover usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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"})

ParametersJSON Schema

Name	Required	Description	Default
`params`	No
`operation`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It declares the tool 'safe, read-only', which is good. However, it does not disclose error behavior for invalid operations, permission requirements, or rate limits. The example shows correct usage but lacks edge-case context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences plus an example, all essential. The purpose is front-loaded, and the example clarifies usage immediately. No redundant words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the two parameters adequately and provides an example. However, there is no output schema and the description does not mention the return format, potential errors, or pagination. For a read tool, omitting the return structure is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions in schema), so the description compensates. It explains that 'operation' selects the read operation and 'params' is a JSON object with parameters. The mention of operation='help' and the example add concrete meaning beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Query Jira data (safe, read-only)', which identifies the verb and resource. It distinguishes from sibling tools like jira_write and jira_delete by explicitly marking itself as read-only. However, it could be more specific about which Jira entities are queried, though the example helps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises calling with operation='help' to list available operations, which provides a discovery mechanism. It does not explicitly contrast with siblings, but they are clearly different (write, execute, delete). No explicit when-to-use or when-not-to-use guidance beyond the 'read-only' hint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jira_versionA

Get the Jira MCP server version and service status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries the burden. It accurately states the tool retrieves version and status without side effects. Could mention authentication or availability, but sufficient for a simple read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence front-loading the purpose with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and simple purpose, the description is entirely sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Baseline for 0 params is 4; description adds no param info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Get' and resource 'Jira MCP server version and service status', clearly distinguishing from sibling tools like jira_write or jira_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives; usage is implied by the purpose but lacks direct context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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"})

ParametersJSON Schema

Name	Required	Description	Default
`params`	No
`operation`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behavioral traits. Only states 'non-destructive', which is useful but insufficient. Does not disclose error handling, side effects, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: one line for purpose, one for help mechanism, one for example. Every sentence provides essential information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity (2 params, no output schema, no annotations), the description covers the operation dispatch pattern and usage example. Could mention return format or error cases, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must add meaning. Explains that operation can be 'help' or a specific operation name, and params is a JSON object. Example clarifies usage. Adds significant value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Create or update Jira resources (non-destructive)', which specifies verb and resource. However, does not differentiate from sibling tools like jira_execute, leaving ambiguity about when to use this tool over alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance to call with operation='help' to list operations, and includes an example. Lacks explicit when-not-to-use or comparisons with siblings, but the help mechanism compensates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Jul 29, 2026
- First observedjira_delete
- First observedjira_execute
- First observedjira_read
- First observedjira_version
- First observedjira_write

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-29 18:40 across 5 tools

Disambiguation5/5

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.

Naming Consistency5/5

All tools follow a consistent 'jira_' prefix with a clear verb (version, write, execute, delete, read). The pattern is uniform and predictable.

Tool Count5/5

Five tools is an appropriate scope for a Jira integration, covering all major actions without unnecessary granularity or fragmentation.

Completeness4/5

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
SmartBear MCPOAuth
com.smartbear
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Monitoring Testing & QA Tools API Testing
144
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233

Related MCP Servers

Jira MCP Server
Project Management Developer Tools
AlexVulaj
A
license
Not graded
quality
D
maintenance
An MCP server for integrating with Jira Server instances, enabling natural language interactions to create, update, search, and manage issues and comments.
Updated a year ago (2025-09-12 14:27 UTC)
60 npm
1
MIT
Jira Cloud MCP Server
Project Management Developer Tools
aaronsb
A
license
Not graded
quality
A
maintenance
MCP server for interacting with Jira Cloud instances. Enables issue management, JQL queries, project and sprint management, and batch operations via natural language interfaces.
Updated 10 days ago (2026-09-05 02:51 UTC)
195 npm
4
MIT
mcp-jira-python
Project Management Developer Tools
amovfx
A
license
Not graded
quality
D
maintenance
MCP server for JIRA integration enabling issue management, search, comments, and linking via natural language.
Updated 2 years ago (2025-03-02 23:09 UTC)
Apache 2.0
jira-mcp
Project Management Developer Tools
Soundhannes
F
license
Not graded
quality
D
maintenance
MCP server for Jira Server/Data Center, enabling issue management, comments, attachments, JQL search, and more through natural language.
Updated 8 months ago (2026-01-24 22:46 UTC)
-