en es ja ko zh

Jira MCP Server

Name: Jira MCP Server
Author: ParasSolanki

by ParasSolanki

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Jira MCP 服务器

NPM 版本 NPM 下载许可证：MIT

Jira 的模型上下文协议服务器。

通过 MCP 提供与 Jira 的集成，允许 LLM 与其交互。

Jira REST Api 文档

安装

手动安装

注意：要求 Node 版本为 22.12.0 或以上

创建或获取 Jira 个人访问令牌：指南
将服务器配置添加到 Claude Desktop：
- MacOS：〜/资源库/应用程序支持/Claude/claude_desktop_config.json
- Windows：查看本指南

{
  "mcpServers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "@parassolanki/jira-mcp-server@latest"],
      "env": {
        "JIRA_PERSONAL_ACCESS_TOKEN": "email@example.com:your_personal_jira_access_token",
        "JIRA_BASE_URL": "jira_base_url"
      }
    }
  }
}

对于 Windows：

{
  "mcpServers": {
    "jira": {
      "command": "cmd /c npx",
      "args": ["-y", "@parassolanki/jira-mcp-server@latest"],
      "env": {
        "JIRA_PERSONAL_ACCESS_TOKEN": "email@example.com:your_personal_jira_access_token",
        "JIRA_BASE_URL": "jira_base_url"
      }
    }
  }
}

Related MCP server: Jira MCP Server

成分

工具

list_projects ：列出来自 Jira 的项目。
- 必需输入：
  - query （可选字符串）：用于过滤返回的项目的查询字符串。
  - maxResults （可选数字，最大值：100）：返回的最大结果数。
  - expand (可选字符串)：扩展响应中的附加信息。（逗号分隔的description 、 lead 、 issueTypes 、 url 、 projectKeys 、 permissions和insight ）。
list_boards ：列出项目中的板。
- 必需输入：
  - projectKeyOrId （字符串）：项目的密钥或 ID。
  - name （可选字符串）：项目名称。
  - maxResults （可选数字，最大值：100）：返回的最大结果数。
  - startAt （可选数字）：返回板的起始索引。
  - type （可选字符串）：板的类型。（可以是scrum或kanban之一）。
list_sprints_from_board ：列出来自某个板的冲刺。
- 必需输入：
  - boardId （字符串）：板的 ID。
  - maxResults （可选数字，最大值：100）：返回的最大结果数。
  - startAt （可选数字）：返回板的起始索引。
list_issues_from_sprint ：列出冲刺中的问题。
- 必需输入：
  - boardId （字符串）：板的 ID。
  - sprintId （字符串）：冲刺的 ID。
  - maxResults （可选数字，最大值：100）：返回的最大结果数。
  - startAt （可选数字）：返回板的起始索引。
  - expand （可选字符串）：扩展响应中的附加信息。（以逗号分隔的schema和names ）。
create_issue ：在 Jira 中创建问题（仅支持任务问题类型）。
- 必需输入：
  - projectKeyOrId （字符串）：项目的密钥或 ID。
  - summary （字符串）：问题的摘要/标题。
  - description （字符串）：问题的描述。

使用示例

您可以使用以下示例提示与 Jira 进行交互：

“显示所有 Jira 项目”→执行 list_projects 工具查看所有可用项目。
“DEV 项目中有哪些看板？”→ 执行 list_boards 工具，将 DEV 项目键和类型参数设置为“kanban”。
“显示板 ID 123 的所有冲刺”→执行 list_sprints_from_board 工具以查看与板 123 相关的所有冲刺。
“123 号板上的 sprint 456 中有哪些问题？” → 执行 list_issues_from_sprint 工具查看 123 号板上的 sprint 456 中的所有问题。
“显示营销板上当前冲刺的前 50 个问题”→首先执行 list_boards 以查找营销板 ID，然后执行 list_sprints_from_board 以查找当前冲刺，然后执行 list_issues_from_sprint 并使用 maxResults=50。

发展

安装依赖项：

pnpm install

在.env中配置 Github 访问令牌：

JIRA_PERSONAL_ACCESS_TOKEN=email@example.com:your_personal_jira_access_token
JIRA_BASE_URL=jira_base_url

使用 watch 在本地运行：

pnpm dev

构建服务器：

pnpm build

使用检查器进行本地调试：

pnpm inspector

待办事项

