What can you do with this server?

The MCP Jira Server enables AI assistants to interact with self-hosted Jira instances through the Model Context Protocol using Personal Access Token authentication. Core Capabilities: Issue Management - Full CRUD operations: view, create, update, delete, and assign issues with support for summary, description, issue type, priority, assignee, labels, components, and custom fields (using customfield_ prefix) Search & Discovery - Search issues using JQL (Jira Query Language) with customizable result limits Comments & Collaboration - Add comments to issues and retrieve all existing comments Project Navigation - List all available projects, get detailed project information, and view available issue types (Bug, Task, Story, Epic, etc.) for specific projects Workflow Management - Transition issues between statuses (e.g., "In Progress", "Done") and manage priority levels (High, Medium, Low) User Information - Retrieve details about the currently authenticated user Authentication & Security - Secure connection using Personal Access Tokens with support for custom User-Agent headers for reverse proxy configurations, working with Jira REST API v2

Which integrations are available for this server?

Provides tools for interacting with self-hosted Jira instances to manage issues, projects, and comments, including capabilities for searching via JQL, transitioning issue statuses, and managing assignments.

How do I use MCP Jira 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., "@MCP Jira Server search for all open issues assigned to me in project PROJ" 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.

MCP Jira Server

by edrich13

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MCP Jira Server for Self-Hosted Jira

A Model Context Protocol (MCP) server for interacting with self-hosted Jira instances using Personal Access Token (PAT) authentication.

Features

✅ Personal Access Token authentication for self-hosted Jira
✅ Create, read, update, and delete Jira issues
✅ Search issues using JQL (Jira Query Language)
✅ Add and view comments
✅ Manage issue assignments
✅ List projects and issue types
✅ Transition issues between statuses
✅ Get current user information

Related MCP server: Jira Cloud MCP Server

Prerequisites

Node.js 18 or higher
A self-hosted Jira instance (e.g., https://jira.domain.com)
A Jira Personal Access Token

How to Create a Personal Access Token in Self-Hosted Jira

Log in to your Jira instance (e.g., https://jira.domain.com)
Click on your profile icon in the top right corner
Select "Profile" or "Account Settings"
Navigate to "Personal Access Tokens" or "Security"
Click "Create token"
Give your token a name (e.g., "MCP Server")
Set an expiration date (optional but recommended)
Click "Create"
Copy the token immediately - you won't be able to see it again!

Installation

Option 1: Using npm (Recommended)

Direct usage with npx:

npx mcp-jira-server

Or install globally:

npm install -g mcp-jira-server

Option 2: From Source

Clone the repository:

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

Install dependencies:

npm install

Build the server:

npm run build

Configuration

For Claude Desktop

Add the following to your Claude Desktop configuration file:

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

Option 1: Using npx (Recommended)

{
  "mcpServers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "mcp-jira-server"],
      "env": {
        "JIRA_BASE_URL": "https://jira.domain.com",
        "JIRA_PAT": "your-personal-access-token-here"
      }
    }
  }
}

Option 2: Using source build

{
  "mcpServers": {
    "jira": {
      "type": "stdio",
      "command": "node",
      "args": ["/Users/edrich.rocha/.nvm/versions/node/v22.6.0/bin/mcp-jira-server"],
      "env": {
        "JIRA_BASE_URL": "https://jira.domain.com",
        "JIRA_PAT": "your-personal-access-token-here"
      }
    }
  }
}

For VS Code with MCP

Create or update .vscode/mcp.json in your workspace:

Option 1: Using npx (Recommended)

{
  "servers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "mcp-jira-server"],
      "env": {
        "JIRA_BASE_URL": "https://jira.domain.com",
        "JIRA_PAT": "your-personal-access-token-here"
      }
    }
  }
}

Option 2: Using source build

