jira-confluence-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: Jira actions target tickets, comments, fields, and attachments, while Confluence actions target pages, child pages, and search. Overlap is minor and resolved by descriptions, such as get_ticket for whole-ticket data and get_attachment for one specific attachment.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern: get_*, search_*, post_*, update_*. There are no one-word verbs, version suffixes, or mixed conventions, making the tool set predictable.
Tool Count5/5
Eight tools is well-scoped for a server spanning Jira and Confluence. Each tool serves a distinct purpose and none are redundant, keeping the surface compact while covering meaningful retrieval and update workflows.
Completeness4/5
The set supports the core investigation workflow: search and read Jira tickets, download attachments, add comments, update fields, and search/read Confluence pages. Missing issue creation, issue deletion, and Confluence write operations are notable as general CRUD gaps, but they appear to be intentionally outside the workflow described by this server.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 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 provided, so the description must disclose behavioral aspects. It only states the core action without any additional context such as pagination, ordering, whether it includes archived pages, or what happens if the page has no children. There is no mention of authentication or performance implications. This is a minimal description with no extra behavioral insight.
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 gets straight to the point. It is front-loaded with the main purpose. No superfluous information. This is efficient and meets the standard for conciseness, though it might be slightly too minimal for full credit.
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 is simple (one parameter, no output schema), the description is somewhat adequate, but it leaves out key details like whether it returns only direct children (it does say 'direct' though), and any behavioral nuances. The annotations are absent, so the description is the only source of context. It could mention that it does not recursively list all descendants, which would be helpful. The absence of output schema means the agent doesn't know what to expect in the response, but the description doesn't clarify either.
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 schema description coverage at 0%, the description must compensate. It does mention 'page_id' implicitly by saying 'direct child pages of a Confluence page', which implies the page_id parameter identifies the parent. However, it doesn't clarify the format (e.g., numeric ID or string), or that the page_id is the ID of the parent page. The schema has only one parameter, so the description provides some context but could be more explicit about the parameter's role.
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 lists direct child pages of a Confluence page, using a specific verb ('List') and resource ('direct child pages'). It distinguishes from siblings like get_page (which likely retrieves a single page) and search_confluence (which searches). However, it doesn't explicitly mention that it only returns direct children, which is a slight gap.
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 you need to list child pages of a specific page. It doesn't explicitly contrast with alternatives like search_confluence or get_page, but the purpose is clear enough. No exclusions or when-not-to-use guidance is provided, so it's adequate but not explicit.
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 burden of disclosing behavior. It does reveal a key behavioral trait: the tool is guarded by DRY_RUN / ALLOW_WRITES env vars, suggesting it may be a no-op in certain environments. However, it does not mention authentication requirements, error handling, or what happens if the field or value is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, with the core action first and the guard condition second. There is no fluff or redundant information, making it highly efficient 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?
For a mutation tool with no annotations and no output schema, the description is quite sparse. It explains the env var guard but does not cover potential side effects, required permissions, success/failure indicators, or behavior back to the caller. A tool that updates Jira fields likely has complexities (e.g., required fields, validation) that are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning about the parameters. It does not explain what 'field' expects (e.g., ID vs name), the format of 'value', or any constraints. The agent must guess from the parameter names alone, which is insufficient given the schema has no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update a single Jira field value.' It uses a specific verb (Update) and identifies the resource (single Jira field value), which distinguishes it from sibling tools like post_comment (comments) and search_tickets (search). The scope is unambiguous.
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?
It provides some usage context by mentioning the guard by DRY_RUN / ALLOW_WRITES, which implies it's a write operation that may be disabled. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites beyond the env var guard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It indicates a download action and the destination directory, which is useful, but it does not mention potential side effects, file handling, or error conditions. The description adds context but not extensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the main action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and no output schema, the description is minimally complete: it states action and destination. However, given zero parameter documentation and no annotations, it leaves out important details like required permissions, file format, or behavior when the attachment does not exist, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for the lack of parameter explanations. The description mentions 'by id' but does not clarify what ticket_id and attachment_id look like or how they relate. With zero coverage and only bare parameter names, the agent lacks guidance on format or purpose beyond the names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download'), the resource ('a specific Jira attachment'), the identifier ('by id'), and the destination ('into the ticket's log directory'). It is specific enough to distinguish from sibling tools like get_ticket or search_confluence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates a specific use case but does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having a ticket_id and attachment_id. It implies usage without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly mentions the DRY_RUN / ALLOW_WRITES env var guard, which informs the agent that the write operation might be blocked or simulated. This is valuable transparency beyond the basic write implication. However, it does not mention other potential side effects, permissions, or return behavior, so it is not a perfect 5.
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 exactly two sentences, front-loaded with the primary purpose. Every word earns its place; there is no fluff or redundancy. It is optimally concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks essential context. It does not describe what happens after posting (e.g., returns comment ID or confirmation), nor does it address error cases or edge conditions. The guard is mentioned, but parameter details are missing. Given the lack of annotations and output schema, the description is minimally complete but leaves gaps that could cause an agent to misinvoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description adds no semantic detail about the parameters. It simply echoes the schema field names (body, ticket_id) without explaining formats, constraints, or examples. The names are self-explanatory, but the description fails to compensate for the lack of schema descriptions, leaving the agent to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Post a comment on a Jira ticket.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_ticket, search_tickets, and update_ticket_field, which handle retrieval or field updates.
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 only mentions that it is 'Guarded by DRY_RUN / ALLOW_WRITES env vars,' which is a behavioral constraint, not a usage recommendation. There is no mention of prerequisites, context, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys that this is a read-only search operation using JQL, and gives a usage example. However, it does not describe result shape, pagination behavior, rate limits, or what search results contain.
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 with no filler. The parenthetical example is succinct and adds practical value without bloating the text.
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 search tool with no output schema and no annotations, the description should mention what the search returns (e.g., matching issues and key fields) and how max_results behaves. The description covers high-level intent but leaves important invocation and interpretation details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'jql' by identifying it as JQL and giving an example, but it says nothing about the optional 'max_results' parameter or how results are limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Jira issues using JQL, and the parenthetical example 'to find similar historical defects' adds a concrete purpose. This distinguishes it from sibling tools like get_ticket and search_confluence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example provides clear context for when to use the tool: finding similar historical defects via JQL. It does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly reveals a notable side effect: automatic download of log-like attachments into a shared data directory, and offers a skip flag. It does not mention error behavior or permission requirements, but the main side effect is transparently disclosed.
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?
Three short sentences, front-loaded with the core purpose, then side-effect and option. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and no output schema, the description adequately covers the fetched content and the key side-effect. It is slightly incomplete in parameter details and alternative guidance, but sufficient for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains download_logs=false to skip, but does not clarify the default/null behavior of download_logs or the expected format of ticket_id (e.g., Jira key vs numeric ID). Only partial compensation is provided for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Fetch a Jira ticket' and enumerates the returned content (summary, description, comments, attachments, metadata). This distinguishes it from sibling tools like search_tickets (searching) and get_attachment (retrieving a specific attachment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool to fetch a full Jira ticket with details. However, there is no explicit statement about when to prefer it over siblings or when to use alternatives like search_tickets or get_attachment. The download_logs guidance is operational rather than selection-oriented.
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 discloses the output format (clean plain text and metadata) and notes caching behavior, which are useful behavioral details. However, it does not mention potential errors or limitations, but for a simple read operation this is acceptable.
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 conveys the core functionality without unnecessary words. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description covers the essential aspects: what it does, the output format, and caching. It could elaborate on edge cases, but it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (page_id) which is self-explanatory and required. The description adds no extra context about the parameter, but its meaning is clear from the name and type. Since schema coverage is high, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Confluence page and returns clean plain text plus metadata, which is specific and distinguishes it from sibling tools like get_ticket or search_confluence. The verb 'fetch' and resource 'Confluence page' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as search_confluence or get_child_pages. It mentions caching but lacks guidance on selection criteria or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the CQL full-text search mechanism, the returned fields (title, url, excerpt, relevance score), and the mechanism_signal filtering behavior with rationale. It does not cover auth, rate limits, or pagination, but it provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. Each sentence adds relevant information: what is searched, how results are shaped, and when filtering occurs. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description provides a useful picture of result shape and ranking behavior. It also explains the non-obvious mechanism_signal behavior. The main gaps are a fuller explanation of the cql parameter and explicit handling of result limits, but overall it is adequate.
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 0%, so the description must compensate. It explicitly explains mechanism_signal, including its expected value type and filtering effect. Query and max_results are reasonably self-evident from their names, but cql is only indirectly referenced via 'Uses CQL full-text search' and is not clearly defined.
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 starts with a specific verb and resource: 'Search the Confluence knowledge base', and immediately states the result type ('ranked, normalised results'). It clearly distinguishes this from sibling tools like search_tickets and get_page by naming the Confluence knowledge base as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool as a Confluence search tool, which implicitly differentiates it from search_tickets and page-fetching siblings. However, it does not explicitly state when not to use it or mention alternative tools by name.
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-confluence-mcp MCP server](https://glama.ai/mcp/servers/anands-bounteous/jira-confluence-mcp/badges/card.svg)](https://glama.ai/mcp/servers/anands-bounteous/jira-confluence-mcp)

Score Badge

Copy to your README.md:

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

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