[x] 列出项目
[x] 列表板
[x] 列出来自板的冲刺
[x] 列出来自冲刺的问题
[ ] 通过 ID 或密钥获取问题
[x] create_issue（仅限任务问题类型）
[ ] create_issue（故事、史诗、子任务问题类型）
[ ] update_issue
[ ] 删除问题
[ ] 归档问题
[ ] 列出来自问题的评论
[ ] 根据问题 ID 获取评论
[ ] 在问题中创建评论
[ ] 更新问题评论
[ ] 删除问题评论
[ ] 列出来自问题的子任务
[ ] 通过用户名或密钥获取用户

Available Tools

5 tools

create_issueB

Create an issue in Jira

ParametersJSON Schema

Name	Required	Description
`projectKeyOrId`	Yes	The key or ID of the project
`summary`	Yes	The summary of the issue
`description`	Yes	The description of the issue

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states it creates an issue; does not disclose side effects, permissions needed, success/failure behavior, or whether the action is idempotent.

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?

Extremely concise single sentence with no filler; every word is essential.

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

Completeness2/5

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

Given no output schema and no annotations, the description should hint at return value or additional behavior. It does not; leaves agent guessing about what happens after creation.

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?

Schema description coverage is 100%, so baseline is 3. Description adds no extra semantic context beyond the schema definitions; e.g., does not explain the purpose of projectKeyOrId or summary.

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 action ('Create') and the resource ('an issue in Jira'), which is distinct from sibling tools that are all list operations.

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

Usage Guidelines2/5

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

No guidance on when to use versus alternatives (e.g., list_issues_from_sprint). Does not mention prerequisites such as having a project key or that summary and description are required.

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

list_boardsC

List boards from a project

ParametersJSON Schema

Name	Required	Description
`projectKeyOrId`	Yes	The key or ID of the project
`name`	No	The name of the boards to return, Must be less than 255 characters.
`maxResults`	No	The maximum number of results to return, (max: 100)
`startAt`	No	The starting index of the returned boards
`type`	No	The type of boards to return

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose read-only nature, pagination behavior, or error handling. Only implies listing without side effects.

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

Conciseness4/5

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

Single sentence, 4 words, no wasted text. However, it could be expanded without losing conciseness.

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

Completeness2/5

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

Description lacks return value info, pagination details, and filtering logic. With 5 parameters and no output schema, it is underspecified.

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?

Schema descriptions cover all 5 parameters with 100% coverage, so description adds no extra meaning beyond the schema. Baseline score of 3.

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?

Description clearly states the tool lists boards from a project, with a specific verb and resource. It is distinct from sibling tools (list_projects, list_sprints_from_board) but does not explicitly differentiate them.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention context or prerequisites.

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

list_issues_from_sprintC

List issues from a sprint

ParametersJSON Schema

Name	Required	Description
`sprintId`	Yes	The ID of the sprint
`boardId`	Yes	The ID of the board
`maxResults`	No	The maximum number of results to return, (default: 5, max: 100)
`startAt`	No	The starting index of the returned boards
`expand`	No	Use this parameter to include additional information in the response. This parameter accepts a comma-separated list. Expand options include: `schema` and `names`. Comma separated list of options.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action, omitting details like pagination (implied by maxResults/startAt), default results, error behavior, or authentication requirements. This is insufficient for an agent to understand the tool's full behavior.

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

Conciseness4/5

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

The description is extremely concise (4 words) with no wasted text. However, it borders on under-specification, as it could benefit from a brief qualifier (e.g., 'paginated list'). Nonetheless, it is efficient for a simple tool.

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

Completeness2/5

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

Given the tool has 5 parameters (2 required) and no output schema, the description is too minimal. It fails to explain return structure, parameter expected formats (e.g., sprintId format), or how results are ordered. An agent would struggle to use this tool correctly without additional context.

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?

The input schema has 100% description coverage for all 5 parameters, so the schema already provides meaning. The description adds no additional parameter-level context beyond the schema. Baseline score of 3 is appropriate.

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 'List issues from a sprint' clearly states the verb (list) and the resource (issues from a sprint), distinguishing it from sibling tools like list_boards or list_sprints_from_board. However, it lacks specificity on scope or filtering options that would enhance clarity.

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

Usage Guidelines2/5

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

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., search issues, list all issues), nor does it specify prerequisites like the need for valid sprintId and boardId.

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

list_projectsC

