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: ~/라이브러리/애플리케이션 지원/클로드/claude_desktop_config.json
- Windows: 이 가이드를 확인하세요

지엑스피1

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에는 어떤 이슈가 있나요?" → list_issues_from_sprint 도구를 실행하여 123번 보드의 스프린트 456에 있는 모든 이슈를 확인하세요.
"마케팅 보드에서 현재 스프린트의 처음 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

시계를 사용하여 로컬로 실행:

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

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