What can you do with this server?

The Jira MCP Server facilitates interaction with Jira through a set of tools for listing and creating data: * List Projects: Retrieve projects with optional query filters and expanded information * List Boards: Fetch boards from a specific project, filterable by type (scrum/kanban) and name * List Sprints: Obtain sprints from a particular board * List Issues: Extract issues from a specific sprint on a board * Create Issue: Generate new issues within a project (currently limited to Task issue types only)

Which integrations are available for this server?

Provides integration with Jira, allowing viewing and management of projects, boards, sprints, and issues. Capabilities include listing projects, boards, sprints, and retrieving issues from sprints, with plans for additional functionality like issue creation, commenting, and user management.

How do I use Jira MCP Server?

1. Click on "Install 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 Server show me all issues in the current sprint for board 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.

en es ja ko zh

Jira MCP Server

by ParasSolanki

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Jira MCP Server

NPM Version NPM Downloads License: MIT

A Model Context Protocol Server for Jira.

Provides integration with Jira through MCP, allowing LLMs to interact with it.

Jira REST Api Docs

Installation

Manual Installation

Note: Requires Node version to be 22.12.0 or above

Create or get Jira Personal Access Token: Guide
Add server config to Claude Desktop:
- MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: Check this Guide

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

For 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

Components

Tools

list_projects: List projects from Jira.
- Required inputs:
  - query (optional string): A query string used to filter the returned projects.
  - maxResults (optional number, max: 100): The maximum number of results to return.
  - expand (optional string): Expand additional information in the response. (comma separated description, lead, issueTypes, url, projectKeys, permissions and insight).
list_boards: List boards from a project.
- Required inputs:
  - projectKeyOrId (string): Key or Id of the project.
  - name (optional string): Name of the project.
  - maxResults (optional number, max: 100): The maximum number of results to return.
  - startAt (optional number): The starting index of the returned boards.
  - type (optional string): The type of boards. (can be one of scrum or kanban).
list_sprints_from_board: List sprints from a board.
- Required inputs:
  - boardId (string): The ID of the board.
  - maxResults (optional number, max: 100): The maximum number of results to return.
  - startAt (optional number): The starting index of the returned boards.
list_issues_from_sprint: List issues from a sprint.
- Required inputs:
  - boardId (string): The ID of the board.
  - sprintId (string): The ID of the sprint.
  - maxResults (optional number, max: 100): The maximum number of results to return.
  - startAt (optional number): The starting index of the returned boards.
  - expand (optional string): Expand additional information in the response. (comma separated schema and names).
create_issue: Create an issue in Jira (Only supports Task issue type).
- Required inputs:
  - projectKeyOrId (string): Key or Id of the project.
  - summary (string): The summary/title of the issue.
  - description (string): The description of the issue.

Usage examples

Some example prompts you can use to interact with Jira:

"Show me all Jira projects" → execute the list_projects tool to see all available projects.
"What Kanban boards exist in the DEV project?" → execute the list_boards tool with the DEV project key and type parameter set to "kanban".
"Show me all the sprints for board ID 123" → execute the list_sprints_from_board tool to see all sprints associated with board 123.
"What issues are in sprint 456 on board 123?" → execute the list_issues_from_sprint tool to see all issues in sprint 456 on board 123.
"Show me the first 50 issues from the current sprint on the Marketing board" → first execute list_boards to find the Marketing board ID, then list_sprints_from_board to find the current sprint, then list_issues_from_sprint with maxResults=50.

Development

Install dependencies:

pnpm install

Configure Github Access token in .env:

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

Run locally with watch:

pnpm dev

Build the server:

pnpm build

Local debugging with inspector:

pnpm inspector

TODOS

list_projects
list_boards
list_sprints_from_board
list_issues_from_sprint
get_issue_by_id_or_key
create_issue (task issue type only)
create_issue (story, epic, sub-task issue types)
update_issue
delete_an_issue
archieve_an_issue
list_comments_from_issue
get_comment_from_issue_by_id
create_comment_in_issue
update_comment_of_issue
delete_comment_of_issue
list_subtasks_from_issue
get_user_by_username_or_key

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

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

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Mercado Pago
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 a year 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
98
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
98
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 10 months ago (2025-11-05 15:13 UTC)
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ParasSolanki/jira-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server