jira-api-mcp-wrapper

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action on Jira resources. Single and bulk operations are clearly separated, and user-related tools (search_users vs resolve_user_account_id) have distinct purposes. No two tools appear to do the same thing.
Naming Consistency5/5
All tools follow a consistent 'jira_verb_noun' pattern using snake_case. Verbs are uniform (add, bulk_create, bulk_edit, create, get, list, resolve, search, transition, update), and bulk operations are prefixed with 'bulk_'. The naming is predictable and easy to understand.
Tool Count5/5
With 13 tools, the server covers core Jira issue operations without being overwhelming. The number is well within the ideal range (3-15) and each tool addresses a specific need, from CRUD to searching and user resolution.
Completeness4/5
The tool surface covers creation (single and bulk), reading, updating, commenting, searching, and transitions. Missing delete functionality is a notable gap, but the set is sufficient for most issue management workflows. Overall, it is well-scoped for its stated purpose.
Average 3.6/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description discloses API endpoint and support for ADF docs but no behavioral traits like rate limits, auth requirements, or side effects. Minimal transparency.
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?
Single sentence, front-loaded with action and endpoint. Concise but could be structured with separate sentences for required vs optional info.
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?
Missing output schema, no explanation of return values (e.g., issue key/ID). Does not elaborate on validateAdf or error handling. Adequate but incomplete for a complex creation tool.
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?
Adds meaning beyond schema by specifying required fields (project, issuetype) and custom field support, including ADF format. Schema already describes both parameters but this clarifies usage.
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?
Clearly states action (create) and resource (Jira issue). Mentions required fields (project, issuetype) and optional custom fields/ADF. However, does not distinguish from bulk creation or update 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?
No guidance on when to use vs alternatives like bulk_create or update. No prerequisites or context provided. Only mentions which fields to supply.
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 must cover behavioral traits. It mentions the endpoint and that it returns field IDs, but it does not disclose whether the operation is read-only, required permissions, rate limits, error handling, or any side effects. The description is too minimal for a tool with no annotation support.
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 exceptionally concise: two sentences with no wasted words. It front-loads the action and resource, and then provides a clear link to the next step. Every sentence serves a 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 complexity (4 parameters, no output schema, no annotations), the description is lacking. It does not explain the return structure, specify that it is a read-only operation, or provide enough context for an agent to decide when to use this tool confidently over alternatives. The description is functional but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond what the schema provides (e.g., explaining searchText or pagination cursors). It only implicitly references the required parameter 'issueIdsOrKeys' via context.
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 ('Get') and the resource ('bulk-editable field IDs for a set of issues'). It also references the HTTP endpoint and mentions the complementary tool (jira_bulk_edit_issues), which helps contextualize the purpose. However, it does not explicitly differentiate from siblings like jira_update_issue_fields or jira_list_fields.
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 indicates that this tool should be used to obtain field IDs for bulk editing, and its output is intended for jira_bulk_edit_issues. However, it does not provide explicit when-not-to-use guidance or mention alternatives (e.g., for single issue editing). The usage context is implied but not fully elaborated.
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 should disclose behavioral traits. It only mentions the API endpoint without clarifying permissions, error handling, or side effects (though it's read-only).
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 sentence that is concise and front-loaded, but it could benefit from a bit more structure, such as listing the return type.
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 simple read tool with full schema coverage and no output schema, the description is minimally adequate but lacks information about the output structure (e.g., array of transitions with statuses).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it repeats the API path but does not elaborate on parameter syntax or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'available transitions for an issue', which is specific and distinguishes it from siblings like 'jira_transition_issue' that performs transitions.
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?
No guidance on when to use this tool versus alternatives like 'jira_get_issue' or 'jira_transition_issue'. The description is minimal and implies usage only by naming the endpoint.
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, and the description does not disclose behavioral traits such as read-only nature, potential size of output, or rate limits. For a listing tool, stating it is non-destructive would be helpful.
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?
Two sentences with no fluff. The first sentence states the core functionality and API endpoint; the second provides a concrete use case. Every part earns its place.
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 it's a simple list tool with good schema coverage and no output schema, the description is mostly complete. It covers purpose, resource, and use case. It could mention that the output contains all fields (limited by filter) and that it's read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters well (case-insensitive filter, optional schema metadata). The description adds overarching context ('including customfield_*') but does not enhance meaning of individual parameters beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
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 ('List') and the resource ('Jira fields including customfield_* from /rest/api/3/field'). It provides a specific use case ('map friendly names to field IDs'). While it doesn't explicitly differentiate from siblings, the sibling tools are mostly issue/comment operations, so it's reasonably distinct.
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 gives a concrete use case ('use this to map friendly names to field IDs'), which guides the agent. However, it does not mention when not to use it (e.g., if you need field details by project) or provide alternatives.
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, description only mentions body formats and API endpoint. It fails to disclose return value, error cases, permissions, or idempotency. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Efficiently conveys core purpose and key detail about body format.
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?
Adequately covers basic operation and parameter formats but lacks usage guidance and behavioral details. For a simple tool, it's minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents parameters. Description adds marginal value by restating body options but no new insights beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'add', resource 'comment to an issue', includes API endpoint, and distinguishes from sibling tools like jira_create_issue or jira_update_issue_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives. The description implies usage for adding comments but lacks context on when not to use or comparisons with siblings.
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. Description mentions HTTP POST (mutating) and bulk creation, but omits details on error handling, partial failures, rate limits, or required authentication. The schema includes a max limit of 50, but this is not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the action. It is efficient but could benefit from additional context without being 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 the complexity of bulk creation (nested objects, up to 50 issues), the description is too minimal. It fails to explain required fields, error behavior, or return values. The input schema provides some detail, but the description adds little context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description restates the input structure ('issueUpdates entries containing fields and optional update') without adding new meaning or explaining object formats like valid fields or ADF validation.
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: 'Bulk create issues via POST /rest/api/3/issue/bulk'. The verb 'create' and resource 'issues' are specific, and the sibling tool 'jira_create_issue' for single creation makes the bulk nature distinctive.
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 for bulk creation but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, e.g., using 'jira_create_issue' for single issues or 'jira_bulk_edit_issues' for editing.
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, and the description only states 'bulk edit' without disclosing side effects, limits (though schema shows max 1000 items), or whether the operation is destructive. It fails to warn about notification behavior or validation, which are exposed in schema but not highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and endpoint, and includes the most critical required parameters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the tool's complexity (5 params, nested objects, no output schema). It does not explain return values, error conditions, or how the bulk operation behaves (e.g., partial success). With no annotations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by recommending jira_bulk_get_editable_fields to discover field IDs, which is not in the schema. This extra guidance improves parameter understanding.
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 action ('bulk edit issues'), the HTTP method and endpoint, and explicitly lists the three required parameters. It distinguishes from siblings like jira_bulk_create_issues and jira_update_issue_fields by indicating this is a bulk operation.
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 mentions required inputs but does not provide explicit guidance on when to use this tool versus single-issue editing or other bulk operations. It implies usage by stating 'bulk edit', but lacks direct comparison or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral disclosure. It mentions the endpoint path and that it returns a page with selected fields, but lacks details on error handling, authentication needs, or rate limits. Basic transparency but incomplete.
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?
Two sentences, front-loaded with action and endpoint, no fluff. Every sentence adds value. Excellent conciseness.
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 complexity (5 parameters, no output schema), the description is minimal. It explains return type (page of issues with selected fields) but not pagination details or error scenarios. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description adds no additional meaning beyond what the schema already provides for parameters. It briefly mentions 'selected fields' which relates to the fields parameter, but no deeper explanation.
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 action 'search', resource 'issues', and method 'using JQL'. It distinguishes from sibling tools like jira_get_issue by specifying JQL-based search and returning a page of issues.
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 implies usage for searching issues with JQL but does not explicitly differentiate from alternatives like jira_get_issue or provide when-not-to-use guidance. Given the clear purpose, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions using the /rest/api/3/user/search API and selecting the best candidate, which gives some insight but lacks details on matching logic, error handling, or rate limits. Adequate but not comprehensive.
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 sentence of 24 words, front-loading the key action ('Resolve a single best-match Jira user and return accountId') and providing only essential information without 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?
While the description covers the main purpose and key parameters, it lacks output schema and does not explain failure behavior (e.g., no match found) or return format beyond 'accountId.' For a simple resolver, this is somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the schema. The description does not add additional meaning beyond the schema; it merely restates the purpose. Thus, score at baseline 3.
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 resolves a single best-match Jira user and returns an accountId, specifically for setting user picker custom fields. It mentions the API endpoint used and that it selects the best candidate, which differentiates it from sibling tools like jira_search_users that return multiple users.
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 context on when to use the tool ('for setting user picker custom fields') and implies it's for a single best match, contrasting with search tools. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning whether the transition is destructive, what side effects occur, or any required permissions. This is insufficient for safe usage.
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 two sentences, front-loading the core action and prerequisite. No 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?
While the core purpose is clear and the schema covers parameters, the description lacks information about return values, error handling, or state changes. For a mutation tool without output schema, this is a notable gap, but the essential context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds minimal value by mentioning the transition ID requirement, but does not elaborate on the 'fields' or 'update' objects. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'transition' and identifies the resource 'issue'. It explicitly mentions the API endpoint and provides a direct link to the sibling tool jira_get_transitions, clearly distinguishing this tool's purpose.
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 clearly states when to use this tool: to transition an issue. It provides explicit guidance to use jira_get_transitions first to obtain the transition ID, which is essential for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It confirms the tool mutates data ('Update') and mentions requirements for field IDs and value shapes, but lacks details on idempotency, validation, error handling, permissions, or response behavior. The caution about user picker requiring accountId adds some 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 three concise sentences. The first states the core action, the second lists supported features, and the third gives critical usage advice. No unnecessary words or repetition.
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 tool's complexity (7 parameters, nested objects, no output schema), the description is somewhat incomplete. It does not explain return values or whether the tool returns the updated issue, nor does it mention prerequisites like issue existence or authorization needs. It covers the main action but lacks broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enhances parameter semantics by providing a concrete example ('user picker needs accountId') and warning about correct field IDs and ADF docs. This adds value beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'Jira issue fields'. It mentions the specific API endpoint and supported field types (customfield_*, ADF docs), which distinguishes it from siblings like jira_create_issue or jira_get_issue. However, it does not contrast with jira_bulk_edit_issues, but the singular focus is clear.
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 for updating single issue fields but does not explicitly state when to use this tool versus alternatives like jira_bulk_edit_issues. It provides cautionary guidance about correct field IDs and value shapes, but no explicit when-to-use/when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the API endpoint and that it returns accountId, but does not disclose other behaviors like query matching behavior, pagination, rate limits, or authentication requirements. The schema covers parameters, so the description adds minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. It front-loads the purpose and use case, and every sentence earns its place.
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 simplicity of the tool (3 parameters, no output schema, no nested objects), the description is adequate but could be improved by mentioning the output format (e.g., list of users with accountId and displayName). It does cover the key return value (accountId) and the use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description does not add any additional meaning beyond what is already in the schema for the parameters. It does not elaborate on the query format beyond what is in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches users and returns accountId, and provides a specific use case (mapping email/displayName to accountId for user picker fields). It implicitly distinguishes from sibling 'jira_resolve_user_account_id' which likely operates on a known accountId.
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 says 'Use this to map email/displayName → accountId for user picker fields', providing a clear when-to-use scenario. It does not explicitly mention when not to use, but the context of siblings and the specific use case give enough 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, but description discloses it's a read-only fetch with optional payload reduction via fields/expand. No contradictions. Could mention return format but adequate for a get operation.
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?
Two sentences, front-loaded with key action and endpoint, no wasted words.
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?
Simple tool, description covers essential: fetch by key, optional field selection. Lacks mention of default return behavior but not critical for a get operation. No output schema, but not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining purpose of fields/expand parameters ('to reduce payload'), which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a Jira issue by key', specifying the exact endpoint and verb. It distinguishes from sibling 'jira_search_issues_jql' which searches rather than fetches by key.
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?
Usage is implied: use when you have an issue key. But no explicit guidance on when not to use (e.g., searching) or comparison to alternatives like jira_search_issues_jql.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/jarekbird/jira-api-mcp-wrapper'

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