Personal JIRA MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between attachment-related tools (download_all_attachments, get_attachment_by_filename, get_issue_attachment, get_issue_attachments, getIssues includes attachments) that could cause confusion about which to use. However, core issue operations (create, get, update, search) and project operations are clearly distinct.
Naming Consistency2/5
The naming is inconsistent with mixed conventions: most tools use snake_case (create_issue, get_issue), but getIssues uses camelCase. There's also redundancy in naming (get_issue_attachment vs get_attachment_by_filename) and unclear verb choices (debug_issue_fields stands out as different from other CRUD-style names).
Tool Count4/5
12 tools is reasonable for a JIRA server covering issues, projects, and attachments. While there are some redundant tools, the count aligns well with the domain scope and doesn't feel excessive or insufficient for basic JIRA operations.
Completeness4/5
The toolset covers core JIRA workflows well: CRUD for issues (create, get, update, search), project access (get, list), and attachment handling. Minor gaps include no delete operations for issues or attachments, and debug_issue_fields is a niche tool that doesn't fit standard CRUD patterns, but agents can work around these limitations.
Average 2.4/5 across 12 of 12 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '更新JIRA问题' only indicates it's a mutation operation but reveals nothing about required permissions, whether updates are reversible, rate limits, error conditions, or what happens when partial updates are provided. For a mutation tool with 7 parameters and zero annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (three Chinese characters), this is under-specification rather than effective conciseness. The single phrase doesn't provide enough information to be useful, and there's no structure or front-loading of critical information. Every sentence should earn its place, but here there's essentially no content to evaluate for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, what fields can be updated, required permissions, or any behavioral characteristics. The description fails to compensate for the lack of structured information across all dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the tool description provides no information about any of the 7 parameters. The description doesn't mention that 'issue_key' is required or explain what any parameters represent, their formats, or how they interact. With 0% schema coverage and no parameter information in the description, this fails to provide basic parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新JIRA问题' (Update JIRA issue) is a tautology that restates the tool name in Chinese. While it indicates the verb ('update') and resource ('JIRA issue'), it doesn't specify what aspects can be updated or differentiate this from sibling tools like 'create_issue' or 'debug_issue_fields'. The purpose is vague beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for JIRA issue operations (create_issue, get_issue, search_issues, etc.), but the description offers no context about prerequisites, when this tool is appropriate, or when other tools should be used instead.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '调试' (debug) implies a read or diagnostic operation, but it doesn't specify whether it's safe (non-destructive), requires permissions, has side effects, or what the output entails. This leaves the agent guessing about critical behavioral traits.
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 a single phrase, which is concise but under-specified rather than efficiently informative. It's front-loaded but lacks necessary detail, making it more of a placeholder than a helpful summary. While not verbose, it doesn't earn its place with actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a debugging tool with no annotations, 1 undocumented parameter, and no output schema), the description is severely incomplete. It doesn't explain what debugging involves, what fields are examined, the output format, or how it differs from sibling tools like 'get_issue'. This leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. With 1 parameter (issue_key) and 0% schema description coverage, the schema only provides a title and type. The description doesn't explain what 'issue_key' is (e.g., a JIRA identifier like 'PROJ-123'), its format, or how it's used in debugging, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '调试JIRA问题字段' (Debug JIRA issue fields) states a general purpose but is vague. It doesn't specify what 'debug' entails (e.g., inspect, validate, troubleshoot) or what resource is affected beyond 'JIRA issue fields'. Compared to siblings like 'get_issue' or 'update_issue', it lacks differentiation in verb specificity or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for troubleshooting vs. regular operations), or exclusions. With siblings like 'get_issue' for retrieval and 'update_issue' for modification, there's no indication of when 'debug_issue_fields' is the appropriate choice.
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 full burden. '创建JIRA问题' implies a write operation but doesn't disclose behavioral traits like whether this requires authentication, what happens on success/failure, rate limits, or side effects. It mentions nothing about the creation process, validation rules, or what the tool returns. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase. While this is efficient, it's arguably under-specified rather than appropriately concise. Every word earns its place, but the description lacks necessary detail. It's front-loaded with the core action but doesn't provide needed context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema. The description is completely inadequate - it doesn't explain what the tool does beyond the name, provides no parameter guidance, no behavioral context, and no usage guidelines. For a complex creation tool, this leaves the agent guessing about everything from required fields to expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description provides no information about any of the 7 parameters. It doesn't explain what 'project_key', 'summary', or other fields mean, their formats, or constraints. The description adds zero value beyond what the bare schema provides, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建JIRA问题' (Create JIRA issue) states the basic action but is tautological with the tool name 'create_issue'. It doesn't specify what kind of issue is created or differentiate from siblings like 'update_issue' beyond the obvious verb difference. The purpose is clear but lacks specificity about the resource being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'create_issue' over 'update_issue' or 'search_issues', nor does it specify prerequisites like needing a valid project key or appropriate permissions. There's no context about appropriate use cases.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('获取' - get) without describing what '获取' entails—e.g., whether it's a read-only operation, requires authentication, has rate limits, returns structured data, or handles errors. This leaves the agent with insufficient information about how the tool behaves.
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—a single phrase in Chinese—and front-loaded with the core action. There's no wasted text, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 1 parameter), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, parameter details, or return values, leaving the agent unprepared to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. With 0% schema description coverage and 1 parameter ('project_key'), the schema only provides a title and type. The description doesn't explain what 'project_key' is (e.g., a JIRA identifier like 'PROJ-123'), its format, or examples. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取JIRA项目详情' (Get JIRA project details) states a clear verb ('获取' - get) and resource ('JIRA项目' - JIRA project), but it's vague about what '详情' (details) includes. It doesn't distinguish from sibling 'get_projects' (which likely lists multiple projects) or 'get_issue' (which gets issue details). The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to use it over 'get_projects' (for listing projects) or 'get_issue' (for issue details), nor does it specify prerequisites like needing a project key. The description alone offers no usage context.
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 mentions searching but doesn't describe key behaviors: whether this is a read-only operation, how results are returned (e.g., pagination via start_at and max_results), rate limits, authentication needs, or error handling. This is a significant gap for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese ('搜索JIRA问题列表'), which is appropriately concise and front-loaded. There's no wasted verbiage, though it could benefit from slightly more detail given the lack of annotations and schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a search tool with 3 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain the return format, error conditions, or how to interpret parameters like 'jql', leaving the agent with insufficient context to use the tool effectively beyond basic inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about parameters beyond what's implied by the tool name (e.g., it doesn't explain what 'jql' is, how 'max_results' works, or what 'start_at' means). With 3 parameters and no compensation in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '搜索JIRA问题列表' (Search JIRA issue list) states a clear verb ('搜索' - search) and resource ('JIRA问题列表' - JIRA issue list), providing basic purpose. However, it doesn't distinguish this tool from sibling tools like 'getIssues' or 'get_issue', making it somewhat vague about its specific scope compared to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getIssues' or 'get_issue'. It lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
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. The description only states what the tool does (get issue details) without mentioning any behavioral traits like whether it requires authentication, has rate limits, returns specific data formats, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase ('获取JIRA问题详情'), which is appropriately sized for a simple tool. It's front-loaded with the core purpose and has zero wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with one parameter), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter details, or return values, leaving gaps that could hinder an AI agent's ability to use the tool effectively. The description does the bare minimum but lacks necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond what the input schema provides. With 0% schema description coverage and one parameter (issue_key), the schema only documents the parameter's title and type. The description doesn't explain what an 'issue_key' is, its format (e.g., 'PROJ-123'), or examples. Since schema coverage is low (<50%), the description fails to compensate, leaving parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取JIRA问题详情' (Get JIRA issue details) clearly states the verb (get) and resource (JIRA issue details), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'getIssues' or 'search_issues', which also retrieve issue information. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this tool retrieves a single issue by key, while 'getIssues' might retrieve multiple issues or 'search_issues' might filter issues. There's no explicit when/when-not advice or named alternatives, leaving usage context implied at best.
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 full burden. It implies a read operation ('get'), but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what the output looks like (e.g., file content or metadata). For a tool with no annotation coverage, this is a significant 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, efficient sentence in Chinese ('获取JIRA问题附件'), which is appropriately sized and front-loaded. There's no wasted text, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 required parameters, no annotations, no output schema), the description is incomplete. It lacks details on usage context, parameter meanings, behavioral aspects, and output format, making it inadequate for an AI agent to reliably invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'JIRA issue attachment' but doesn't explain the parameters 'issue_key' and 'attachment_id' (e.g., format, examples, or how they relate). The description adds minimal meaning beyond the schema, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取JIRA问题附件' (Get JIRA issue attachment) states a clear verb ('get') and resource ('JIRA issue attachment'), but it's vague about scope and doesn't distinguish from sibling tools like 'get_issue_attachments' (plural) or 'get_attachment_by_filename'. It specifies what it does but lacks precision about what exactly is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_issue_attachments' (likely lists attachments) and 'get_attachment_by_filename' (retrieves by filename), the description doesn't indicate that this tool requires specific IDs or is for single attachments, leaving usage unclear.
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. It mentions retrieving issues and attachments but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, what format the output returns, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 with a single phrase, '获取JIRA问题及其附件', which is front-loaded and wastes no words. Every part of it directly contributes to stating the tool's purpose, making it efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (retrieving issues and attachments), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain return values, error handling, or how attachments are included, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't mention the 'issue_key' parameter at all, leaving it undocumented. The description implies retrieval but provides no context on what the parameter represents or how it should be used, failing to add meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取JIRA问题及其附件' (Get JIRA issues and their attachments) states a clear verb ('获取' - get) and resource ('JIRA问题及其附件' - JIRA issues and attachments), but it's vague about scope. It doesn't specify whether it retrieves a single issue or multiple issues, and it doesn't distinguish from siblings like 'get_issue' or 'search_issues' which likely have different functionalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_issue', 'get_issue_attachments', and 'search_issues', there's no indication of how this tool differs in usage context, prerequisites, or when it should be preferred over other options.
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. It states the tool downloads attachments to local storage, implying a write operation to the local system, but doesn't disclose behavioral traits such as file naming conventions, overwrite behavior, download location, network usage, or error handling. This leaves significant gaps for a tool that performs I/O operations.
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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a download operation (with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't address key aspects like what happens if there are no attachments, how files are saved, or what the tool returns (e.g., success status, file paths). For a tool that interacts with external systems and local storage, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the 'issue_key' parameter beyond what the schema title ('Issue Key') implies. It doesn't explain the format, examples, or constraints for the issue key, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('下载' meaning 'download') and resource ('JIRA问题的所有附件' meaning 'all attachments of a JIRA issue'), making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'get_attachment_by_filename' or 'get_issue_attachments', which appear to be read-only operations, but the download action implies a local storage outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_issue_attachments' (which might list attachments without downloading) or 'get_attachment_by_filename' (which might download a specific file). The description implies it's for bulk downloading all attachments, but doesn't specify prerequisites, error conditions, or exclusions.
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?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a read-only operation, what happens if the file doesn't exist, authentication needs, rate limits, or output format (e.g., file download vs. metadata).
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, efficient sentence in Chinese that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, with every word contributing to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects, parameter usage beyond basics, and output handling, making it inadequate for a tool that likely involves file operations.
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 0%, so the description must compensate. It mentions '问题ID' (issue ID) and '文件名' (filename), which map to the required parameters 'issue_key' and 'filename', adding meaning beyond the schema. However, it doesn't explain the optional 'save_to_disk' parameter or provide format details, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('JIRA附件' meaning 'JIRA attachment'), specifying it retrieves an attachment based on issue ID and filename. It distinguishes from siblings like 'get_issue_attachment' or 'download_all_attachments' by focusing on filename-based retrieval, though not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_issue_attachment' or 'download_all_attachments'. The description implies usage for retrieving a specific attachment by filename, but lacks explicit when/when-not instructions or prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: for example, whether it returns metadata or file content, if there are rate limits, authentication requirements, or pagination for large attachment sets. This is a significant gap for a tool with potential complexity in handling attachments.
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, efficient sentence in Chinese that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of handling attachments (which could involve metadata, file downloads, or pagination), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of attachment objects, file contents, or download links), leaving critical gaps for an agent to use it effectively.
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 description coverage is 0%, so the description must compensate, but it doesn't mention any parameters. It implies 'issue_key' is needed by referring to 'JIRA问题' (JIRA issue), but doesn't explain the 'download' parameter or its boolean nature. The baseline is 3 because the schema fully documents the parameters, though the description adds no value beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('JIRA问题的所有附件' meaning 'all attachments of a JIRA issue'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'get_attachment_by_filename' or 'download_all_attachments', which would require more specificity to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_attachment_by_filename' (for specific attachments) or 'download_all_attachments' (which may have different behavior). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.
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. The description only states what the tool does ('get JIRA project list') without revealing any behavioral traits such as whether it requires authentication, how it handles errors, if it's read-only or has side effects, or what format the output might be in. This leaves significant gaps for an AI 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('获取JIRA项目列表') that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks behavioral context (e.g., read-only vs. mutative, authentication needs) and doesn't explain the return values or format, which is crucial since there's no output schema. For a tool interacting with a system like JIRA, more completeness is needed to guide proper usage.
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 tool has 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation for a parameterless tool. No additional value is required beyond stating the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取JIRA项目列表' clearly states the action ('获取' meaning 'get/fetch') and resource ('JIRA项目列表' meaning 'JIRA project list'), providing a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'get_project' (singular), which might retrieve a single project, leaving some ambiguity about sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_projects' (plural) instead of 'get_project' (singular) or other sibling tools like 'search_issues', nor does it specify any prerequisites or context for usage.
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-jira MCP server](https://glama.ai/mcp/servers/yuezheng2006/mcp-server-jira/badges/card.svg)](https://glama.ai/mcp/servers/yuezheng2006/mcp-server-jira)

Score Badge

Copy to your README.md:

[![mcp-server-jira MCP server](https://glama.ai/mcp/servers/yuezheng2006/mcp-server-jira/badges/score.svg)](https://glama.ai/mcp/servers/yuezheng2006/mcp-server-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/yuezheng2006/mcp-server-jira'

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