mcp-server-jira

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct action and resource: search, get, create, update, comment, transitions, transition, assign, and list projects. There is no overlap between their purposes.
Naming Consistency4/5
All tool names consistently use the snake_case verb_noun pattern (e.g., search_issues, get_issue, create_issue). The only minor deviation is 'get_transitions' which is a noun-adjective form, but it still fits the pattern well.
Tool Count4/5
9 tools is a reasonable count for a JIRA MCP server covering core operations. It covers search, CRUD, comments, transitions, assignment, and project listing without being excessive.
Completeness4/5
The tool surface covers the most common JIRA workflows: search, CRUD, commenting, status transitions, and assignment. Missing capabilities like deleting issues or managing attachments are minor gaps for a typical agent use case.
Average 3.3/5 across 9 of 9 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
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 are present, so the description must fully disclose behavior. It only states 'gets details,' omitting whether the tool is read-only, what happens with invalid keys, or any side effects. This is insufficient for a fetch 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 a single, brief sentence in Japanese. It is concise but may benefit from a note about parameter usage or context. There is no waste, but it could be slightly more informative without losing conciseness.
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 tool has a modest parameter set and no output schema, so the description should compensate. It fails to explain what details are returned or how the `fields` parameter influences output. For a JIRA tool with many siblings, this is 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 description coverage is 100%, so the schema already documents both parameters. The description adds no meaning beyond the schema, aligning with the baseline 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 ('JIRA 課題の詳細を取得します') clearly indicates fetching details of a JIRA issue, with a specific verb and resource. However, it does not differentiate from siblings like `search_issues` or `get_transitions`.
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 such as `search_issues`. The description lacks context about prerequisites or 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?
No annotations are present, so the description must fully communicate behavioral traits. It states 'search' which implies a read-only operation, but it does not disclose whether the search is paginated, if there are rate limits, whether it returns full issue objects or summaries, or if authentication is required. The description adds minimal behavioral context beyond the basic action.
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, concise sentence that directly states the purpose. It is front-loaded and efficient, with no unnecessary words. However, for a tool with three parameters and no annotations, slightly more detail (e.g., a second sentence on typical usage) could improve completeness without harming conciseness.
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 absence of annotations and output schema, the description is insufficient. It does not explain return format, error handling, or common use cases. For a search tool with multiple parameters, the agent would benefit from knowing that results are paginated or that fields can reduce payload size. The current description is too minimal to fully prepare an agent for correct 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?
The input schema has 100% description coverage for all three parameters (jql, fields, maxResults). The tool description does not add any additional meaning or usage hints beyond what the schema already provides. With full schema coverage, the baseline is 3, and the description adds no extra value here.
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 core function: searching JIRA issues using a JQL query. The verb 'search' and resource 'issues' are specific, and it distinguishes from sibling tools like get_issue (single issue retrieval) and mutation tools (create_issue, update_issue). However, it does not elaborate on the search capabilities or scope (e.g., whether it supports advanced filtering beyond JQL).
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. For example, it does not clarify that get_issue should be used to fetch a single issue by key, or that search_issues is appropriate for bulk queries. There are no usage hints, prerequisites, or exclusions, leaving the agent to infer context from the tool name and siblings.
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 carry the full burden of behavioral disclosure. The verb '変更' implies a mutation, but the description does not mention required permissions, side effects, error handling, or whether changes are reversible. For a mutating tool, this is minimal 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, concise sentence that gets straight to the point without any filler. It is appropriately sized for the simplicity of the 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 low complexity (2 required params, no output schema), the one-sentence description is minimally viable: it states the purpose and the schema fills in parameter details. However, it lacks any mention of return values, errors, or permissions, which would be useful in a complete description.
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 both parameters (issueKey, accountId) clearly described in the schema. The tool description adds no extra parameter semantics beyond restating the overall action, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'JIRA 課題の担当者を変更します' (Changes the assignee of a JIRA issue) uses a specific verb and resource, making the purpose immediately clear. It does not explicitly differentiate from sibling tools like update_issue, but the action is specific enough to be understood.
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., update_issue) or any prerequisites such as permissions or validation rules. It only states the basic function, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly implies mutation by saying 'update', but it does not disclose potential side effects such as whether updates are atomic, trigger notifications, or require specific permissions. However, since the schema lists 6 writable fields and the description matches, it is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence (7 words), which is concise but arguably under-specified. It front-loads the core purpose, but could benefit from a second sentence about behavior or use-case to earn a higher score.
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 has 6 parameters (all with descriptions in schema), no output schema, and no annotations, the description is minimally complete. It informs that the tool updates fields but lacks cautions about replace semantics (e.g., labels replacing existing) or permission requirements, which a JIRA update tool could benefit from.
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% — each property has a clear description (e.g., 'New labels (replaces existing)', 'New summary/title'). The description does not add extra semantics beyond the schema, but with full 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 'JIRA 課題のフィールドを更新します' clearly states the verb ('更新') and resource ('課題'), which translates to 'update JIRA issue fields'. While it doesn't explicitly differentiate from siblings like transition_issue which updates status, its specificity is good.
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 siblings such as 'create_issue', 'assign_issue', or 'transition_issue'. There is no mention of prerequisites, exclusions (like when to use assign_issue instead), or when updating via other means is preferred.
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 disclosing behavioral traits. It only states the core action without mentioning side effects, authentication requirements, idempotency, or whether the comment triggers notifications. For a mutation tool, this level of disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. Every word is necessary, and there is no superfluous content. It is appropriately sized for a simple tool with two parameters.
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 absence of output schema and the presence of sibling tools, the description is incomplete. It does not explain what the tool returns (e.g., comment ID, success indicator) nor does it provide any contextual cues like typical use cases or order of operations (e.g., first get issue, then add comment). An agent needs more than this minimal description to use the tool reliably.
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% (both parameters have descriptions in the schema). According to the rubric, the baseline is 3 even if the tool description adds no further parameter information. The description does not elaborate on parameter semantics beyond what the schema already provides.
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 is a concise Japanese sentence stating 'Add a comment to a JIRA issue,' which clearly identifies the verb (add) and resource (comment to a JIRA issue). It is unambiguous and distinct from sibling tools like search_issues, get_issue, create_issue, etc., none of which involve adding comments.
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 usage guidance is provided. The description does not indicate when to use add_comment versus its siblings, such as whether update_issue can also add comments, or what prerequisites (e.g., issue existence) are needed. This omission leaves the agent without contextual decision support.
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 correctly implies a read operation (getting transitions) and does not claim destructive behavior. However, it lacks detail such as whether it returns all possible transitions or only those allowed for the current user, and whether it respects JIRA workflow conditions like permissions or required fields.
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 that is concise and front-loaded with the core purpose. It contains no redundant or irrelevant information, earning its place.
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 there is no output schema and the tool has a single parameter, the description should explain what the response contains (e.g., list of transition names, IDs, and to-statuses) and whether it requires specific permissions. The current description is too minimal for an agent to use the tool effectively without guessing the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents 'issueKey' with an example. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. It does not clarify format constraints or how the issueKey relates to the project.
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 states the tool gets available status transitions for a JIRA issue, using the specific verb '取得します' (retrieve) and resource 'ステータス遷移' (status transitions). It somewhat distinguishes from siblings like transition_issue, which performs the transition, and get_issue, which gets issue details. However, it could be more explicit that this is a lookup of possible next states, not a history.
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?
There is no guidance on when to use this tool versus alternatives. The sibling tools include transition_issue (which would depend on knowing valid transitions) and search_issues, but the description does not clarify that this tool is a prerequisite for transition_issue or that it is read-only. An agent would benefit from knowing to call this before transition_issue.
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 must fully convey behavioral traits. It describes a state change (mutation) but does not mention if it is reversible, requires specific permissions, or the impact on linked issues. For a state-changing tool, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence—without unnecessary detail. However, it could be slightly more informative without losing concision, e.g., mentioning that the transition must be valid for the current status.
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 has 2 required parameters and no output schema, the description is minimally complete: it explains the action and relies on the schema for parameter details. Additional context on success responses, error cases (e.g., invalid transition), or workflow constraints would improve 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?
Schema description coverage is 100%, meaning the schema already documents both parameters well (issueKey and transitionId). The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the status of a JIRA issue, using a specific verb (変更します) and resource (課題のステータス). It is distinct from siblings like create_issue or update_issue, though it could explicitly mention the concept of 'transitioning' an issue through a workflow.
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 is minimal and provides no guidance on when to use this tool versus alternatives. However, the sibling tools (get_transitions, assign_issue) and schema hint (transitionId via get_transitions) help infer proper usage. A brief note on prerequisites or when not to use (e.g., when status change is not allowed) would improve clarity.
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?
The description is concise and correctly indicates that the tool creates an issue (a write operation). Since no annotations are provided, the description carries the full burden and does so without contradictions. The behavioral implication is clear: this is a mutation that will persist data. It could be improved by noting any prerequisites, such as the need for the user to have project permissions, but the current text is honest and minimally sufficient.
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, concise sentence in Japanese that conveys the tool's purpose without waste. It is front-loaded with the action and resource, making it scanable. Every word earns its place, and nothing extraneous is included.
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 complexity of 7 parameters (3 required), no annotations, no output schema, and no enum constraints, the description is somewhat underpowered. It provides the basic purpose but omits context such as required fields, typical usage patterns, or behavior on success. An agent would need to rely solely on the schema to understand mandatory inputs like `projectKey`, `summary`, and `issueType`. The description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's description coverage is 100%, meaning all 7 parameters are documented in the schema alone. The description adds no additional semantic value beyond what the schema already provides (e.g., parameter types, descriptions, or relationships). According to the guidelines, with high schema coverage, a baseline of 3 is appropriate. The description does not compensate with extra context like parameter ordering or dependencies.
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 verb ("作成します") and the resource ("JIRA に新しい課題"), making the primary purpose unambiguous. However, it lacks differentiation from sibling tools like `update_issue`, `add_comment`, or `transition_issue`, which are all issue-related. The description could be improved by noting that it creates a new issue, while others modify or comment on existing ones.
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. For example, it doesn't mention that `create_issue` is used for new issues while `update_issue` modifies existing ones, or that `add_comment` appends comments. An agent must infer context from the tool name alone, which is insufficient for optimal 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, the description carries full burden but only states the basic action. It does not disclose potential pagination, ordering, permission requirements, or response format, leaving behavioral traits opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that front-loads the purpose without redundancy. It earns its place fully.
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 zero-parameter, no-output-schema, simple list nature, the description is mostly complete. Slight addition on return structure or limits would improve clarity, but the current text is adequate for a simple listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not elaborate on parameter meanings. The baseline of 4 applies as the schema is vacuously complete.
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 and resource: '取得します' (retrieve) and 'JIRA プロジェクトの一覧' (list of JIRA projects). It distinguishes from sibling tools focused on issues, making its purpose unambiguous.
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?
While no explicit when-to-use guidance is provided, the tool's purpose is self-evident: use it to retrieve JIRA projects. Context clearly separates it from issue-centric siblings, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kt057/mcp-server-jira'

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