jira-dev-mcp

Server Quality Checklist

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

Latest release: v1.4.5
Disambiguation5/5
Every tool has a clearly distinct purpose. The closest pair, jira_read_task and jira_analyze_task, is explicitly disambiguated: one is data-only, the other is a full workflow. Downloading single vs all attachments is also clearly distinguished.
Naming Consistency4/5
All tools follow a jira_verb_noun pattern except jira_my_tasks, which breaks the convention by using a possessive adjective instead of a verb. Otherwise, naming is highly consistent and predictable.
Tool Count5/5
With 10 tools, the set is well-scoped for a Jira dev integration. Each tool satisfies a distinct need, from project path mapping to comments, search, attachments, and a comprehensive analysis workflow.
Completeness4/5
The tool surface covers core read, search, comment, attachment, and workflow-driven analysis. Minor gaps exist—no issue creation, status transition, or assignment modification—but these are outside the apparent focus on investigation and commenting.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT 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

Behavior2/5
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 only mentions returning the comment URL, but omits important traits such as the need for authentication, the two-step confirmation flow (preview then confirm), and the fact that posting is a mutating action. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the primary purpose and then provides a useful verification detail without any 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?
The tool has a non-trivial flow (optional confirmation token) that is not explained in the description. The description is too minimal to fully inform the agent about when to provide confirm_token or how the preview step works, making it incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover 100% of parameters with meaningful definitions (key, body, confirm_token), so the baseline is 3. The description adds no further parameter context, but it is not required given the schema's thoroughness.
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's function with a specific verb ('Post') and resource ('comment on a Jira issue'), and the distinction from sibling jira_edit_comment is evident. It also adds a concrete outcome (returns the comment URL), making the purpose unambiguous.
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 when to use the tool (to post a comment) but does not explicitly mention alternatives like jira_edit_comment for editing comments, nor does it explain the preview/confirm_token workflow. This leaves usage context somewhat implicit rather than fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not explain what happens if no mapping exists, error behavior, or the output format. For a getter tool, this lack of context is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently states the action and the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the return format or failure behavior but only states what the tool gets. The agent is left guessing about the response structure and error handling, which is critical for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions (e.g., 'Jira project key (e.g. AT)'), yielding 100% schema description coverage. The description adds no extra parameter detail, so the 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 uses a specific verb ('Get') and resource ('local repository path mapped to a Jira project key'), clearly distinguishing it from sibling tools like jira_set_project_path or jira_search_issues. It immediately conveys the exact function.
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 when to use it (when you need the local repository path for a Jira project key) but does not explicitly state when not to use it or mention alternatives. No exclusion or comparison with sibling tools is provided, so guidance is minimal.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that text files (txt, md, json, log) are returned inline, CSV/XLS/XLSX/PDF are parsed into structured text, and images/binaries are returned as base64. This is significant added context, though it omits potential error responses or auth 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?
The description is three concise sentences with no redundancy. The main action is front-loaded, and file-type handling follows logically. Every sentence adds meaningful information, making it highly scannable and efficient.
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?
Without an output schema, the description compensates by explaining the main return format categories (inline, structured text, base64). It is incomplete regarding error handling and the exact JSON structure, but it covers the core behavior well for a download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters, giving 100% coverage. The description adds value by connecting attachment MIME types to output formats, but it does not clarify parameter semantics beyond schema, such as the meaning of response_format options or how to locate the 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 'Download an attachment from a Jira issue', specifying both the action (download) and the resource (attachment). It distinguishes from sibling tools like jira_download_all_attachments by focusing on a single attachment, and from jira_read_task by targeting attachment content rather than 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like jira_download_all_attachments. It does not mention prerequisites (e.g., obtaining filename via jira_read_task) or exclusions, leaving usage entirely inferred from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the return fields (keys, summaries, statuses, assignees), which is helpful, but does not mention read-only nature, error handling, pagination behavior, or any side effects. This is adequate but leaves gaps.
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 exactly two sentences, front-loaded with the action and resource, followed by return information. No filler or redundant phrasing.
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?
The tool has 4 parameters fully documented in the schema and no output schema. The description covers the main search behavior and return fields, which is sufficient for basic usage. It could mention pagination or output format handling, but the schema already provides these details, so the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides; 'natural language keywords or raw JQL' duplicates the schema's query description. The other parameters (startAt, maxResults, response_format) are fully described in the schema and not expanded in the description.
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 states 'Search Jira issues using natural language keywords or raw JQL' with a specific verb and resource, and lists return fields (keys, summaries, statuses, assignees). This clearly distinguishes it from sibling tools like jira_read_task and jira_my_tasks, which focus on retrieving specific tasks rather than searching.
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 provides clear context on when to use the tool: for searching issues with keywords or JQL. It implies the agent should use this for flexible search scenarios. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 disclose a key downstream effect (enabling jira_read_task to include the path hint), but it does not state whether the mapping overwrites an existing one, whether it persists, or any authorization requirements. This is a reasonable but not fully transparent disclosure.
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 two tightly written sentences. The first sentence states the core action, and the second explains the practical benefit for jira_read_task. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter setter with no output schema, the description covers the main action, the purpose, and a meaningful integration context. It does not describe the return value or explain behavior on repeated calls, but given the tool's low complexity, this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have clear descriptions in the schema). The description's mention of 'Jira project key' and 'local repository path' mirrors the schema without adding new constraints, formats, or examples, so it meets the baseline for high schema coverage without adding extra semantic value.
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 'Map' with clear resources ('Jira project key' and 'local repository path'), and the mention of enabling jira_read_task distinguishes it from the sibling jira_get_project_path. Purpose is immediately clear 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?
The description gives clear context by explaining when this tool is useful: before jira_read_task, to include a local path hint for code exploration. It does not explicitly state when not to use it or mention the inverse tool jira_get_project_path, but the situational guidance is strong enough for an agent to select it appropriately.
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?
With no annotations present, the description carries the full burden. It clearly indicates a read-only operation ('List') and scopes results to the authenticated user, implying safe usage. It does not mention pagination details or response format, but these are partially covered by the schema, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence without any wasted words. It efficiently conveys the tool's purpose and the key optional filter.
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 output schema, the description covers the core functionality and filter. It does not explicitly describe the response format, but the response_format parameter in the schema addresses that, so the description is sufficiently complete.
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?
All four parameters are fully described in the schema (100% coverage), so the description adds minimal parameter semantics beyond reinforcing the 'status' filter. The baseline of 3 applies because the schema does the heavy lifting.
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 verb 'List' and specifies the resource as 'Jira issues assigned to the currently authenticated user', which is specific and clearly differentiates from sibling tools like jira_search_issues or jira_read_task. The optional status filter further clarifies the tool's scope.
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 clearly states that the tool lists issues assigned to the current user, giving a solid context for when to use it. It does not explicitly mention alternatives or exclusions, so it falls short of a 5 due to lack of '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?
No annotations are present, so the description carries the full burden. It discloses the tool's range of actions: reading issues/comments/attachments, idempotency detection, template selection, and a step-by-step SOP culminating in posting a comment. This provides substantial transparency about behavior, though it does not explicitly warn about side effects or output details.
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 four sentences, with a clear lead, a compact list of capabilities, and a specific usage directive. Every sentence adds distinct information; there is no fluff or redundancy.
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?
The tool is complex with a multi-step workflow, and the description covers many aspects: accepted input, data sources, idempotency, template selection, and SOP steps. However, there is no output schema, and the description does not explicitly state what the tool returns beyond 'provides step-by-step SOP,' leaving the actual return value ambiguous. This gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptions for all four params. The description only reiterates the input format (issue key or URL) in the same words, adding no extra semantic meaning. Therefore, 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 opens with 'Full investigation and fix workflow for a Jira issue,' which clearly names the verb (analyze/fix) and resource (Jira issue). It further differentiates from the sibling by directing users to 'use this instead of jira_read_task when you want to drive the full workflow end-to-end,' making the tool's purpose distinct and specific.
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?
The description explicitly states when to use this tool over jira_read_task, providing a clear alternative. It also describes the workflow steps (explore → plan → implement → verify → comment), giving context on appropriate usage scenarios. No exclusion criteria are mentioned, but the guidance is sufficient.
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?
With no annotations, the description carries the full burden. It discloses that attachments are returned inline and that the operation is a single bulk call, plus the filtering behavior. It doesn't mention potential size limits or rate limits, but for a read-only download tool this is reasonable.
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?
Three concise sentences, front-loaded with the core action, and each sentence adds value with no redundancy.
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 tool with 3 params and no output schema, the description fully explains purpose, usage, and return behavior. It could mention edge cases like no attachments, but overall it's sufficiently complete.
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 covers all 3 parameters with descriptions, so baseline is 3. The description adds slightly by giving a concrete example for mime_filter and noting it's optional, but doesn't go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download') and resource ('all attachments from a Jira issue'), and clearly distinguishes itself from the sibling tool jira_download_attachment by stating it replaces multiple calls.
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 states when to use this tool ('Use this instead of multiple jira_download_attachment calls') and mentions optional MIME type filtering, which covers the key usage scenarios.
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?
With no annotations provided, the description carries the transparency burden. It clearly states this is a data-only read operation ('Read raw details', 'Data-only') and explicitly says it does not post comments or guide analysis, giving confidence that it has no side effects. However, it does not mention pagination behavior or any potential rate limits, which leaves minor gaps.
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 three sentences, each earning its place: the first states exactly what the tool does, the second clarifies its scope limitations, and the third directs to the alternative workflow. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description provides a solid overview of its purpose, the data it returns, and its distinction from siblings. It does not explain default pagination values or error handling, but those are covered in the schema. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'Comment pagination offset', 'Include comments (default false)'). The tool description adds a list of returned fields (description, subtasks, changelog, labels, priority, parent, attachments) which provides context, but does not add meaning to individual parameters beyond what the schema already offers. 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 uses a specific verb ('Read raw details') and a concrete resource ('a Jira issue'), enumerating the exact fields returned. It explicitly distinguishes itself from jira_analyze_task, noting it does NOT guide analysis, which clearly separates it from a key sibling tool.
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?
The description explicitly tells the reader when to use this tool vs. an alternative: 'Use jira_analyze_task when you need the full investigation workflow.' It also provides exclusions ('does NOT guide analysis or post comments'), making the usage boundary clear.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly explains the two-step manual mode (preview first, then confirm_token to apply), which is a key behavioral trait. It could also mention error handling or what happens on invalid confirm_token, but the core behavior is disclosed.
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 two sentences that front-load the primary purpose and then concisely explain the manual mode. Every word earns its place, with no redundancy or filler.
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 simple tool with four well-documented parameters and no output schema, the description covers the essential context: what the tool does, the manual mode flow, and the role of confirm_token. No additional information is necessary for an agent to select and invoke the tool correctly.
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 provides 100% coverage with parameter descriptions, so the bar for added value is moderate. The description adds meaningful context by explaining the relationship between parameters: without confirm_token, it previews; with it, the update applies. This clarifies when each parameter is needed beyond the schema's standalone 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 the verb ('Edit') and resource ('existing Jira comment'), which distinguishes it from sibling tools like jira_add_comment. It also introduces the manual mode behavior, making the tool's purpose 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?
The description implies when to use it: for editing existing comments, as opposed to adding. It mentions manual mode with a preview and confirm_token, but does not explicitly state when not to use it or name alternative tools, leaving a small gap.
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:

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

Score Badge

Copy to your README.md:

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

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/nianyi778/jira-dev-mcp'

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