List projects from Jira

ParametersJSON Schema

Name	Required	Description
`maxResults`	No	The maximum number of results to return, (max: 100)
`query`	No	A query string used to filter the returned projects. The query string cannot be used with the startAt and maxResults parameters.
`expand`	No	Use this parameter to include additional information in the response. This parameter accepts a comma-separated list. Expand options include: `description`, `lead`, `issueTypes`, `url`, `projectKeys`, `permissions`, `insight`. Comma separated list of options.

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden of disclosure. It does not state whether the operation is read-only, idempotent, or any side effects. The name 'list' implies read-only, but no explicit confirmation is given.

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

Conciseness3/5

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

The description is a single sentence, which is concise but lacks any structure or additional context. It could be more informative without becoming verbose.

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

Completeness2/5

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

The description is insufficient for a tool with no output schema. It does not explain the return format, pagination behavior, or any error conditions, even though the schema mentions maxResults and expand. The low complexity partly excuses this, but a complete description would add value.

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?

Schema coverage is 100%, and the schema descriptions are clear. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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 'List projects from Jira' clearly states the action and resource. It is specific enough to distinguish from siblings like list_boards or list_issues_from_sprint, though it does not explicitly differentiate.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., filtering via query vs. using maxResults). There is no mention of when-not to use it or any prerequisites.

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

list_sprints_from_boardB

List sprints from a board

ParametersJSON Schema

Name	Required	Description
`boardId`	Yes	The ID of the board
`maxResults`	No	The maximum number of results to return, (max: 100)
`startAt`	No	The starting index of the returned boards

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and description does not disclose behaviors like pagination (maxResults, startAt), ordering, or scope (active/future/closed sprints). Full burden on description, which fails.

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 sentence with no wasted words. Perfectly concise.

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

Completeness2/5

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

Does not mention return format, pagination behavior, or constraints like max sprints. Incomplete for a 3-parameter tool with no output schema.

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?

Schema coverage is 100%, so baseline is 3. Description does not add any additional meaning beyond schema parameter names.

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?

Clearly states verb 'list', resource 'sprints', and scope 'from a board'. Distinguishes from sibling tools like list_boards and list_issues_from_sprint.

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 or alternatives, but purpose is straightforward given sibling names. Lacks exclusions or prerequisites.

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.0Jan 2, 2026
- Addedcreate_issue
- Addedlist_boards
- Addedlist_issues_from_sprint
- Addedlist_projects
- Addedlist_sprints_from_board

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-05-06 14:15 across 5 tools

Disambiguation5/5

Each tool targets a distinct action: create issue, list boards, list issues from sprint, list projects, list sprints from board. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_issue, list_boards). No deviations.

Tool Count5/5

5 tools is well-scoped for a Jira MCP server, covering essential listing and creation operations without bloat.

Completeness3/5

The set covers creation and listing of key entities but lacks update, delete, and search operations, which are common in Jira workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
215
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

Related MCP Servers

Python Jira MCP Server
Project Management Developer Tools App Automation
Chase-Bullock
F
license
Not graded
quality
D
maintenance
A server implementation that allows AI models to interact with Jira through the Model Context Protocol, enabling tasks like JQL searches and retrieving issue details.
Updated 2 years ago (2025-03-06 02:48 UTC)
-
Jira MCP Server
App Automation Project Management
samuelrizzo
A
license
A
quality
D
maintenance
A Model Context Protocol server that enables AI assistants like Claude to interact with Jira, allowing for project management tasks such as listing projects, searching issues, creating tickets, and managing sprints through natural language queries.
Updated a year ago (2025-08-06 19:07 UTC)
7
54 npm
2
TypeScript
MIT
Jira MCP Server
sespinosa
A
license
C
quality
D
maintenance
A Model Context Protocol server that enables AI assistants like Claude to interact with Jira Cloud instances, providing capabilities for issue management, project listing, and JQL search.
Updated a year ago (2025-07-07 21:36 UTC)
1
54 npm
2
MIT
Jira MCP Server
Project Management Search
Positronic-AI
A
license
Not graded
quality
C
maintenance
A clean, reliable Model Context Protocol server for Jira integration, enabling issue management, search, and more via natural language.
Updated a year ago (2025-11-05 15:13 UTC)
MIT

Jira MCP 服务器

安装

手动安装

成分

工具

使用示例

发展

待办事项

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches