Which integrations are available for this server?

Provides tools for querying Jira boards, issues, user information, and adding comments to Jira issues, enabling AI agents to interact with Jira Cloud.

How do I use Jira MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jira MCP Server list my issues on board 5" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Jira MCP Server

by ahmetbarut

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Jira MCP Server

A modular, extensible Model Context Protocol (MCP) server for interacting with Jira Cloud. This project provides a set of tools to query boards, issues, user information, and more, making it easy to integrate Jira with AI agents, bots, or other automation systems.

🚀 Features

List all available Jira scrum boards
List your own issues for a specific board
Add comments to Jira issues (ADF-compliant)
Get current authenticated user information
Search for users by login, email, or display name
Get Jira server information (including server time)
Modular, extensible, and easy to contribute

Related MCP server: Jira MCP Server

🛠️ Requirements

Node.js 18+
Access to a Jira Cloud instance
Jira API Token (see Jira API Tokens)

⚙️ Environment Variables

Set the following environment variables in your shell or .env file:

JIRA_BASE_URL=https://your-domain.atlassian.net
JIRA_EMAIL=your-email@company.com
JIRA_API_TOKEN=your-jira-api-token

🚀 Quick Start (with npx)

You can run the Jira MCP Server instantly with npx, no global install required:

npx -y @ahmetbarut/jira-mcp-server

Or, if you want to use it as an MCP tool in a config file (e.g. mcp.json):

{
  "Jira MCP Server": {
    "command": "npx",
    "args": ["-y", "@ahmetbarut/jira-mcp-server"],
    "env": {
      "JIRA_BASE_URL": "https://your-domain.atlassian.net",
      "JIRA_EMAIL": "your-email@company.com",
      "JIRA_API_TOKEN": "your-jira-api-token"
    }
  }
}

No need for npm install or global install.
All dependencies are handled by npx.
You can set your Jira credentials in the env section.

Note: The first run may take a few seconds as npx downloads the package.

📦 Installation & Setup

Clone the repository (optional):

git clone https://github.com/ahmetbarut/jira-mcp.git
cd jira-mcp-server

Install globally (optional):

npm install -g @ahmetbarut/jira-mcp-server

Set environment variables:
- See above for required variables.
Build the project (if using from source):
```
npm run build
```

Run the server:

jira-mcp-server
# or
npx -y @ahmetbarut/jira-mcp-server

🧩 Usage

This server is designed to be used as an MCP tool server, typically via stdio. You can interact with it using the Model Context Protocol Inspector or integrate it into your own MCP-compatible agent.

Example: List Boards

npx @modelcontextprotocol/inspector --cli npx -y @ahmetbarut/jira-mcp-server --method tools/call --tool-name get_boards

Example: Get Your Issues for a Board

npx @modelcontextprotocol/inspector --cli npx -y @ahmetbarut/jira-mcp-server --method tools/call --tool-name get_issues --tool-arg boardId=123

Example: Add a Comment to an Issue

npx @modelcontextprotocol/inspector --cli npx -y @ahmetbarut/jira-mcp-server --method tools/call --tool-name add_comment_to_issue --tool-arg issueIdOrKey=PROJ-123 --tool-arg body="This is a test comment."

🧰 Available Tools

get_boards: List all available Jira scrum boards
get_issues: List your issues for a specific board
add_comment_to_issue: Add a comment to a Jira issue (ADF-compliant)
get_current_user_info: Get current authenticated user information
search_user: Search for a user by login, email, or display name
get_server_info: Get Jira server information (including server time)

🏗️ Project Structure

src/index.ts — Main server entry point and tool dispatcher
src/tools.ts — Tool definitions and schemas
src/handlers.ts — Tool handler implementations (business logic)
src/jiraApi.ts — Jira API helpers and configuration
src/types.ts — TypeScript types and interfaces

🤝 Contributing

Contributions are welcome! Please follow these steps:

Fork the repository
Create a new branch for your feature or bugfix:
```
git checkout -b my-feature
```
Write clear, well-documented code
Add or update tests if applicable
Open a pull request with a clear description of your changes
Ensure your code passes lint and build checks

Code Style

Use TypeScript and follow the existing modular structure
Keep business logic in handlers.ts and API helpers in jiraApi.ts
Write clear commit messages

Issues

If you find a bug or have a feature request, please open an issue on GitHub with as much detail as possible.

📄 License

This project is licensed under the MIT License. See LICENSE for details.

Happy automating with Jira MCP Server!

Available Tools

7 tools

add_comment_to_issueB

Add a comment to a specific Jira issue

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	The comment text
`issueIdOrKey`	Yes	The issue key or ID to add a comment to

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only says 'Add a comment', giving no information about permissions, idempotency, side effects, or response behavior. This is a significant gap for a mutation tool.

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 at one sentence and 9 words. It is front-loaded and efficient, but could integrate more information without losing brevity. Still, it avoids wordiness.

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?

For a simple mutation tool with two required parameters, no output schema, and no annotations, the description is too sparse. It lacks any mention of return values, error handling, or usage context, leaving the AI agent with minimal guidance beyond the 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?

The input schema has 100% description coverage for both parameters ('body' and 'issueIdOrKey'), each with clear descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 ('Add a comment') and the resource ('a specific Jira issue'), matching the tool name directly. It is unambiguous and distinct from sibling tools like get_issues or get_boards, which are read-only.

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 vs alternatives, nor any prerequisites or exclusions. The description simply states the action without context about when it is appropriate or not.

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

get_boardsA

Get all available Jira scrum boards

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description must convey behavior. It indicates a read operation ('Get') but does not explicitly state that it is read-only, has no side effects, or requires any authentication context.

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

Conciseness5/5

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

The description is a single, concise sentence with no wasted words. It is appropriately sized for a simple tool.

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

Completeness3/5

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

The tool has no output schema and the description does not mention the return format or fields. For a simple list endpoint, it would be helpful to know what information is returned (e.g., board names, IDs, types).

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

Parameters4/5

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

The input schema has zero parameters, so schema coverage is trivially 100%. The baseline for no parameters is 4, and the description adds no redundant parameter info.

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 'Get all available Jira scrum boards' uses a specific verb 'Get' and identifies the resource clearly as scrum boards. It distinguishes from sibling tools like get_issues which deal with issues, not boards.

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 guidance is provided on when to use this tool versus alternatives like search or filtered board tools. The purpose is clear but the description lacks any context about usage scenarios.

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

get_current_user_infoA

Get current authenticated user information including login, email, timezone

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It correctly implies a read-only operation and lists output fields, but it does not mention potential failure modes (e.g., authentication required, network errors) or side effects. For a simple tool, this is adequate but not exceptional.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that contains no extraneous information. Every word is necessary to convey the tool's purpose and output, achieving maximum conciseness.

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

Completeness4/5

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

For a simple tool with no parameters and no output schema, the description is largely complete. It specifies the key output fields (login, email, timezone) and implies the scope (current authenticated user). A small gap is the lack of mention of any additional returned fields, but this is minor.

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

Parameters4/5

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

There are no parameters, so the input schema is empty (100% coverage). The description adds no parameter information, which is acceptable. According to calibration, a baseline of 4 is appropriate for zero-parameter tools.

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 verb 'Get' and the resource 'current authenticated user information', listing specific fields (login, email, timezone). The tool name and description uniquely identify its purpose, and the sibling tools (e.g., search_user, get_server_info) are clearly distinct, so an agent can easily differentiate when to use this tool.

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 explicit guidance is provided on when to use this tool versus its siblings. While the purpose is clear, the description lacks any hints about prerequisites, context, or exclusions. An agent must rely solely on the tool name to infer usage context.

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

get_issue_detailB

Get detailed information about a specific Jira issue

ParametersJSON Schema

Name	Required	Description	Default
`issueIdOrKey`	Yes	The issue key (e.g., PROJ-123) or ID to get details for

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 'Get detailed information', omitting any behavioral traits like read-only nature, authentication needs, rate limits, or what 'detailed' entails.

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 a single concise sentence that is front-loaded. However, it is overly minimal and could include more detail without losing conciseness.

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

Completeness3/5

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

Given the tool's simplicity (one parameter, no output schema), the description is adequate but not complete. It fails to clarify what 'detailed information' includes, leaving the agent without expected return structure.

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 the baseline is 3. The description adds no additional meaning beyond the schema's parameter description; it merely restates the parameter purpose.

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 verb 'Get' and the resource 'detailed information about a specific Jira issue'. It distinguishes from siblings like 'get_issues' (list) and 'add_comment_to_issue' by targeting a single issue.

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

Usage Guidelines3/5

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

The description implies use for a single issue but offers no explicit when-to-use or when-not-to-use guidance. No mention of alternatives like 'get_issues' for listing.

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

get_issuesB

Get current user's tasks from a specific Jira board

ParametersJSON Schema

Name	Required	Description	Default
`boardId`	Yes	Board ID to get your tasks from

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so description must bear full burden. It only states the action without disclosing side effects, auth requirements, or error behaviors like invalid boardId.

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 9 words, front-loaded with key verb and resource. No redundancy or wasted text.

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

Completeness3/5

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

For a simple 1-param tool with no output schema, the description is adequate but leaves gaps: does not specify return format, pagination, or if 'tasks' means assigned issues. Sufficient for basic use, not comprehensive.

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% with a clear description for boardId. The tool description adds no new meaning beyond the schema, resulting in baseline score.

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?

Description clearly states the tool retrieves current user's tasks from a specific board, using distinct verb and resource. It differentiates from siblings like get_boards (lists boards) and get_current_user_info (user details).

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 or not use this tool, nor any mention of alternatives. Siblings are listed but no comparative advice provided.

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

