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 と対話できるようにします。

Jira REST API ドキュメント

インストール

手動インストール

注: Node バージョン 22.12.0 以上が必要です

Jira 個人アクセストークンを作成または取得する: ガイド
Claude Desktop にサーバー設定を追加します。
- MacOS: ~/Library/Application Support/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 プロジェクトにはどのようなカンバンボードが存在しますか?」 → DEV プロジェクトキーとタイプパラメータを「kanban」に設定して list_boards ツールを実行します。
「ボード ID 123 のすべてのスプリントを表示する」→ list_sprints_from_board ツールを実行して、ボード 123 に関連付けられているすべてのスプリントを表示します。
「ボード 123 のスプリント 456 にはどのような問題がありますか?」 → ボード 123 のスプリント 456 にあるすべての問題を表示するには、list_issues_from_sprint ツールを実行します。
「マーケティングボードの現在のスプリントの最初の 50 件の問題を表示します」→ 最初に list_boards を実行してマーケティングボード ID を見つけ、次に list_sprints_from_board を実行して現在のスプリントを見つけ、最後に maxResults=50 で list_issues_from_sprint を実行します。

発達

依存関係をインストールします:

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（ストーリー、エピック、サブタスクの課題タイプ）
[ ] 更新問題
[ ] 問題を削除する
[ ] 号をアーカイブする
[ ] 問題からのコメントリスト
[ ] 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

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

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