This server connects to a Jira Enterprise instance via a Personal Access Token (PAT) and exposes a comprehensive set of tools for read and write operations on projects, issues, attachments, comments, worklogs, and more.
Test connectivity – Verify your PAT and retrieve the current user profile.
List projects – View all Jira projects accessible to your token.
Fetch issues – Look up an issue by key, including common fields and rendered metadata; optionally retrieve screenshot/image attachments as MCP image content.
Fetch attachments – Get attachment metadata and optionally download raw file bytes as base64; image attachments also include MCP image preview content.
Inspect creation metadata – View issue creation metadata for a project and issue type, with a fallback when createmeta is unavailable.
Search issues – Run JQL queries to find issues, with configurable result limits.
Create issues – Create new issues with a summary, description, issue type, and project.
Update issues – Modify fields such as summary, description, assignee, and priority on existing issues.
List comments – Retrieve all comments on an issue in a simplified format.
Add comments – Post a new comment to an existing issue.
Manage transitions – List available workflow transitions for an issue or execute a specific transition by ID, optionally with a comment.
Upload attachments – Attach base64-encoded files to an issue, or upload a file and simultaneously post a comment referencing it (with optional inline image markup).
View linked issues – Fetch all issues linked to a given issue.
View & add worklogs – Retrieve worklog entries for an issue or log time spent with an optional comment and start timestamp.
Provides tools for interacting with Jira, enabling AI agents to manage issues, projects, comments, attachments, worklogs, and perform JQL searches programmatically.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jira Enterprise MCP find issues assigned to me with priority High"
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.
Small MCP server for Codex that connects to enterprise Jira with a Jira personal access token.
Tests connectivity to Jira
Lists accessible Jira projects
Looks up a Jira issue by key
Looks up a Jira issue by key, including derived acceptance criteria when present in a custom field
Looks up a Jira issue by key and can return screenshot/image attachments as MCP image content, including derived acceptance criteria when present in a custom field
Fetches individual attachments and can return raw attachment bytes as base64, with image attachments also exposed as MCP image content
Inspects issue creation metadata for a project and issue type, with a fallback for tenants that do not expose createmeta
Runs JQL searches
Creates a Jira issue
Updates an existing issue
Lists issue comments
Lists or performs issue transitions
Uploads attachments to an issue
Uploads an attachment and posts a comment that references it, with optional inline image markup
Lists linked issues
Fetches and creates worklog entries
Adds a comment to an existing issue
Related MCP server: Jira MCP Server
Node.js 18+
A Jira PAT that works against your Jira instance
Network access to your Jira base URL
Install dependencies:
npm installCopy .env.example to .env and fill in your values if you want a local template file:
cp .env.example .envExport the variables before launching the MCP server, or let your MCP host pass them in:
export JIRA_BASE_URL=https://your-jira.example.com
export JIRA_PAT=your-token
export JIRA_DEFAULT_PROJECT=YOURPROJECT
export JIRA_REQUEST_TIMEOUT_MS=30000
export JIRA_MAX_ATTACHMENT_BYTES=26214400npm startNote: this server reads JIRA_BASE_URL, JIRA_PAT, and JIRA_DEFAULT_PROJECT from process.env. It does not load .env automatically, so .env.example is a template, not a runtime loader.
src/index.js starts the stdio transport only.
src/server.js builds the MCP server and wires tool listing/call handlers.
src/jira-client.js owns Jira HTTP requests, auth headers, timeouts, attachment downloads, and uploads.
src/tools/*-tools.js co-locates each feature area's MCP tool schemas with its handlers.
src/tools/registry.js combines feature modules into the MCP tool list and dispatch table.
src/config.js, src/validation.js, src/jira-formatters.js, and src/mcp-content.js keep shared config, validation, serialization, and MCP response helpers isolated.
Use this order when validating a new PAT against your Jira instance:
jira_test_connection
jira_list_projects
jira_get_create_meta
jira_get_issue
jira_get_issue_with_images
jira_get_attachment
jira_list_issue_comments
jira_transition_issue
jira_update_issue
jira_search
jira_create_issue
jira_add_attachment
jira_add_comment_with_attachment
jira_get_issue_links
jira_get_worklog
jira_add_worklog
jira_add_comment
This matters because enterprise Jira tenants often allow reads before creates, and issue creation may require project-specific issue types or custom fields.
If you are using Codex locally, point an MCP entry at this server command:
{
"mcpServers": {
"jira-enterprise": {
"command": "node",
"args": ["/absolute/path/to/src/index.js"],
"env": {
"JIRA_BASE_URL": "https://your-jira.example.com",
"JIRA_PAT": "YOUR_PAT",
"JIRA_DEFAULT_PROJECT": "YOURPROJECT"
}
}
}
}If you prefer the Codex CLI helper, the shape should be equivalent to:
codex mcp add jira-enterprise --env JIRA_BASE_URL=https://your-jira.example.com --env JIRA_PAT=YOUR_PAT --env JIRA_DEFAULT_PROJECT=YOURPROJECT -- node /absolute/path/to/src/index.jsThe exact config location can vary by Codex app version, so use whichever local MCP configuration flow your Codex build exposes.
For Claude clients that support local MCP servers, use the equivalent mcpServers entry and pass the same environment variables:
{
"mcpServers": {
"jira-enterprise": {
"command": "node",
"args": ["/absolute/path/to/src/index.js"],
"env": {
"JIRA_BASE_URL": "https://your-jira.example.com",
"JIRA_PAT": "YOUR_PAT",
"JIRA_DEFAULT_PROJECT": "YOURPROJECT"
}
}
}
}If your Claude app exposes an MCP configuration file or settings UI, add the server there. The important part is that Claude launches node /absolute/path/to/src/index.js with those three env vars present.
This server uses Authorization: Bearer <PAT>.
JIRA_REQUEST_TIMEOUT_MS and JIRA_MAX_ATTACHMENT_BYTES are optional safety limits. Defaults are 30 seconds and 25 MiB.
If your Jira instance accepts UI logins but rejects API calls, the PAT may not be enabled for your tenant or may require a different auth scheme.
If your Jira admins require custom CA certificates, you may need to trust that certificate at the OS or Node runtime level before this server can connect cleanly.
On some Jira tenants, createmeta may return 404 "Issue Does Not Exist". The MCP falls back to project issue types and workflow statuses so you can still discover valid issue types even when field-level create metadata is unavailable.
jira_test_connection
jira_list_projects
jira_get_issue
jira_get_issue_with_images
jira_get_attachment
jira_list_issue_comments
jira_transition_issue
jira_update_issue
jira_get_create_meta
jira_search
jira_create_issue
jira_add_attachment
jira_add_comment_with_attachment
jira_get_issue_links
jira_get_worklog
jira_add_worklog
jira_add_comment
jira_get_attachment with includeContent: false returns attachment metadata only.
jira_get_attachment with includeContent: true returns raw file bytes in contentBase64 with contentEncoding: "base64".
For image attachments such as PNGs, the tool also includes MCP image preview content, but the downloadable bytes are always in contentBase64.
Upload a file attachment to a Jira issue using base64-encoded content.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Filename to store in Jira | |
| issueKey | Yes | Jira issue key, for example ABC-123 | |
| mimeType | No | Optional MIME type, for example image/png | |
| contentBase64 | Yes | Base64-encoded file content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions base64-encoded content but does not reveal constraints like file size limits, required permissions, or error handling. It does not contradict any annotations, however.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema or annotations, the description is too sparse. It does not explain return values, error cases, or constraints like file size limits, which are critical for a file upload operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the parameters are already well-documented. The description adds the detail of base64 encoding, but does not provide significant additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a file attachment to a Jira issue using base64-encoded content. It provides a specific verb and resource, but does not differentiate from the sibling tool 'jira_add_comment_with_attachment' which also uploads attachments albeit to comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'jira_add_comment_with_attachment'. No context is given about prerequisites, limitations, 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.
Add a comment to an existing Jira issue.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | Comment body | |
| issueKey | Yes | Jira issue key, for example ABC-123 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as authentication requirements, error handling, or the nature of the operation (e.g., irreversible). The description is too minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise. However, it is overly brief, not fully earning the highest score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description is minimally adequate but lacks details on return values or error conditions. Completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no additional value beyond the parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and resource 'comment to an existing Jira issue', leaving no ambiguity about what the tool does. It is distinct from siblings like jira_add_comment_with_attachment due to the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like jira_add_comment_with_attachment or when not to use it. Lacks prerequisites or context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload an attachment to a Jira issue and then post a comment that references it, with optional inline image markup.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Comment body to post after the attachment upload | |
| filename | Yes | Filename to store in Jira | |
| issueKey | Yes | Jira issue key, for example ABC-123 | |
| mimeType | No | Optional MIME type, for example image/png | |
| embedInline | No | When true, add Jira wiki-style inline image markup for image attachments. Defaults to true. | |
| contentBase64 | Yes | Base64-encoded file content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the dual-operation nature and inline image markup option, but lacks details on atomicity, error handling, authentication requirements, or how the comment references the attachment (e.g., automatically appended text). The behavioral description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. Every part contributes to the purpose: upload, comment, reference, inline markup. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 100% schema coverage, and no output schema or annotations, the description is minimal. It does not explain the exact mechanism of how the comment references the attachment, nor the behavior when 'embedInline' is false. Some additional context on error handling or the final comment structure would improve completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds contextual meaning by explaining the overall workflow (upload then comment) and the effect of 'embedInline'. However, it does not significantly extend beyond the schema descriptions, which are already clear. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads an attachment to a Jira issue and then posts a comment referencing it, with optional inline image markup. This distinctively differentiates it from sibling tools like 'jira_add_attachment' (upload only) and 'jira_add_comment' (comment only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when both actions are needed together, but it does not explicitly state when to use it over calling the two sibling tools separately, nor does it provide exclusions (e.g., when only one action is needed). The usage context is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a worklog entry to a Jira issue.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Optional worklog comment | |
| started | No | Optional start timestamp in Jira format, for example 2026-04-09T09:00:00.000-0400 | |
| issueKey | Yes | Jira issue key, for example ABC-123 | |
| timeSpent | Yes | Time spent string, for example 1h 30m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action. It does not mention that this is a write operation, that it may require issue edit permissions, or any side effects like overwriting existing worklogs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is too terse. It could include key details like required parameters or example usage while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what the tool returns (e.g., worklog ID, issue update). For a data-adding tool, this is a significant gap, leaving the agent unsure about the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters are documented in the input schema. The description does not add any additional meaning beyond the schema, which is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'worklog entry to a Jira issue', which distinguishes it from sibling tools like jira_add_comment or jira_add_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when to use jira_get_worklog to read or jira_add_comment for comments. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Jira issue in the given project.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | Short issue summary | |
| issueType | Yes | Issue type name, for example Task, Story, or Bug. | |
| projectKey | No | Project key. Falls back to JIRA_DEFAULT_PROJECT if omitted. | |
| description | No | Issue description |
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 'Create a Jira issue' without disclosing behavioral traits like permissions needed, whether the issue is created immediately, or what the response looks like. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point—one sentence with no unnecessary words. It is appropriately front-loaded and gets the key idea across, though it could be slightly more detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more completeness. It omits return value information, required permissions, and error conditions. For a creation tool with 4 parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3. The description adds no additional meaning beyond the schema, e.g., it does not clarify in-depth usage of 'summary' or 'description' fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Jira issue in a given project, which is specific and distinct from sibling tools like jira_update_issue or jira_add_comment. The verb 'Create' and resource 'Jira issue' are clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when to use jira_get_create_meta first or prerequisites like required permissions. The description does not indicate any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Jira attachment metadata and optionally include attachment content. When includeContent is true, raw attachment bytes are returned as base64 in the JSON payload; image attachments also include MCP image preview content.
| Name | Required | Description | Default |
|---|---|---|---|
| attachmentId | Yes | Jira attachment id | |
| includeContent | No | When true, download the attachment content and return raw bytes as base64 in contentBase64. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that includeContent returns base64 bytes and image preview, adding behavioral context beyond the schema. However, it does not mention any side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then detail. Every sentence adds value, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description covers the main functionality: fetching metadata and optionally content. It does not detail metadata fields but is still sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning by explaining what includeContent does (base64, preview), going beyond the schema's description. This justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches Jira attachment metadata and optionally includes content. It uses a specific verb+resource and distinguishes from sibling tools like jira_add_attachment (adds) and jira_get_issue (gets issue).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching attachment info but provides no explicit when-to-use or when-not-to-use guidance compared to siblings. It is adequate but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect issue creation metadata for a project, optionally filtered to a specific issue type. Falls back to project issue types and statuses when this Jira tenant does not expose createmeta.
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | No | Project key. Falls back to JIRA_DEFAULT_PROJECT if omitted. | |
| issueTypeName | No | Optional issue type name, for example Task, Story, or Bug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses fallback behavior when createmeta is not exposed. No annotations provided, so description carries burden; could mention read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, efficiently conveys purpose and fallback.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description omits what metadata includes. Adequate given simple parameters but lacks return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond schema: explains default for projectKey and gives example values for issueTypeName. Baseline 3 since coverage 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'inspect' and resource 'issue creation metadata for a project', with optional filtering by issue type. Distinct from sibling creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for inspecting metadata before issue creation, mentions fallback behavior but no explicit when-not or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Jira issue by key, including common fields and rendered metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, for example ABC-123 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions fetching with common fields and rendered metadata, omitting any behavioral traits like error handling, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, front-loaded with purpose, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description lacks explanation of return format or field details; adequate for a simple get tool but vague on 'common fields and rendered metadata'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter description for issueKey; the tool description adds context about fetching by key but does not enrich parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Fetch', resource 'Jira issue', and specifies 'by key' with inclusion of 'common fields and rendered metadata', distinguishing it from sibling tools like jira_search and jira_get_issue_with_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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; usage is implied from the name and description but lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch linked issues for a Jira issue in a simplified shape.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, for example ABC-123 |
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 does not mention read-only nature, rate limits, authentication requirements, or what 'simplified shape' entails beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key action. However, it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should hint at what fields or structure the 'simplified shape' returns. It does not, leaving the agent uninformed about the return value. The description is adequate only for the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'issueKey' already explained. The description adds no additional meaning or context beyond the schema, meeting the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'linked issues for a Jira issue', and hints at a 'simplified shape', distinguishing it from siblings like jira_get_issue which retrieves the full issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention scenarios where it is preferred or when to avoid it, and lacks references to sibling tools despite their availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Jira issue with attachment metadata and include screenshot/image attachments as MCP image content.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, for example ABC-123 | |
| maxImages | No | Maximum number of image attachments to include. Defaults to 5, max 10. | |
| includeImageData | No | When true, download image attachments and return them as MCP image content. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses that the tool downloads image attachments, which is a key behavioral trait. However, it does not mention side effects, rate limits, or requirements for authentication, and it lacks detail on how images are included (e.g., size limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. It contains no fluff or redundant information, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 3 parameters and no output schema, the description is fairly complete. It explains what the tool does and that it includes images. However, it could mention that the tool also returns issue metadata along with images, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides, so the score remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a Jira issue with attachment metadata and includes images as MCP content. It distinguishes from sibling jira_get_issue, which likely does not include images, making the purpose 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when images are needed, but it does not explicitly state when not to use it or mention alternatives like jira_get_issue for text-only cases. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch worklogs for a Jira issue.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, for example ABC-123 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details beyond the basic action. Missing information on return format, pagination, ordering, or permissions, which is insufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no extraneous information, achieving maximum conciseness for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks details about what the returned worklogs contain or potential limits, making it marginally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, with the single parameter issueKey fully described. The description adds no additional semantic value beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'worklogs for a Jira issue,' making the tool's purpose specific and distinguishable from siblings like jira_get_issue or jira_add_worklog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving worklogs but does not explicitly state when to use this tool versus alternatives, nor does it provide context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List comments for a Jira issue in a simplified shape.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, for example ABC-123 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether comments are paginated, ordered, require authentication, or what 'simplified shape' entails. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It efficiently communicates the core action and resource, earning its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no output schema, the description is too minimal. It fails to explain the return format, pagination, or any limitations, leaving the agent without critical context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (issueKey) with a clear description. The tool description adds no additional meaning beyond the schema, which is acceptable given the baseline of 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list comments) and the resource (a Jira issue), using a specific verb+resource pair. It distinguishes from sibling tools like jira_add_comment and jira_get_issue. The phrase 'in a simplified shape' adds slight ambiguity but does not obscure the overall purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 over alternatives, nor are any exclusions or prerequisites mentioned. The description only states what it does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Jira projects visible to the PAT. Useful for validating access and choosing a default project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that listing is scoped to PAT visibility. For a simple read tool, this is adequate. Could mention if there is pagination or output limits, but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. First sentence states action and scope; second sentence provides context for when to use. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple purpose, the description fully informs the agent about the tool's function and application. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline is 4. Description adds value by explaining the output (list of projects visible to PAT) and its utility, compensating for lack of input schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List', resource 'Jira projects', and scope 'visible to the PAT'. Distinguishes from sibling tools (all issue/attachment related). Provides practical use cases: validating access and choosing a default project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly guides usage by stating usefulness for validating access and choosing a default project, suggesting it should be used before other operations. No explicit when-not-to-use or alternatives, but no sibling tool directly competes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a JQL search in Jira.
| Name | Required | Description | Default |
|---|---|---|---|
| jql | Yes | JQL query string | |
| maxResults | No | Maximum number of issues to return. Default is 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as pagination behavior, error handling for invalid JQL, or any side effects. The only additional info is from the schema, which is not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, but it may be too brief for a complex JQL search tool. It earns its place but lacks additional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of JQL searches and the lack of annotations and output schema, the description is insufficient. It does not explain what JQL is, what the output format is, or any constraints like maximum results beyond what the schema provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'run a search' and the resource 'Jira' using JQL, distinguishing it from sibling tools which are specific CRUD operations. However, it does not explicitly mention that it returns issues, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 provide any context for when a search is appropriate compared to other tools like get_issue or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that the Jira PAT works and return the current user profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It clearly states the tool is a read-only verification and returns user profile. It does not mention side effects or error behavior, but for a simple test tool, transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete for its intended simplicity. It covers the action and the expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter meaning. The schema coverage is 100%, and the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verify PAT and return current user profile. It uses a specific verb 'verify' and a resource, and distinguishes clearly from sibling CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives, but the purpose implies it is for testing connection before other operations. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available transitions for an issue or perform a transition by id.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Optional comment to add while transitioning the issue. | |
| issueKey | Yes | Jira issue key, for example ABC-123 | |
| transitionId | No | Transition id to execute. If omitted, the tool lists available transitions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only reveals two modes (list or perform) and a conditional on transitionId. It omits side effects (e.g., notifications, permissions required) and output details, which are critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the dual purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two modes, but the description does not explain what the output looks like (e.g., format of listed transitions, response after performing). Given no output schema, this gap limits usability for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds value by explaining that omitting transitionId lists transitions, and that comment is optional. This conditional behavior is not captured in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs (list, perform) and clearly identifies the resource (transitions for an issue). It distinguishes this tool from sibling tools, as none of the others deal with transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, when listing is appropriate, or when performing should be done.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update selected common fields on an existing Jira issue.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | No | Updated issue summary | |
| issueKey | Yes | Jira issue key, for example ABC-123 | |
| description | No | Updated issue description | |
| assigneeName | No | Assignee username or account identifier supported by the tenant | |
| priorityName | No | Priority name, for example High |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries full burden for behavioral disclosure. It only states 'update' but does not describe whether updates are atomic, how omitted fields are handled (left unchanged?), required permissions, or side effects. Significant transparency gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundancy. It efficiently conveys the core purpose. Minor improvement could be made to elaborate on 'common fields' but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no output schema or annotations, the description is minimally adequate. It implies updating only provided fields but lacks details on success/failure responses or idempotency. Sibling diversity demands more context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds marginal value by framing the fields as 'selected common fields', hinting at limited scope. Baseline 3 is appropriate as the description does not introduce new semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and resource ('existing Jira issue') and specifies it operates on 'selected common fields', which distinguishes it from creating issues or transitioning them. Sibling tools like jira_create_issue and jira_transition_issue reinforce this differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_create_issue or jira_transition_issue. It does not mention prerequisites, scenarios, or exclusions, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0jira_add_attachmentjira_add_commentjira_add_comment_with_attachmentjira_add_worklogjira_create_issuejira_get_attachmentjira_get_create_metajira_get_issuejira_get_issue_linksjira_get_issue_with_imagesjira_get_worklogjira_list_issue_commentsjira_list_projectsjira_searchjira_test_connectionjira_transition_issuejira_update_issueMost tools have distinct purposes, but `jira_add_attachment` and `jira_add_comment_with_attachment` overlap in attachment functionality, potentially causing misselection. Descriptions help clarify, so ambiguity is minimal.
All tools follow the `jira_verb_noun` pattern consistently. Naming is predictable and clear, with only minor exceptions like `search` (no noun) which is still unambiguous.
17 tools is slightly above the typical well-scoped range but reasonable for a complex system like Jira. The set covers many aspects without being excessive.
Core issue operations (create, read, update, transition) are covered, but a delete issue tool is missing. Other gaps like project management and user operations are acceptable for a focused MCP server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
An MCP server that provides access to Testiny projects, test cases and test runs
MCP server for Linear project management and issue tracking
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/w-10-m/jira-enterprise-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