get_server_infoA

Get Jira server information including current server time

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation retrieving server information and time, which is straightforward. No hidden behaviors are suggested, though it lacks details on permissions or data freshness.

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

Conciseness5/5

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

The description is a single concise sentence that captures the tool's purpose efficiently without any redundant or extraneous information.

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

Completeness4/5

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

Given the tool's simplicity (no parameters, no output schema), the description is adequately complete. It conveys the core function, though it could optionally mention the format of the server time.

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

Parameters4/5

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

There are no parameters, so baseline is 4. The description adds no parameter detail because none is needed; the schema already covers the trivial case.

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

Purpose5/5

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

The description clearly states the tool retrieves Jira server information and specifically mentions including current server time. The verb 'Get' and resource 'Jira server information' are precise, and it distinguishes well from sibling tools that focus on boards, issues, users, or comments.

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

Usage Guidelines3/5

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

The description implies use when server info or time is needed, but it provides no explicit guidance on when to use this tool over alternatives or when not to use it. There are no exclusions or usage context given.

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

search_userB

Search for a user by login name or email

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Username, email, or display name to search for

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic search purpose without detailing characteristics like result size, case sensitivity, partial matching, or whether this is a read-only operation. The omission of 'display name' from the schema's description also introduces inconsistency.

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 a single concise sentence with no waste. However, it could be more structured to include additional context without sacrificing brevity.

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?

With no output schema and no annotations, the description fails to explain return format, pagination, error behavior, or whether multiple users can be returned. This is insufficient for a search tool.

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

Parameters2/5

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

Schema coverage is 100% with a clear description for 'query' (username, email, or display name). The tool's description narrows this to 'login name or email', omitting display name and potentially confusing the agent. It adds no additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the verb 'Search' and the resource 'user', and specifies criteria 'by login name or email'. This distinguishes it from sibling tools like get_boards or get_current_user_info.

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

Usage Guidelines3/5

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

The description implies usage when needing to find a user by login name or email, but provides no explicit guidance on when to use versus alternatives, nor any exclusions.

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.

7 tool updatesv1.1.0Jul 30, 2026
- First observedadd_comment_to_issue
- First observedget_boards
- First observedget_current_user_info
- First observedget_issue_detail
- First observedget_issues
- First observedget_server_info
- First observedsearch_user

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-07-30 22:35 across 7 tools

Disambiguation5/5

Each tool targets a distinct resource or action: boards, issues, user info, server info, and comments. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, e.g., get_boards, get_issues, add_comment_to_issue. The naming is predictable and clear.

Tool Count5/5

With 7 tools, the set is well-scoped for a Jira server, covering essential operations on boards, issues, users, and server info without being excessive.

Completeness3/5

The set lacks issue creation, update, and deletion, which are core operations for a Jira server. Agents cannot complete full issue lifecycle tasks, leaving notable gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Atlassian Rovo MCP ServerOAuth
com.atlassian
Connect to Atlassian Jira, Confluence, Loom, and more to search, create, and manage your work.
Workplace & Productivity Project Management Developer Tools
21,112
KelviaOAuth
io.github.gonnagetapower
Task manager your agent can fully operate: boards, tasks, sprints, roles, worklogs, day planner.
Project Management Workplace & Productivity
11
mcp-serverOAuth
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
Tack
io.github.Thefirstmannnn
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Project Management Workplace & Productivity
1

Related MCP Servers

Jira MCP
Project Management Developer Tools App Automation
icy-r
A
license
Not graded
quality
C
maintenance
Enables AI assistants to manage Jira Cloud instances, including creating and updating issues, managing sprints and projects, adding comments, tracking worklogs, and searching with presets.
Updated 9 months ago (2025-12-17 07:02 UTC)
4 npm
MIT
Jira MCP Server
Project Management Developer Tools Workplace & Productivity
Jira-MCP
A
license
A
quality
Not graded
maintenance
Enables AI assistants to interact with Atlassian Jira Cloud, allowing users to manage projects, issues, comments, and workflows through natural language commands.
Updated 8 months ago (2026-01-12 07:24 UTC)
6
30 npm
3
-
Jira MCP Integration
Project Management Developer Tools
Koveh
F
license
Not graded
quality
D
maintenance
Enables AI agents to interact with Jira Cloud through the REST API, supporting project management, issue operations (create, read, update, delete), JQL search, task assignments, and status transitions.
Updated 10 months ago (2025-11-28 15:23 UTC)
-
jira-mcp-server
Project Management Developer Tools
BillNobill
A
license
B
quality
C
maintenance
Enables AI agents to manage Jira projects and issues using natural language, including creating, updating, searching issues, managing sprints, and more via the Jira API.
Updated a month ago (2026-08-19 23:21 UTC)
36
30 npm
1
MIT