{
  "servers": {
    "jira": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-jira-server/build/index.js"],
      "env": {
        "JIRA_BASE_URL": "https://jira.domain.com",
        "JIRA_PAT": "your-personal-access-token-here"
      }
    }
  }
}

Environment Variables

JIRA_BASE_URL: The base URL of your self-hosted Jira instance (e.g., https://jira.domain.com)
JIRA_PAT: Your Personal Access Token
JIRA_USER_AGENT (optional): Custom User-Agent header for Jira instances behind reverse proxies (oauth2-proxy, nginx, etc.) that filter requests by User-Agent. If your API requests get redirected to SSO login despite valid PAT, your reverse proxy may require a specific User-Agent to bypass authentication for API clients.

Available Tools

1. `jira_get_issue`

Get details of a specific Jira issue by its key.

Parameters:

issueKey (string, required): The Jira issue key (e.g., "PROJ-123")

Example:

Get details for issue PROJ-123

2. `jira_search_issues`

Search for Jira issues using JQL (Jira Query Language).

Parameters:

jql (string, required): JQL query string
maxResults (number, optional): Maximum number of results (default: 50)

Example:

Search for all open issues in project PROJ assigned to me

Common JQL Examples:

project = PROJ AND status = Open
assignee = currentUser() AND status != Done
priority = High AND created >= -7d
reporter = john.doe AND status IN (Open, "In Progress")

3. `jira_create_issue`

Create a new Jira issue.

Parameters:

projectKey (string, required): Project key
summary (string, required): Issue title/summary
issueType (string, required): Issue type (e.g., "Bug", "Task", "Story")
description (string, optional): Detailed description
priority (string, optional): Priority level (e.g., "High", "Medium", "Low")
assignee (string, optional): Username to assign to
labels (array, optional): Array of labels
components (array, optional): Array of component names
Custom fields: Any additional parameters prefixed with customfield_ (e.g., customfield_10001)

Example:

Create a new bug in project PROJ with summary "Login page not loading" and high priority

Custom Fields Example:

Create a story in PROJ with custom field customfield_10001 set to "Sprint 1"

4. `jira_update_issue`

Update an existing Jira issue.

Parameters:

issueKey (string, required): Issue key to update
summary (string, optional): New summary
description (string, optional): New description
assignee (string, optional): New assignee username
priority (string, optional): New priority
labels (array, optional): New labels array
status (string, optional): New status (e.g., "In Progress", "Done")
Custom fields: Any additional parameters prefixed with customfield_ (e.g., customfield_10002)

Example:

Update issue PROJ-123 to set status to "In Progress" and assign to john.doe

5. `jira_add_comment`

Add a comment to a Jira issue.

Parameters:

issueKey (string, required): Issue key
comment (string, required): Comment text

Example:

Add a comment to PROJ-123 saying "Fixed in latest deployment"

6. `jira_get_comments`

Get all comments from a Jira issue.

Parameters:

issueKey (string, required): Issue key

7. `jira_get_projects`

List all available Jira projects.

Parameters: None

Example:

List all Jira projects

8. `jira_get_project`

Get details of a specific project.

Parameters:

projectKey (string, required): Project key

9. `jira_get_issue_types`

Get available issue types for a project.

Parameters:

projectKey (string, required): Project key

10. `jira_assign_issue`

Assign a Jira issue to a user.

Parameters:

issueKey (string, required): Issue key
assignee (string, required): Username to assign to

11. `jira_delete_issue`

Delete a Jira issue permanently.

Parameters:

issueKey (string, required): Issue key to delete

⚠️ Warning: This action is permanent and cannot be undone.

12. `jira_get_current_user`

Get information about the currently authenticated user.

Parameters: None

Development

Build the server

npm run build

Watch mode for development

npm run watch

Run in development mode

npm run dev

Testing the Server

After configuring the server, restart Claude Desktop or VS Code to load the new MCP server.

Quick Test Commands

Test authentication:
```
Get my current Jira user information
```
List projects:
```
Show me all Jira projects
```

Search for issues:

Search for all issues assigned to me that are not done

Create an issue:

Create a new task in project PROJ with summary "Test MCP integration"

Troubleshooting

Server not connecting

Verify the absolute path in your configuration
Ensure the server is built (npm run build)
Check that environment variables are set correctly
Restart Claude Desktop or VS Code after configuration changes

Authentication errors

Verify your Personal Access Token is still valid
Check that the token has not expired
Ensure the token has appropriate permissions
Verify the JIRA_BASE_URL is correct (no trailing slash)

API errors

Check Jira server logs for detailed error messages
Verify the Jira API is accessible from your machine
Ensure your user account has necessary permissions
Try accessing the REST API directly: https://jira.domain.com/rest/api/2/myself

Common issues

"Cannot find module": Run npm install and npm run build
"Connection refused": Check if Jira server is accessible and URL is correct
"Unauthorized": Verify your Personal Access Token
"Issue type not found": Use jira_get_issue_types to see valid types for the project
API requests redirect to SSO login: Your Jira may be behind a reverse proxy (oauth2-proxy, nginx) that filters by User-Agent. Set JIRA_USER_AGENT environment variable to a whitelisted User-Agent string. Contact your system administrator to get the allowed User-Agent value.

Security Best Practices

Never commit your Personal Access Token to version control
Store tokens securely in configuration files with restricted permissions
Use tokens with minimal required permissions
Set expiration dates for tokens
Rotate tokens regularly
Monitor token usage in Jira's audit logs

API Reference

This MCP server uses the Jira REST API v2. For more information about Jira's API:

Jira REST API documentation: https://your-jira-instance/rest/api/2/
JQL syntax guide: Check your Jira instance documentation

License

MIT

Support

For issues related to:

MCP Server: Check the logs in Claude Desktop or VS Code
Jira API: Refer to your self-hosted Jira documentation
Authentication: Contact your Jira administrator

Contributing

Contributions are welcome! Please ensure:

Code follows TypeScript best practices
All tools are properly documented
Error handling is comprehensive
Security best practices are followed

Available Tools

12 tools

jira_add_commentB

Add a comment to a Jira issue

ParametersJSON Schema

Name	Required	Description	Default
`issueKey`	Yes	The Jira issue key
`comment`	Yes	The comment text to add

TDQS

B3.4/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 but only states the basic action. It does not disclose whether comments are appended, overwritten, require permissions, or have length limits.

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 wasted words. However, it could afford to include a bit more context without sacrificing brevity.

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 tool with two required string parameters and no output schema, the description covers the basic operation. It does not mention formatting, limits, or whether comments are appended, but is minimally adequate.

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 clear parameter descriptions ('The Jira issue key', 'The comment text to add'). The description adds no additional meaning beyond the schema, earning the 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?

The description clearly states the verb 'Add' and the resource 'comment to a Jira issue', which is specific and distinct from sibling tools like jira_get_comments (retrieving comments) and jira_update_issue (modifying issue fields).

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 such as jira_update_issue or jira_get_comments. The usage is implied but lacks explicit context or exclusion criteria.

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

jira_assign_issueB

Assign a Jira issue to a user

ParametersJSON Schema

Name	Required	Description	Default
`issueKey`	Yes	The Jira issue key
`assignee`	Yes	Username to assign the issue to

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 full burden. It only states 'assign' without disclosing side effects (e.g., overwrites existing assignee), triggers (notifications), or constraints (e.g., assignee must be a valid user in Jira).

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 wasted words. However, it could be slightly expanded to include key behavioral details without becoming verbose.

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 tool with 2 required parameters and no output schema, the description is minimal but functional. It covers the basic purpose but lacks completeness regarding prerequisites, side effects, and parameter semantics.

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. The description adds no additional meaning beyond the schema's parameter descriptions; it merely restates the action. No extra context for parameter values, formats, or constraints.

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 ('assign') and resource ('Jira issue'), and distinguishes from sibling tools like jira_create_issue or jira_update_issue. It is specific and unambiguous.

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 given on when to use this tool versus alternatives (e.g., jira_update_issue), nor any prerequisites or context (e.g., permissions, valid assignee). The description is purely functional.

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

jira_create_issueB

Create a new Jira issue in a specified project

ParametersJSON Schema

Name	Required	Description
`projectKey`	Yes	The project key where the issue will be created
`summary`	Yes	Brief summary/title of the issue
`description`	No	Detailed description of the issue
`issueType`	Yes	Type of issue (e.g., Bug, Task, Story, Epic)
`priority`	No	Priority level (e.g., High, Medium, Low)
`assignee`	No	Username of the person to assign the issue to
`labels`	No	Array of labels to add to the issue
`components`	No	Array of component names
`customFields`	No	Map of additional Jira field IDs/keys (e.g., customfield_10211) to include in the fields payload

TDQS

B3.1/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 but only says 'Create a new Jira issue'. It does not disclose side effects, return value, or required permissions. The minimal disclosure is insufficient for an agent to understand the tool's behavior fully.

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 and to the point. However, it is very brief and could incorporate more structure or context 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?

Given the tool has 9 parameters (some optional), no output schema, and moderate complexity (nested objects), the description is too lacking. It does not mention return values, success behavior, or any constraints, making it incomplete for the agent.

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?

Input schema has 100% description coverage, so each parameter is documented in the schema. The description adds no extra parameter meaning beyond the schema fields, hence baseline score of 3.

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 'Create' and the resource 'Jira issue', and specifies the scope 'in a specified project'. It distinguishes this tool from siblings like jira_update_issue (update) and jira_get_issue (read).

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?

The description provides no guidance on when to use this tool versus alternatives or any prerequisites. It merely states what the tool does without context on when it's appropriate.

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

jira_delete_issueA

Delete a Jira issue permanently

ParametersJSON Schema

Name	Required	Description	Default
`issueKey`	Yes	The Jira issue key to delete

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description bears full burden. It discloses 'permanently' indicating irreversibility. However, it doesn't mention side effects (e.g., removal of comments, attachments) or permission requirements.

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?

A single sentence of 5 words efficiently conveys the tool's purpose. No wasted words.

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 one-parameter tool with no output schema, the description covers the core action. However, it could be more complete by noting the irreversible nature or typical prerequisites.

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 parameter 'issueKey' is well-defined. The description adds no extra meaning beyond the parameter name and schema's description; 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 'Delete a Jira issue permanently' clearly states the action (delete) and resource (Jira issue), and the word 'permanently' adds important scope. It distinguishes from sibling tools like create, update, or reading tools.

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 (e.g., only when issue is no longer needed) or when not to use (e.g., irreversible). No alternatives mentioned. Implied context from purpose but lacking.

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

jira_get_commentsB

Get all comments from a Jira issue

ParametersJSON Schema

Name	Required	Description	Default
`issueKey`	Yes	The Jira issue key

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits like read-only nature, pagination, ordering, authentication requirements, or potential limits. The description carries the full burden but fails to add context beyond the action.

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 redundancy. While minimal, it is not overly verbose. However, it could benefit from slightly more detail 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?

Given the tool is simple (1 param, no output schema), the description is incomplete. It does not mention what the output looks like, whether comments are ordered, or any limitations. The schema covers the parameter, but the description lacks sufficient context for effective use.

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. The description adds no additional meaning beyond the schema's parameter description for 'issueKey'. No further details on formatting or constraints.

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 'all comments from a Jira issue'. It distinguishes from sibling tools (e.g., jira_add_comment, jira_create_issue) by specifying retrieval of comments.

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?

The description provides no guidance on when to use this tool versus alternatives, such as jira_search_issues or jira_get_issue. No exclusions or prerequisites are mentioned.

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

jira_get_current_userA

Get information about the currently authenticated user

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It states 'Get information' implying a read operation, but fails to disclose behavioral traits such as authentication requirements, rate limits, or what data is returned.

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 10-word sentence, concise and front-loaded. However, it sacrifices some completeness for 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?

Given no output schema, the description should explain what information is returned. It only says 'information' without specifics, leaving the agent uncertain about the response format.

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 no parameters (100% coverage). According to calibration, 0 parameters gives a baseline of 4. The description does not add parameter info, but none is needed.

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 'information about the currently authenticated user'. It is distinct from sibling tools which focus on issues, projects, and 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?

No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the name, but the description does not mention any usage context or exclusions.

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

jira_get_issueB

Get details of a specific Jira issue by its key (e.g., PROJ-123)

ParametersJSON Schema

Name	Required	Description	Default
`issueKey`	Yes	The Jira issue key (e.g., PROJ-123)

TDQS

B3.3/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 details' without disclosing it is a read-only operation, what fields are returned, or any behavioral traits. Minimal transparency.

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, clear sentence with no unnecessary words or repetition. It is appropriately front-loaded.

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 low complexity (1 param, no output schema), the description is minimally adequate but fails to mention what kind of details are returned. It is complete enough for a simple get, but could hint at response content.

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% for the single parameter issueKey. The description adds an example format 'e.g., PROJ-123', which is helpful but does not significantly extend meaning beyond the schema. Baseline 3 due to high coverage.

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', the resource 'details of a specific Jira issue', and the identifier 'by its key (e.g., PROJ-123)'. This purpose distinguishes it from siblings like jira_search_issues or jira_get_comments.

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?

The description lacks any guidance on when to use this tool vs. alternatives. It does not mention when to use other tools like jira_search_issues or any exclusions. The usage is only implied.

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

jira_get_issue_typesA

Get available issue types for a project

ParametersJSON Schema

Name	Required	Description	Default
`projectKey`	Yes	The project key

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, and description adds minimal behavioral context beyond the core action. Does not disclose auth requirements, rate limits, or whether the operation is read-only.

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, no redundant information, appropriately sized for the tool's simplicity.

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 get operation with one parameter, description is nearly complete, though it could mention that the return is a list of issue types.

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 single parameter described, and description adds no additional meaning beyond what the schema already provides.

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 uses specific verb 'Get' and resource 'issue types' with context 'for a project', clearly distinguishing from sibling tools like jira_get_issue or jira_get_project.

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?

Implies usage when needing issue types for a project, but no explicit guidance on when to use versus alternatives like jira_search_issues or jira_get_project.

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

jira_get_projectB

Get details of a specific Jira project

ParametersJSON Schema

Name	Required	Description	Default
`projectKey`	Yes	The project key

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits such as required permissions, output structure, or any side effects. It only states 'Get details', which is minimal.

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 front-loads the purpose. However, it could be more informative without being verbose.

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 retrieval tool with one parameter and no output schema, the description is adequate but fails to provide details on what 'details' are returned, leaving some ambiguity.

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% for the single parameter 'projectKey', and the description adds no additional meaning beyond the schema's own description. Baseline score of 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 verb 'Get' and the resource 'specific Jira project', distinguishing it from sibling tools like 'jira_get_projects' (list all) and 'jira_get_issue' (different resource).

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 needing details on one project, but does not explicitly contrast with alternatives like 'jira_get_projects' for listing or 'jira_search_issues' for filtered results.

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

jira_get_projectsA

List all available Jira projects

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description lacks details about authentication, rate limits, response structure, or any constraints (e.g., whether it returns only projects the user has access to).

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, clear sentence with no wasted words. It is front-loaded and conveys the essential purpose immediately.

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 listing tool with no parameters or output schema, the description captures the core functionality. However, it could mention the expected output format or any implicit filtering.

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 no parameters and is fully covered by the description. Since there are no parameters, the description does not need to add parameter-specific meaning.

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 uses the specific verb 'List' and identifies the resource as 'all available Jira projects'. This clearly distinguishes it from its sibling tool 'jira_get_project', which retrieves a single project.

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 the tool's use for listing all projects, but does not explicitly state when to use it versus alternatives like 'jira_get_project' or when not to use it.

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

jira_search_issuesA

Search for Jira issues using JQL (Jira Query Language). Examples: "project = PROJ AND status = Open", "assignee = currentUser() AND status != Done"

ParametersJSON Schema

Name	Required	Description	Default
`jql`	Yes	JQL query string to search for issues
`maxResults`	No	Maximum number of results to return (default: 50)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, leaving the full burden on the description. The description only states it 'searches' but does not disclose return format, pagination behavior, error handling (e.g., invalid JQL), or whether it's read-only (implied but not explicit). Minimal behavioral insight beyond the basic action.

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 examples, no fluff. Purpose is front-loaded and every word earns its place. Examples are embedded efficiently without additional commentary.

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 parameter schema covers the inputs and there is no output schema, the description adequately explains what the tool does but does not describe the output format, result structure, or how results relate to siblings. It is minimally complete for a straightforward search tool but lacks contextual details about pagination and default behavior (though maxResults default is in schema).

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?

Schema coverage is 100%, so baseline is 3. The description adds value by providing concrete JQL examples that demonstrate how to construct queries, going beyond the schema's generic 'JQL query string' description. This helps an agent understand parameter usage effectively.

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 the tool searches for Jira issues using JQL, with specific examples that immediately convey the purpose. Distinguishes from siblings like jira_get_issue (single issue) through the use of search and JQL.

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?

Provides examples of JQL queries, which gives implicit context on how to use the tool. However, no explicit guidance on when to use this over alternatives like jira_get_issue or jira_get_projects, nor any prerequisites or limitations.

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

jira_update_issueC

Update an existing Jira issue

ParametersJSON Schema

Name	Required	Description
`issueKey`	Yes	The Jira issue key to update
`summary`	No	New summary/title for the issue
`description`	No	New description for the issue
`assignee`	No	Username to assign the issue to
`priority`	No	New priority level
`labels`	No	New array of labels
`status`	No	New status/workflow state (e.g., "In Progress", "Done")
`customFields`	No	Map of additional Jira field IDs/keys (e.g., customfield_10211) to include in the fields payload

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 must disclose behavioral traits. It only says 'Update' implying mutation, but lacks details on whether updates are incremental or full replacement, required permissions, or side effects (e.g., notifications).

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 sentence, concise and front-loaded. While it achieves brevity, it sacrifices some necessary detail, but it does not contain wasted words.

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's complexity (8 parameters, nested objects, no output schema), the description is insufficient. It does not explain return values, error handling, or behavior of partial updates, leaving significant gaps for an AI agent.

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?

Input schema has 100% description coverage for all 8 parameters, so the description adds minimal value beyond the schema. The baseline of 3 is appropriate as the description does not enhance parameter understanding.

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 'Update an existing Jira issue' clearly indicates the action and resource. However, it does not differentiate from sibling tools like jira_assign_issue or jira_create_issue, which could cause confusion.

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?

There is no guidance on when to use this tool versus alternatives (e.g., when to use jira_assign_issue instead for assignment-only updates). No context about prerequisites or typical use cases is provided.

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. Dates show when Glama detected each change.

2 tool updatesMay 6, 2026

Changedjira_create_issue1 field changed

addedInput schema / properties / customFields

Added value: +{
+  "additionalProperties": true,
+  "description": "Map of additional Jira field IDs/keys (e.g., customfield_10211) to include in the fields payload",
+  "type": "object"
+}

Changedjira_update_issue1 field changed

addedInput schema / properties / customFields

Added value: +{
+  "additionalProperties": true,
+  "description": "Map of additional Jira field IDs/keys (e.g., customfield_10211) to include in the fields payload",
+  "type": "object"
+}

12 tool updatesv1.0.3Jan 15, 2026
- First observedjira_add_comment
- First observedjira_assign_issue
- First observedjira_create_issue
- First observedjira_delete_issue
- First observedjira_get_comments
- First observedjira_get_current_user
- First observedjira_get_issue
- First observedjira_get_issue_types
- First observedjira_get_project
- First observedjira_get_projects
- First observedjira_search_issues
- First observedjira_update_issue

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose (add comment vs get comments, create vs update vs delete issue, etc.), so an agent can easily differentiate them without confusion.

Naming Consistency5/5

All tools follow a consistent 'jira_verb_noun' pattern using snake_case, with verbs like add, assign, create, delete, get, search, update, making naming predictable.

Tool Count5/5

12 tools is well-scoped for a Jira server, covering CRUD operations, comments, assignment, projects, user info, and search without being excessive or too sparse.

Completeness4/5

Covers essential operations (issue CRUD, comments, assignment, search, projects) but misses issue transitions and linking. Minor gaps that are manageable.

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

Testiny Test ManagementOAuth
io.testiny
An MCP server that provides access to Testiny projects, test cases and test runs
Testing & QA Tools Project Management
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Jira MCP Server
Project Management Developer Tools
abdoosalomov
A
license
Not graded
quality
C
maintenance
Custom MCP server for interacting with Jira, supporting issue management, search, and project operations.
Updated a month ago (2026-08-06 09:49 UTC)
640
2
MIT
Jira Cloud MCP Server
Project Management Developer Tools
aaronsb
A
license
Not graded
quality
A
maintenance
MCP server for interacting with Jira Cloud instances. Enables issue management, JQL queries, project and sprint management, and batch operations via natural language interfaces.
Updated a day ago (2026-09-05 02:51 UTC)
148
4
MIT
Jira MCP OAuth gateway
Project Management Search
Wasim-Shaikh25
F
license
B
quality
D
maintenance
MCP server that connects AI assistants to your Jira site, supporting PAT or SSO authentication for search, read, create, update, and delete operations on issues.
Updated 5 months ago (2026-04-20 06:43 UTC)
17
39
-
mcp-server-jira
Project Management Developer Tools
kt057
F
license
A
quality
D
maintenance
MCP server for JIRA Cloud REST API v3, enabling issue search, creation, updates, comments, and transitions.
Updated 6 months ago (2026-02-22 11:56 UTC)
9
-

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/edrich13/mcp-jira-server'

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

MCP Jira Server for Self-Hosted Jira

Features

Prerequisites

How to Create a Personal Access Token in Self-Hosted Jira

Installation

Option 1: Using npm (Recommended)

Option 2: From Source

Configuration

For Claude Desktop

For VS Code with MCP

Environment Variables

Available Tools

1. jira_get_issue

2. jira_search_issues

3. jira_create_issue

4. jira_update_issue

5. jira_add_comment

6. jira_get_comments

7. jira_get_projects

8. jira_get_project

9. jira_get_issue_types

10. jira_assign_issue

11. jira_delete_issue

12. jira_get_current_user

Development

Build the server

Watch mode for development

Run in development mode

Testing the Server

Quick Test Commands

Troubleshooting

Server not connecting

Authentication errors

API errors

Common issues

Security Best Practices

API Reference

License

Support

Contributing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `jira_get_issue`

2. `jira_search_issues`

3. `jira_create_issue`

4. `jira_update_issue`

5. `jira_add_comment`

6. `jira_get_comments`

7. `jira_get_projects`

8. `jira_get_project`

9. `jira_get_issue_types`

10. `jira_assign_issue`

11. `jira_delete_issue`

12. `jira_get_current_user`