Jira MCP Server

Server Quality Checklist

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

Latest release: v2.4.2
Disambiguation5/5
Each tool targets a distinct Jira resource (issue, project, board, sprint, etc.) with no functional overlap. Tool names clearly indicate the resource they operate on.
Naming Consistency5/5
All tools follow the consistent pattern 'jira_<resource_noun>', making it easy to predict tool names. No mixing of conventions.
Tool Count5/5
16 tools cover the major Jira entities comprehensively without being excessive. The scope matches typical Jira usage well.
Completeness5/5
The tool set covers CRUD operations for core entities (issues, projects, boards, sprints), plus search, user management, and metadata. No obvious gaps for standard workflows.
Average 3.9/5 across 16 of 16 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on June 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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?
No annotations are provided, so the description must disclose behavior. It describes read-like operations but does not explicitly state that the tool is read-only or mention any side effects, permissions, or rate limits.
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 relatively short but includes a list of actions. It could be more structured (e.g., separating actions) but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and low schema coverage, the description is insufficient for an agent to understand parameter relationships, required vs optional fields per action, or return value expectations.
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?
With schema description coverage at 21%, the description should compensate for missing parameter details. However, it only lists operations without explaining parameter usage or providing context beyond what is 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 that the tool looks up Jira users, listing several specific operations (myself, search, get, assignable, bulkGet). It distinguishes from sibling tools by focusing on user-related actions.
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 lists operations but provides no guidance on when to use this tool versus alternatives or how to choose among the actions. No exclusions or context for selection are given.
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 full responsibility. It explains that 'full: true' works on read actions but is rejected by mutations, which adds useful behavioral context. However, it lacks details on side effects, permissions, or error handling for mutations.
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 main description is a single concise sentence that captures the tool's scope. The schema description is longer but well-organized with actions and parameters, and the critical 'full' parameter behavior is clearly noted. A minor deduction for the main description being slightly generic.
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's complexity (14 parameters, 8 actions) and lack of output schema, the description covers essential information: actions, required parameters, and the 'full' flag behavior. It could improve by describing response formats or pagination, but overall it is reasonably 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?
The schema description (within the input schema) provides action-specific parameter requirements and optional fields, adding meaning beyond the raw schema. However, with only 7% schema description coverage, many parameters remain undocumented. The main description offers no parameter details, 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 clearly states it manages Agile boards and lists specific actions (list/get/create/delete, configuration, issues, backlog, epics). This distinguishes it from sibling tools like jira_issue or jira_sprint, which handle different resources.
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 enumerates actions but provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites or scenarios where other tools would be more appropriate, leaving the agent to infer usage from the action list alone.
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 provided, so description must disclose behavior. It explains the summary projection and full parameter behavior but omits side effects, auth requirements, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary followed by action list. However, the summary sentence is duplicated in both the description and schema description. Otherwise concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 9 actions and parameter requirements. Lacks details on output format beyond summary references. With 15 parameters and no output schema, completeness is moderate but adequate for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%), but description ties parameters to specific actions (e.g., 'get: requires issueIdOrKey; optional fields, expand'). Some parameter info is repeated from schema. Compensates partially but not fully for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: managing Jira issues with 9 distinct actions. It distinguishes from sibling tools like jira_comment, jira_attachment, etc., which handle sub-resources.
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?
Description lists actions and their required parameters but does not explicitly guide when to use this tool vs. alternatives like jira_search. Usage context is implied by the actions, not stated.
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?
The description discloses that mutation actions reject 'full: true' and read actions can return raw responses, which is a behavioral detail. However, no annotations are provided, and the description does not cover other behavioral traits like authentication requirements, rate limits, or side effects (e.g., deletion cascades).
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 structured into a clear list of actions with parameter requirements, making it easy to scan. It front-loads the overall purpose. However, there is slight redundancy: the opening sentence repeats the scope covered later in the action list. Overall, it is efficient and well-organized.
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's complexity (25 parameters, 11 actions) and no output schema, the description is fairly complete. It explains each action's required and optional parameters, the 'full' parameter behavior, and mutation vs read actions. Some edge cases or return value details could enhance completeness, but it adequately covers core 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?
With schema description coverage at 16%, the description significantly compensates by explaining which parameters are required for each action. For instance, it states that 'listComponents' requires 'projectIdOrKey', while 'createComponent' requires 'project' and 'name'. This adds crucial meaning beyond the bare schema, though some parameters like 'query' remain unexplained.
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 tool manages Jira projects, components, versions, and statuses. It lists specific actions, making the purpose explicit. However, it does not distinguish itself from sibling tools like jira_board or jira_epic, which could lead to confusion about when to use this tool instead.
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 provides context for each action (list, get, create, etc.) and their required/optional parameters, implying when to use them. Yet it lacks explicit guidance on when not to use this tool or comparisons with alternatives. For example, it does not explain when to use jira_project vs jira_issue for project-related tasks.
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?
Despite no annotations, the description reveals important behavioral traits: results come back as a 'trimmed list with refs', and there is a 'full' parameter to bypass the summary projection. It also states that mutation actions reject full:true. This provides behavioral clarity beyond the schema.
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 main description is concise (two sentences) and front-loaded. The schema description adds necessary details without excessive verbosity. A slightly more structured presentation could improve clarity, but it is efficient overall.
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 10 parameters and low schema coverage (30%), the description explains the action logic and the full parameter but fails to cover many pagination and field selection parameters. There is no output schema, and the return value is only described as a 'trimmed list with refs', which is adequate but not exhaustive.
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 adds meaning to the action enum and the full parameter, explaining their roles. However, with only 30% schema description coverage, many parameters (expand, startAt, maxResults, nextPageToken) are not explained in the description, leaving gaps. The description partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's two main purposes: searching Jira issues with JQL and fetching JQL autocomplete metadata. This distinguishes it from sibling tools like jira_issue, which handles individual issues, and other search-related siblings.
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 does not provide guidance on when to use this tool versus alternatives. It does not mention that for specific issue operations, one should use jira_issue, or under what circumstances to use search versus other tools. No exclusions or context are provided.
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 full burden. It explains that `full: true` is accepted only on read actions and rejected on mutations, which is helpful. However, it does not disclose potential side effects (e.g., deletion consequences), authorization requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and organized into a clear action list. It is somewhat long but every sentence adds value. Minor deduction for slight redundancy with schema.
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 20 parameters, multiple actions, and no output schema, the description covers all actions and key parameters adequately. It could mention error handling or idempotency, but overall it is comprehensive.
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?
With only 5% schema description coverage, the description compensates by detailing parameter usage per action. However, it does not fully clarify every parameter (e.g., `rankBeforeIssue`, `rankAfterIssue` lack detailed semantics). The baseline of 3 is appropriate given the partial compensation.
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 explicitly states 'Manage Jira sprints: list/get/create/update/delete, list sprint issues, and move issues in or out.' This clearly defines the tool's purpose and differentiates it from sibling tools like jira_issue or jira_board.
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 provides action-specific parameter requirements, but does not offer comparative guidance on when to use this tool instead of related tools like jira_issue or jira_board. The action list implies scope, but lacks explicit when-to/not-to-use instructions.
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?
Without annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'Inspect', but does not explicitly state it is safe, non-destructive, or mention any rate limits or authentication requirements. For a simple info tool, the basic transparency is adequate but minimal.
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 top-level description is extremely concise (one sentence, 8 words) with no filler. The additional parameter details are placed logically in the schema description. Every part serves a purpose.
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 server info tool with only two parameters and no output schema, the description sufficiently explains the tool's purpose and parameter behavior. It could mention that the tool is safe to call repeatedly, but this is not a major gap.
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 schema description coverage is 50% (only 'full' has an individual description), but the description text inside the input schema adds meaning to both parameters: it explains the 'action' enum and the effect of 'full: true'. This compensates well for the missing per-parameter description on 'action'.
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 'Inspect' and identifies the resource as 'Jira server' with details on version, build, deployment type. It clearly distinguishes itself from sibling tools like jira_issue, jira_project, etc.
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 other jira_* tools. There are no hints about prerequisites or alternatives.
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, the description carries full burden. It discloses that 'full: true' is only for read actions and mutation responses are minimal, but lacks details on side effects of delete, rate limits, or authorization 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 well-structured with a purpose statement, action list, and a note on 'full' parameter. Every sentence provides value; no redundancy.
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?
The description adequately covers actions and parameters but does not describe return values or pagination details for list actions, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite only 11% schema coverage, the textual breakdown of each action explicitly maps required/optional parameters (e.g., 'create: requires name, jql; optional description, favourite, sharePermissions'), adding significant meaning beyond the bare 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 'Manage saved JQL filters: list/get/create/update/delete plus the current user's favourites,' which precisely defines the tool's scope and distinguishes it from sibling tools like jira_issue or jira_search.
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 provides detailed action-specific parameter requirements (e.g., 'list: optional filterName, accountId...'), but does not explicitly guide when to use this tool versus alternatives like jira_search or jira_issue for filtering operations.
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 exist, so the description carries full burden. It discloses support for remaining-estimate adjustment and explains the behavior of the 'full' parameter, including that mutation actions reject it. However, it lacks details on permissions, side effects, or error conditions.
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 structured by action and provides useful breakdowns, but it is somewhat verbose (e.g., repeating the first sentence in the schema description field). It could be more concise while retaining key 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?
Given 18 parameters, 4 actions, and no output schema, the description covers action-specific required params, estimate adjustment, and 'full' behavior. However, it does not describe the response format (e.g., returned worklog structure) or pagination details, leaving some gaps.
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?
With only 11% schema coverage, the description compensates by grouping parameters per action, listing required vs optional params, and explaining the 'full' parameter. It adds meaning beyond the schema but does not document every parameter individually.
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 can list, add, update, and delete worklogs on an issue, effectively identifying the verb+resource and distinguishing it from sibling Jira tools that handle other entities.
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 does not explicitly state when to use this tool over alternatives, but the sibling tools cover distinct resources, so context implies usage. No when-not-to-use or comparative guidance is provided.
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 full burden. It discloses that read actions have a summary projection and can be overridden with 'full: true', while mutation actions reject that parameter. This provides useful behavioral context beyond the bare minimum.
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 concise and front-loads the main purpose, but it packs many details into a single paragraph. Breaking it into sections could improve readability, but overall it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description provides action-specific details but does not explain all parameters (e.g., jql, fields, expand, startAt, maxResults are only listed without description). The return value is partially explained (summary projection vs raw response), but more completeness would be beneficial.
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?
The schema description coverage is only 11%, but the description compensates by explaining each action and its required parameters (e.g., 'get' requires epicIdOrKey, 'issues' requires epicIdOrKey with optional parameters, etc.). It also clarifies the 'full' parameter's behavior in detail, adding meaning 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 explicitly states the verbs: 'Inspect', 'list', and 'move', with the resource 'epics'. It clearly differentiates from sibling tools like jira_issue or jira_board by focusing on epic-specific operations.
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 usage by listing actions and required parameters, but it does not provide explicit guidance on when to use this tool versus alternative tools (e.g., when to use jira_issue for non-epic operations). The context is clear but lacks exclusions or comparisons.
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 provided, so description carries full burden. It discloses behavior of the full parameter and that mutation actions reject it. Lacks details on authentication, rate limits, or error handling, but is adequate for a read-only metadata tool.
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 a clear intro and bullet points for actions. It could be slightly more concise by removing redundant phrasing, but it is front-loaded and easy to scan.
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 7 parameters (1 required) and no output schema, the description covers purpose, actions, and the full parameter. It does not explain return data structure or error cases, but is reasonably complete for a metadata listing 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?
Schema coverage is only 14%. The description adds meaning for the action parameter (lists enum values and their purpose) and the full parameter. Other parameters (projectIds, etc.) are only mentioned briefly under createMeta, leaving most undocumented.
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 lists Jira metadata (fields, issue types, etc.), which is a specific verb-resource combination. It distinguishes itself from sibling tools like jira_issue or jira_project by focusing on configuration metadata rather than entities.
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 explains when to use the full parameter and that mutation actions reject full: true. However, it does not explicitly state when to avoid this tool in favor of siblings, e.g., for retrieving actual issues use jira_search.
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 `full: true` bypasses summary projection for read actions and that mutation actions reject it. It also mentions that the default summary may drop content. It lacks details on authentication, rate limits, or side effects, but the disclosures are helpful.
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 moderately sized but well-structured, starting with a clear purpose then detailing actions. Every sentence adds value, but some explanations (e.g., the full flag) could be more concise. Overall, it is front-loaded and organized.
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 14 parameters, multiple actions, and no output schema, the description is fairly complete. It explains each action's parameters and the `full` flag behavior. It does not detail return values extensively, but mentions 'raw Jira API response' as a hint. Coverage of edge cases or errors is minimal, but acceptable.
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 only 21%, but the description adds significant meaning by explaining which parameters apply to each action (e.g., 'members' requires groupId) and the role of `full`. This compensates for the low schema coverage and provides context beyond the raw 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 three distinct actions: search groups, list group members, and inspect permissions. The tool name 'jira_group' aligns with these group-related operations, and it distinguishes from sibling tools that focus on other entities like attachments, boards, or issues.
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 lists actions (search, members, myPermissions) and their required parameters. It explains when to use each action and notes that mutation actions reject `full: true`. However, it does not explicitly state when NOT to use this tool or compare it to alternatives for creating or modifying groups.
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?
Given the absence of annotations, the description fully discloses key behavioral traits: it explains the `full` parameter effect for read vs mutation actions, and the minimal responses for mutations. It does not cover permissions or idempotency, but for a CRUD tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (around 150 words) and well-structured: a single-sentence summary followed by a bulleted action list. Every sentence serves a clear purpose, avoiding 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?
Despite lacking an output schema, the description covers return behavior (default projection vs raw response for reads, minimal for writes). All actions and parameter requirements are explained, making the tool fully understandable.
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?
With only 57% schema description coverage, the description compensates by mapping actions to required parameters (e.g., create requires type, inwardIssue, outwardIssue; optional comment). This adds meaning beyond the schema, though some parameters like comment and linkId remain lightly described.
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 explicitly states 'Create, fetch, delete issue links, and list available link types.' This clearly identifies the resource (issue links) and the supported actions, distinguishing it from sibling tools like jira_issue or jira_attachment which handle other aspects.
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 details each action and their required parameters, providing clear context on how to use the tool. However, it does not explicitly mention when not to use it or suggest alternatives, leaving a minor gap in 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 provided, so the description carries full weight. It explains that mutation actions reject 'full: true' and that their responses are minimal, and that read actions with 'full: true' bypass the default summary. Missing details on authorization requirements or side effects, but the disclosed behavioral traits are valuable.
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 concise and well-structured: a summary sentence, a bullet list of actions with clear requirements, and a paragraph explaining the 'full' flag. Every sentence adds value without 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 no output schema and no annotations, the description covers the tool's functionality thoroughly, including parameter dependencies and special behavior. However, it does not describe the output format or potential error responses, leaving some gaps for a complete understanding.
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 description coverage is only 25% (only 'full' has a schema description). The tool description compensates fully by explaining the enum values for 'action', which parameters are required per action, and the effect of 'full'. This adds significant meaning beyond the bare 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 it lists, adds, and removes watchers, as well as lists and toggles votes on an issue. The verb-resource combination is specific and distinguishes from sibling tools that focus on other aspects like issue CRUD or comments.
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 detailed guidance on when to use each action, required parameters, and the behavior of the 'full' flag. It does not explicitly state when not to use this tool versus alternatives, but the sibling tools are sufficiently distinct that the context is 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?
No annotations are provided, so the description carries the full burden. It explains the body format (ADF documents), the behavior of the 'full' parameter, and that mutations return minimal responses. It could be more explicit about error conditions or authorization, but overall it gives solid behavioral context.
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 relatively long but well-structured: a concise opening sentence followed by a clear breakdown of actions and the 'full' parameter. It is front-loaded with the main purpose. Slight verbosity could be trimmed, but it remains effective.
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 complexity (10 parameters, nested objects, enum action), the description covers the main use cases and parameter requirements. It lacks details on return values (no output schema), but mentions mutation responses are minimal. Adequate for most usage scenarios.
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?
With only 10% schema description coverage, the description adds substantial meaning to parameters. It explains each parameter's role per action, the enum values for 'action', and the 'full' parameter's effect. This far exceeds the minimal schema info.
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 handles CRUD operations for comments on a Jira issue with specific verbs: list, add, update, delete. It distinguishes itself from sibling tools like jira_attachment or jira_issue.
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 provides explicit guidance for each action, listing required and optional parameters. It also explains when to use the 'full' parameter and that mutation actions reject it. This helps the agent choose the correct action and parameters.
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?
With no annotations, the description fully informs behavior: it explains that 'add' uploads local files by path (server reads bytes), warns against passing contents, and clarifies that 'full: true' is only for read actions and rejected by mutation actions. It also mentions the streaming downloader alternative.
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 concise and front-loaded, but the input schema repeats the same text in the 'description' field, leading to redundancy. Otherwise, it is well-organized with clear action breakdown.
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?
Given no output schema, the description adequately covers all actions, parameters, and behavioral nuances. It addresses reading vs mutation, file handling, and the streaming alternative, making it complete for an agent to use correctly.
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?
Despite 60% schema coverage, the description adds crucial meaning: it explains each action's required parameters, the purpose of 'attachmentId' for get/delete, and the behavior of 'full'. It clarifies that 'filePath' should be a local path, not contents, which the schema's description does not fully capture.
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 'Add, inspect, or delete attachments,' with explicit verb+resource. It distinguishes actions via the 'action' enum and contrasts with the streaming downloader for downloading bytes, differentiating from sibling tools like jira_issue.
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 specifies when to use each action (add, get, delete, meta) and prerequisites like required parameters. It also notes that to download bytes one should use the streaming downloader. However, it lacks explicit guidance on when not to use this tool in favor of others, though the action enum provides context.
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:

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

Score Badge

Copy to your README.md:

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

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