Jira MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific Jira resources and actions. There is no overlap between tools like get_jira_issue (single issue details), list_project_issues (project-specific listing), and search_jira_issues (general JQL search), making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming convention is predictable with verbs like 'get', 'list', and 'search' clearly indicating the action type, and nouns specifying the target resource (e.g., jira_issue, project, boards).
Tool Count5/5
With 10 tools, this server is well-scoped for Jira operations, covering core workflows like issue retrieval, project management, and board/sprint handling. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness3/5
The toolset provides strong read/search capabilities but has notable gaps in write operations. There are no tools for creating, updating, or deleting issues, comments, or other resources, which limits agents to read-only workflows and may cause failures in scenarios requiring modifications.
Average 3.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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 full burden. It states it gets 'detailed information' but doesn't disclose what details are included, whether it's read-only, requires authentication, has rate limits, or error behaviors. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, includes a helpful example, and has zero wasted words. Every element earns its place efficiently.
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 'detailed information' includes, return format, or error handling. For a tool with rich sibling context and no structured output, more detail is needed to be fully helpful.
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 schema fully documenting the issueKey parameter. The description adds an example (PROJ-123) which provides context, but doesn't add substantial meaning beyond what the schema already provides, meeting the baseline for high coverage.
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 'detailed information about a Jira issue', specifying it's by issue key. It distinguishes from siblings like list_project_issues or search_jira_issues by focusing on a single issue, but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_jira_issue_comments or search_jira_issues. The description implies usage for detailed info on a specific issue key, but lacks explicit when/when-not instructions or named 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 provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get') but does not mention any behavioral traits like authentication requirements, rate limits, error handling, or the format of the returned data (e.g., JSON structure). This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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, direct sentence that efficiently conveys the core purpose without any unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that retrieves structured data (statuses per issue type) and the lack of annotations and output schema, the description is insufficient. It does not explain what the output looks like (e.g., a list or mapping), potential errors, or any dependencies, leaving the agent with incomplete context for proper usage.
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 the parameter 'projectIdOrKey' clearly documented. The description does not add any semantic details beyond what the schema provides, such as examples of valid project keys or how to handle invalid inputs. Thus, it meets the baseline for high schema coverage without compensating with extra 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 verb 'Get' and the resource 'available statuses for each issue type in a project', making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'get_jira_project' or 'list_project_issues', which might also relate to project data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to choose it over 'get_jira_project' for project metadata or 'list_project_issues' for issue details. There is no mention of prerequisites, exclusions, or specific contexts, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'with pagination,' which hints at behavior, but lacks details on permissions, rate limits, error handling, or response format. For a read operation with pagination, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a key behavioral trait (pagination), making it appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with pagination, the description is incomplete. It should cover more behavioral aspects like response format, error cases, or usage context relative to siblings to adequately inform the 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 description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying pagination, which is already covered in 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 action ('List issues') and resource ('in a given sprint'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'list_project_issues' or 'search_jira_issues' which might also retrieve issues, 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. With siblings like 'list_project_issues' and 'search_jira_issues', there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'pagination and field selection,' which hints at some behavior, but doesn't describe critical aspects like authentication requirements, rate limits, error handling, or what the return format looks like (especially without an output schema). For a search tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Search issues using JQL with pagination and field selection.' It's front-loaded with the core purpose and includes all key capabilities without waste. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with JQL, pagination, field selection), no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, or behavioral constraints like rate limits or authentication needs. For a tool with 4 parameters and no structured output documentation, the description should provide more context to be fully helpful.
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 all four parameters (jql, startAt, maxResults, fields) with descriptions and constraints. The description adds no additional parameter semantics beyond what's in the schema—it merely echoes 'JQL with pagination and field selection' without providing syntax examples or usage nuances. Baseline 3 is appropriate when 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 tool's purpose: 'Search issues using JQL with pagination and field selection.' It specifies the verb ('Search'), resource ('issues'), and key capabilities (JQL, pagination, field selection). However, it doesn't explicitly differentiate from sibling tools like 'list_project_issues' or 'list_sprint_issues', which might also retrieve issues in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that retrieve issues (e.g., 'list_project_issues', 'list_sprint_issues', 'get_jira_issue'), there's no indication that this is the primary tool for complex JQL-based searches versus simpler listing operations. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation by using 'List', it lacks details on permissions, rate limits, pagination behavior (beyond what the schema covers), or what the output looks like. For a tool with no annotations, this leaves significant gaps in understanding how it behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key details about filtering. There is no wasted language or redundancy, making it easy to parse and understand quickly. This exemplifies optimal conciseness for a simple tool.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and hints at filtering, but lacks details on output format, error handling, or integration with sibling tools. Without annotations or an output schema, more context would be needed for full completeness.
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 description mentions optional type and project filters, which aligns with two of the four parameters in the schema. However, with 100% schema description coverage, the schema already fully documents all parameters, including their types, constraints, and descriptions. The description adds minimal value beyond what the schema provides, meeting the baseline for high coverage.
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 resource ('Jira boards'), making the purpose immediately understandable. It also mentions optional filtering capabilities, which adds specificity. However, it doesn't differentiate this tool from its siblings (like 'list_jira_projects' or 'list_board_sprints'), which would require a more explicit distinction to reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional filters but doesn't specify scenarios where filtering by type or project is appropriate, nor does it reference sibling tools for related tasks. Without any context on usage boundaries or prerequisites, this falls short of providing meaningful 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'optional state filter' and implies pagination through parameters, but doesn't describe key behaviors like whether this is a read-only operation, what the output format looks like, error handling, or rate limits. For a tool with 4 parameters and no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized for a straightforward listing tool and front-loads the essential information.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details about output format, error conditions, or integration with sibling tools. Without annotations or output schema, more behavioral context would be helpful for the agent to use this tool 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema by mentioning the 'optional state filter', which is already clear from the schema's enum. It doesn't provide additional context about parameter interactions or usage examples, meeting the baseline for high schema coverage.
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 sprints') and target resource ('for a given board'), making the purpose immediately understandable. It distinguishes from siblings like 'list_boards' or 'list_sprint_issues' by focusing specifically on sprints within a board. However, it doesn't explicitly differentiate from potential similar tools beyond the name, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions an optional state filter but doesn't explain when to apply it or suggest other tools for related tasks like 'list_sprint_issues' or 'search_jira_issues'. There's no context about prerequisites or typical use cases, leaving the agent with minimal direction.
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 'optional JQL tail filters' but doesn't disclose key behavioral traits such as pagination behavior (implied by parameters but not described), rate limits, authentication needs, or what the output looks like (e.g., list format, error handling). This leaves significant gaps for a tool with 4 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List issues for a project') and adds essential detail ('with optional JQL tail filters') without waste. Every word earns its place, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral aspects like pagination, output format, error conditions, or how it differs from siblings. Without annotations or output schema, the description should compensate more to guide effective use, but it falls short.
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 all parameters. The description adds minimal value beyond the schema by hinting at JQL usage ('optional JQL tail filters'), but doesn't provide additional syntax, examples, or constraints. With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter 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 verb ('List') and resource ('issues for a project'), specifying the action and target. It distinguishes from siblings like 'get_jira_issue' (single issue) and 'search_jira_issues' (general search) by focusing on project-specific listing with JQL filtering, though it doesn't explicitly name these alternatives.
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 through 'optional JQL tail filters,' suggesting it's for filtering within a project, but lacks explicit guidance on when to use this tool versus alternatives like 'search_jira_issues' (which might handle broader searches) or 'list_sprint_issues' (sprint-specific). No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions pagination, which is useful behavioral context, but doesn't cover other important aspects like authentication requirements, rate limits, error handling, or what the return format looks like. This is a minimal but not comprehensive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function and key behavioral trait (pagination). It's front-loaded with no wasted words, making it highly concise and well-structured.
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 moderate complexity (a read operation with pagination), no annotations, and no output schema, the description is minimally adequate. It covers the core purpose and pagination but lacks details on authentication, errors, or return values, leaving gaps for the agent to infer.
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 fully documents all three parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain comment structure or pagination details), meeting the baseline for high schema coverage.
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 'retrieve' and the resource 'comments for a Jira issue', making the purpose unambiguous. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_jira_issue' which might also return comments, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_jira_issue' that might include comments, there's no indication of when this specific comment-focused tool is preferred, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation (implied by 'Get'), authentication requirements, rate limits, error conditions, or what 'full metadata' includes. The description doesn't contradict annotations (none exist), but fails to provide necessary operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word contributes meaning without redundancy. It's appropriately sized for a simple lookup tool with one parameter.
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 operation with one parameter and 100% schema coverage, the description is minimally adequate. However, without annotations or output schema, it should better explain what 'full metadata' includes and any behavioral constraints. The description covers the basics but leaves gaps about the operation's scope and limitations.
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 is fully documented in the schema. The description adds marginal value by reinforcing that both 'key or ID' are accepted and providing examples ('e.g., PROJ or 10001'), but doesn't explain semantic differences between using key vs ID. This meets the baseline for high schema coverage.
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 full metadata') and resource ('for a Jira project'), specifying it works 'by key or ID'. It distinguishes from siblings like 'list_jira_projects' by focusing on individual project details rather than listing multiple projects. However, it doesn't explicitly contrast with 'get_project_statuses' which might provide overlapping information.
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 when needing detailed metadata for a specific project, but provides no explicit guidance on when to choose this over alternatives like 'list_jira_projects' (for overviews) or 'get_project_statuses' (for status-specific data). No exclusion criteria 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions pagination and optional querying, which are useful behavioral details, but doesn't cover other important aspects like authentication requirements, rate limits, error handling, or what 'accessible' means in terms of permissions. The disclosure is partial 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, efficient sentence that front-loads the core purpose ('List accessible Jira projects') and adds two key features ('with pagination and optional query'). There's no wasted verbiage, and every word earns its place.
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 list tool with no annotations and no output schema, the description is minimally adequate. It covers the basic action and key features but lacks details on output format, error cases, or integration with sibling tools. Given the context, it should provide more guidance on usage and results.
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 fully documents all three parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain query syntax or pagination behavior further). This meets the baseline for high schema coverage.
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 ('List') and resource ('accessible Jira projects'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_jira_project' (singular) or 'list_project_issues', which might cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_jira_project' (for a single project) or 'search_jira_issues' (for issues rather than projects). It mentions optional querying but doesn't clarify use cases or prerequisites.
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 MCP server](https://glama.ai/mcp/servers/imrnbeg/jira-mcp/badges/card.svg)](https://glama.ai/mcp/servers/imrnbeg/jira-mcp)

Score Badge

Copy to your README.md:

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

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