mcp-server-atlassian-jira

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.3.0-ufc.3
Disambiguation5/5
Each tool maps to a distinct HTTP verb or operation (e.g., attach, delete, get, patch, post, put) with clear boundaries. Even jira_get_attachment (download) is separate from jira_get (read data) and jira_attach (upload).
Naming Consistency5/5
All tools follow the 'jira_' prefix with an HTTP-method-like verb (attach, delete, get, get_attachment, patch, post, put). The naming is consistent, predictable, and clearly indicates the action.
Tool Count5/5
With 7 tools covering core CRUD, file attachment, and flexible generic operations, the count is well-scoped for a Jira server. It provides sufficient functionality without unnecessary bloat.
Completeness4/5
The tool set covers all major CRUD operations and file attachments. While jira_get handles searches and listings, a dedicated search tool could improve completeness, but the current surface is largely complete for common Jira workflows.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims delete operations while annotations set readOnlyHint=true, a direct contradiction. Additionally, it does not disclose authentication needs or error behavior beyond noting 204 responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately structured but contains redundant explanations (output format details) and lengthy bullet lists that could be condensed.
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?
While it explains output format and status codes, the critical behavioral contradiction undermines completeness. It omits error handling and permission requirements.
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 repeats some examples but adds little new meaning beyond the schema's own parameter descriptions.
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 it deletes Jira resources and lists specific operations (delete issue, comment, worklog, attachment, remove watcher), distinguishing it from sibling tools like jira_get or jira_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit common operations and endpoint patterns, but does not explicitly state when not to use this tool or suggest alternatives, though sibling names imply boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Partially update' (write operation), but annotations include readOnlyHint: true, creating a direct contradiction. No disclosure of side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but slightly verbose with repeated mentions of TOON. Front-loaded purpose and examples make it easy to scan.
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?
Covers parameters and common operations well, but lacks return value details (no output schema) and the annotation contradiction undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions; the description adds extensive examples for body, path, jq, and outputFormat, significantly improving usability.
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 'Partially update Jira resources' and distinguishes from siblings like jira_post and jira_put by emphasizing PATCH semantics. Examples reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides good usage context with common operations and cost optimization tip, but does not explicitly state when to use alternatives (e.g., PUT for full updates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation readOnlyHint: true by stating it creates resources (mutating operation). This is a serious inconsistency that misleads the agent. The description fails to disclose any further behavioral details beyond the creation aspect.
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 well-structured with sections and front-loaded purpose, but contains verbose examples that could be shortened without losing clarity. Still, each sentence contributes to usability.
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 absence of an output schema, the description lacks details about return values or error responses. It compensates somewhat with request examples, but an agent is left guessing about response structure, which is critical for post-creation handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema covers 100% of parameters with descriptions, the description significantly enhances understanding by providing real-world usage examples for body, jq, and outputFormat. This adds value beyond the schema's bare descriptions.
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 'Create Jira resources' and provides specific common operations (create issue, add comment, etc.) that uniquely identify this as a POST/creation tool, distinguishing it from sibling tools like jira_get (read) or jira_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit cost optimization guidance (using jq param) and provides example operations with exact API paths and body structures. However, it does not explicitly state when NOT to use this tool or list alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, but the description describes a write operation ('upload'). This is a direct contradiction. Beyond that, the description adds useful behavioral context (supported file types, returns metadata), but the contradiction is critical.
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 well-organized with sections, bullet points, and code blocks. Every sentence serves a purpose, no fluff. It is concise yet comprehensive.
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?
Despite the annotation contradiction, the description covers the two attachment methods, supported file types, and return metadata. It lacks permission or size limit info, but is generally complete for the task.
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%, but the description adds significant meaning: explains mutual exclusivity of filePath vs textContent/fileName, provides example values, and clarifies the required relationship between textContent and fileName.
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 'Upload a file attachment to a Jira issue' with specific verb and resource. It distinguishes from sibling tools like jira_get_attachment and provides two concrete usage modes with examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly details two ways to attach files and the required parameters. It also directs users to jira_get for listing attachments, guiding usage context. Could mention when not to use, but it's effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly states that PUT performs a full update, which is a write operation. However, the annotations set readOnlyHint=true, directly contradicting the description's behavior. This is a serious inconsistency, scoring 1 as per guidelines.
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 well-structured with sections and markdown, front-loading key information. It is somewhat lengthy but each part serves a purpose (examples, cost tips, note on PATCH). Minor redundancy in API reference URL.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and nested objects, the description provides rich context: common operations, examples, output format details, and cost optimization. It lacks explicit explanation of TOON format behavior but covers most aspects adequately.
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%, baseline 3. The description adds value by explaining the jq parameter for cost reduction, providing concrete examples for path and body, and detailing outputFormat. This goes beyond the schema's basic descriptions.
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 that the tool replaces Jira resources via full update. It lists specific endpoints and operations, and distinguishes from PATCH for partial updates. The verb 'Replace' and resource context are well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using jq for cost optimization, specifies default output format (TOON), and mentions that PUT is for full replacement while PATCH is for partial updates. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description confirms download behavior. Discloses default save location (temp dir) and return fields. No contradiction with annotations.
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?
Structured with usage block, parameter list, tip, and return info. Length is justified by informative content; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers: how to use, parameter defaults, prerequisite (finding IDs via sibling tool), and return values (file path, filename, MIME type, size). No output schema needed given description richness and annotations.
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%. Description adds usage example, explains default behavior for outputPath, and cross-references jira_get for attachmentId. Provides marginal additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Download a Jira attachment to a local file.' Differentiates from siblings: jira_get gets metadata, jira_attach uploads, etc. The verb 'download' and resource 'attachment' are 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage example and parameter details. Shows how to find attachment IDs via jira_get. Does not explicitly state when not to use, but context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds significant behavioral details: default TOON output format, token efficiency, cost warnings, deprecation notice for '/rest/api/3/search', and schema exploration workflow. All consistent with annotations.
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 lengthy but well-structured with headings, bullet points, and code examples. Every section adds value (purpose, cost optimization, schema discovery, common paths, examples). Minor redundancy (jq examples appear twice) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GET tool with 4 params and no output schema, the description is remarkably complete: return format, cost optimization, schema discovery pattern, common paths, example requests, JQL syntax, API reference link. An agent can confidently invoke this tool without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds extensive context: jq examples, common path list, query parameter examples (maxResults, jql), output format explanation (TOON vs JSON), and JQL query examples. Goes well beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs GET requests to read Jira data, with 'Read any Jira data.' and a title 'Jira GET Request'. It distinguishes from sibling write tools (jira_post, jira_patch, etc.) by its read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit cost optimization guidance (use jq, maxResults), a schema discovery pattern, and common paths. Does not explicitly state when not to use this tool, but sibling tools are all write operations so differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-atlassian-jira MCP server](https://glama.ai/mcp/servers/asky74/mcp-server-atlassian-jira/badges/card.svg)](https://glama.ai/mcp/servers/asky74/mcp-server-atlassian-jira)

Score Badge

Copy to your README.md:

[![mcp-server-atlassian-jira MCP server](https://glama.ai/mcp/servers/asky74/mcp-server-atlassian-jira/badges/score.svg)](https://glama.ai/mcp/servers/asky74/mcp-server-atlassian-jira)

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

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