Jira MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Jira operations like create, edit, delete, assign, query, and list. However, 'execute_jql' and 'get_only_ticket_name_and_description' both query tickets via JQL, creating some overlap that could cause confusion, though their descriptions clarify different output focuses.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case throughout, such as 'create_ticket', 'assign_ticket', and 'list_projects'. This predictability makes it easy for agents to understand and navigate the tool set without naming conflicts.
Tool Count5/5
With 11 tools, the count is well-scoped for a Jira server, covering core operations like ticket management, attachments, queries, and project listing. Each tool appears to serve a specific function without unnecessary bloat, fitting typical server tool ranges.
Completeness4/5
The tool set provides good coverage for Jira workflows, including CRUD operations for tickets, assignment, attachments, and project/status queries. Minor gaps exist, such as missing tools for comments, transitions, or watchers, but core functionalities are present and agents can likely work around these omissions.
Average 2.8/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the API endpoint and a markdown restriction, but fails to disclose critical behavioral traits: whether this is a read-only operation, what permissions are needed, how errors are handled, or if there are rate limits. The markdown note is vague and doesn't clarify if it's a requirement or a warning.
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 brief but not optimally structured. The first sentence states the purpose, but the second sentence about markdown is confusing and doesn't add clear value. It could be more front-loaded with essential information, though it avoids excessive verbosity.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., format of name and description, error responses) or behavioral constraints. For a query tool with two parameters, this leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents both parameters (jql query string and number_of_results with default). The description adds no meaningful parameter semantics beyond what's in the schema—it doesn't explain JQL syntax, valid result ranges, or how parameters interact. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves ticket name and description using a specific API endpoint, which provides a basic purpose. However, it doesn't clearly differentiate from sibling tools like 'execute_jql' (which likely performs similar JQL queries) or specify what makes this tool unique (e.g., limited fields returned vs. full ticket data). The mention of 'Do not use markdown in your query' is confusing and doesn't clarify the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'execute_jql' or explain why one would choose this tool over others for querying tickets. The only usage hint is the confusing markdown restriction, which doesn't help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action and API endpoint. It doesn't disclose behavioral traits such as required permissions, rate limits, file size restrictions, supported URL types, or what happens on success/failure. The mention of 'Do not use markdown in your query' adds minor context but is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but could be more front-loaded; the first sentence is clear, but the second about markdown feels tacked on and not core to the tool's purpose. It's reasonably sized but not optimally structured, with some wasted space on non-essential details.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on permissions, error handling, return values, or constraints like URL accessibility. The API endpoint detail is useful but doesn't compensate for missing behavioral context needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('issueIdOrKey' and 'imageUrl'). The description adds no additional meaning beyond implying 'imageUrl' must be a public URL, which is somewhat redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add' and resource 'attachment from a public url to a ticket on Jira', specifying the exact API endpoint. It distinguishes from sibling 'add_attachment_from_confluence' by specifying 'public url' vs 'confluence', though not explicitly named. However, it lacks full sibling differentiation beyond the URL source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_attachment_from_confluence' or other attachment methods. It only includes a technical note about not using markdown in queries, which is not usage guidance. No context, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the API endpoint but doesn't disclose behavioral traits like whether this is a mutation (implied by 'assign'), authentication requirements, error handling, or what happens on success/failure. The note about markdown is irrelevant to behavior.
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?
It's concise but poorly structured. The first sentence states the purpose, but the second sentence about markdown is irrelevant and distracting. Front-loading is adequate, but the extra sentence doesn't earn its place, reducing effectiveness.
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 no annotations and no output schema, the description is incomplete for a mutation tool. It lacks context on permissions, side effects, response format, or error cases. Sibling tools suggest a Jira context, but this isn't leveraged to explain integration points.
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 parameters are fully documented in the schema. The description adds no meaning beyond what the schema provides (e.g., no context on how to obtain accountId or issueIdOrKey). Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Assign a ticket') and the target system ('on Jira'), with a specific API endpoint mentioned. It distinguishes from siblings like 'create_ticket' or 'edit_ticket' by focusing on assignment, but doesn't explicitly differentiate from 'query_assignable' which is related to assignee lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid ticket and assignee), exclusions, or how it relates to siblings like 'query_assignable' (which might help find assignable users). The API endpoint detail is technical but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool deletes a ticket but fails to disclose critical behavioral traits such as whether deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or involves rate limits. The mention of 'Do not use markdown in your query' is irrelevant to behavioral transparency.
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 brief but includes an irrelevant sentence about markdown that does not contribute to understanding the tool. It is front-loaded with the core purpose, but the second sentence wastes space. Overall, it could be more concise by removing the extraneous instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deletion operation, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permanence, permissions), error handling, or what happens post-deletion. For a destructive tool, this leaves significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'issueIdOrKey' parameter. The description does not add any meaning beyond the schema, such as examples or format details (e.g., key format like 'PROJ-123'). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 ('Delete') and resource ('a ticket on Jira'), specifying the API endpoint. However, it does not distinguish this tool from sibling tools like 'edit_ticket' or 'create_ticket' beyond the verb, nor does it clarify if deletion is permanent or reversible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'edit_ticket' for modifications or 'execute_jql' for querying). It includes an unrelated instruction about markdown, which does not aid in tool selection. No explicit when/when-not scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but offers minimal behavioral insight. It mentions the API endpoint but doesn't disclose critical traits like authentication needs, rate limits, pagination, or what 'status' entails (e.g., issue statuses, system statuses). The markdown warning is tangential and not a core behavioral trait.
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 brief but includes an unnecessary sentence ('Do not use markdown in your query') that doesn't add value for tool understanding. It could be more front-loaded by focusing solely on the tool's purpose and usage context.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on what 'status' means in Jira context, how results are returned, error handling, or prerequisites. For a tool interacting with an external API, more contextual information is needed.
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 the schema fully documents the 'number_of_results' parameter. The description adds no parameter-specific information beyond implying retrieval of 'all' statuses, which might conflict with the parameter's default of 1. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all the status on Jira'), specifying the API endpoint '/rest/api/3/status'. It distinguishes from siblings by focusing on status retrieval rather than tickets, attachments, or projects, though it doesn't explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'execute_jql' for filtered queries or 'list_projects' for project-related data. It includes an irrelevant instruction ('Do not use markdown in your query') that doesn't help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API endpoint, implying a network call, but does not describe critical behaviors such as authentication requirements, error handling, rate limits, or what happens if the attachment or page doesn't exist. The 'do not use markdown' note adds some context, but overall, the description lacks sufficient detail for safe and effective use in a mutation operation.
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, consisting of two sentences that directly state the tool's purpose and a technical constraint. It is front-loaded with the main action, avoiding unnecessary verbosity. However, the second sentence about markdown feels slightly tacked on and could be integrated more smoothly, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool that interacts with two systems (Jira and Confluence), no annotations, and no output schema, the description is inadequate. It fails to address key contextual elements such as authentication needs, error responses, or the format of results. The agent is left with significant gaps in understanding how to invoke this tool successfully and handle potential issues.
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, providing clear definitions for all three parameters. The description does not add any meaningful semantic information beyond what the schema already states, such as explaining relationships between parameters or additional constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description neither compensates for gaps nor enhances understanding.
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 ('Add an attachment') and the resources involved ('to a ticket on Jira from a Confluence page'), specifying the source and destination. It distinguishes from sibling tools like 'add_attachment_from_public_url' by mentioning Confluence as the source, but does not explicitly contrast with other attachment-related tools or explain its unique scope beyond the API endpoint reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, only mentioning not to use markdown in queries, which is a technical constraint rather than usage context. It does not indicate when to use this tool versus alternatives like 'add_attachment_from_public_url' or other ticket modification tools, nor does it specify prerequisites such as needing access to both Jira and Confluence. This leaves the agent without clear direction on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates a ticket (implying a write/mutation operation) and mentions the markdown restriction, but lacks critical details like required permissions, whether the operation is idempotent, error handling, or what happens on success (e.g., returns ticket ID). For a mutation tool with zero annotation coverage, this is insufficient.
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 core purpose. The second sentence about markdown is relevant but could be more integrated. No wasted words, though it could be slightly more structured (e.g., separating constraints from the main action).
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?
For a mutation tool with 5 parameters, no annotations, no output schema, and 60% schema coverage, the description is incomplete. It lacks information on authentication needs, error cases, return values, and how to handle the 'parent' parameter (optional but semantically important). The markdown hint is useful but insufficient for full 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 60% (3 of 5 parameters have descriptions in schema: project.key, summary, description). The description adds no parameter-specific information beyond the markdown restriction, which applies to all fields but doesn't clarify individual parameters. With moderate schema coverage, the baseline is 3 as the description doesn't compensate for the coverage gap nor add meaningful semantics.
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 ('Create a ticket') and target system ('on Jira'), with the specific API endpoint '/rest/api/3/issue' providing technical context. However, it doesn't distinguish this from sibling tools like 'edit_ticket' or 'delete_ticket' beyond the creation aspect, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'edit_ticket' or 'assign_ticket'. It mentions 'Do not use markdown in any field' as a constraint, but this is a formatting rule rather than usage context. No prerequisites, dependencies, or comparison to siblings are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an edit operation (implying mutation) and provides a formatting constraint about markdown, but lacks critical behavioral details: authentication requirements, whether changes are reversible, error handling, rate limits, or what happens to fields not mentioned in the update. For a mutation tool with zero annotation coverage, this is insufficient.
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 appropriately concise with two sentences. The first sentence states the core purpose and API endpoint, while the second provides an important formatting constraint. Both sentences earn their place, though the structure could be slightly improved by front-loading more critical behavioral information.
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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about authentication requirements, error responses, what fields can be edited, whether partial updates are allowed, and the format of successful responses. The markdown constraint is useful but doesn't compensate for the broader gaps in behavioral 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 the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter relationships, constraints, or usage examples. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description provides no compensatory value.
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 ('Edit a ticket') and target resource ('on Jira'), with specific API endpoint context. It distinguishes from siblings like 'create_ticket' by focusing on modification rather than creation. However, it doesn't explicitly differentiate from other edit-like operations that might exist in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_ticket' or 'assign_ticket'. It mentions 'Do not use markdown in any field' which is a formatting constraint but doesn't address contextual usage scenarios, prerequisites, or exclusions. No explicit when/when-not instructions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API endpoint ('/rest/api/3/search/jql') and a constraint about markdown, but fails to describe critical behaviors: whether this is a read-only or mutation operation (though 'Execute' suggests read-only), what authentication or permissions are required, rate limits, error handling, or what the response format looks like. For a query tool with zero annotation coverage, this is inadequate.
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 with two sentences that directly address the tool's function and a key constraint. It's front-loaded with the main purpose, and the second sentence adds necessary technical guidance without fluff. However, it could be slightly more structured by explicitly separating behavioral details from usage instructions.
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 executing JQL queries (which can involve syntax, permissions, and result handling), no annotations, and no output schema, the description is incomplete. It lacks information on authentication needs, error cases, response format, and how results are returned (e.g., pagination, fields included). This makes it inadequate for an agent to use the tool effectively without additional 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?
The input schema has 100% description coverage, with clear documentation for both parameters ('jql' and 'number_of_results'), including a default value. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain JQL syntax, result formatting, or constraints on 'number_of_results'. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Execute a JQL query') and the target resource ('on Jira'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from sibling tools like 'query_assignable' or 'get_only_ticket_name_and_description', which might also involve querying Jira data. The description is clear about what it does but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Do not use markdown in your query', which is a technical constraint but doesn't explain when to use this tool versus alternatives. There's no mention of when this tool is appropriate compared to sibling tools like 'query_assignable' or 'get_only_ticket_name_and_description', nor any context about prerequisites or exclusions. This leaves the agent with little guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the API endpoint but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'list all' entails (e.g., if it returns all projects at once or supports filtering). The markdown warning is minor and doesn't cover core behavior.
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?
Two sentences that are reasonably efficient, though the second sentence about markdown feels slightly out of place as it's more of a technical implementation note rather than core description. Overall, it's front-loaded with the main 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 no annotations and no output schema, the description is incomplete. It lacks details on return format (e.g., what fields are included), error handling, or how 'list all' interacts with the 'number_of_results' parameter. For a read operation with one parameter, more context is needed.
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 the parameter 'number_of_results' is fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score of 3.
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 all the projects') and target resource ('on Jira'), with specific API endpoint reference. However, it doesn't differentiate from sibling tools like 'execute_jql' or 'get_only_ticket_name_and_description' that might also retrieve project-related data, missing explicit distinction.
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 this tool versus alternatives like 'execute_jql' for filtered queries or other sibling tools. The description includes a technical note about not using markdown, but this doesn't help with tool selection context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the API endpoint and a technical constraint about markdown, but doesn't describe what 'assignables' means (users, groups?), whether this is a read-only operation, what permissions are needed, what the response format looks like, or any rate limits. For a query tool with zero annotation coverage, this leaves significant behavioral gaps.
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 appropriately concise with two sentences that each serve a purpose: the first states the tool's function and endpoint, the second provides a technical constraint. There's no unnecessary verbosity, though the structure could be slightly improved by front-loading the core purpose more clearly.
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 no annotations, no output schema, and a query tool that interacts with Jira's user assignment system, the description is incomplete. It doesn't explain what 'assignables' are, what the response contains, or important behavioral aspects like authentication requirements or error handling. The technical constraint about markdown is helpful but insufficient for comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'project_key' well-documented as 'The id of the project to search'. The description doesn't add any additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to given complete schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('query assignables') and target resource ('to a ticket on Jira'), with the specific API endpoint provided. It distinguishes from siblings like 'assign_ticket' or 'create_ticket' by focusing on querying rather than modifying. However, it doesn't explicitly differentiate from 'execute_jql' which also queries Jira data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'execute_jql' for general Jira queries or 'assign_ticket' for actual assignment. It mentions not using markdown in queries, but this is a technical constraint rather than usage context. No explicit when/when-not or alternative tool references are included.
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-mcp-server MCP server](https://glama.ai/mcp/servers/KS-GEN-AI/jira-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/KS-GEN-AI/jira-mcp-server)

Score Badge

Copy to your README.md:

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

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/KS-GEN-AI/jira-mcp-server'

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