Provides tools for searching Confluence Cloud spaces and retrieving page content and child pages.
Provides tools for interacting with Jira Cloud, including fetching ticket details and attachments, posting comments, updating fields, and performing JQL searches.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jira-confluence-mcp search Jira for similar defects to EA-123 and get the Confluence runbook"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A single MCP server that gives the Rapid7 SI Triage agent read/write access to Jira Cloud (tickets, attachments, comments, search) and Confluence Cloud (the historical knowledge base of runbooks and postmortems). Combining both Atlassian products in one server is natural: they share the same auth and host, and the triage workflow uses them together.
A key side effect lives here: when the agent fetches a ticket, this server auto-downloads log-like attachments into a shared directory that the companion Log Intelligence MCP then ingests.
Tool | Purpose |
| Fetch + normalise a ticket (summary, description, comments, attachments, product/components, environment). Auto-downloads log attachments unless |
| Download a specific attachment by id into the ticket's log dir. |
| JQL search — used to find similar historical defects. |
| Post a comment (write; guarded). |
| Update one field (write; guarded). |
Tool | Purpose |
| CQL/text search of the KB. Returns ranked, normalised results (title, url, excerpt, relevance) — the same shape as Jira search so the agent handles both uniformly. |
| Fetch a page as clean plain text (storage-format markup stripped) + metadata. Cached. |
| List direct child pages (walk a runbook space). |
Related MCP server: inhouse_confluence_mcp
Atlassian Cloud uses HTTP Basic auth with email:api_token (base64). Secrets
come from the environment only — never hardcoded. Copy .env.example to .env:
ATLASSIAN_BASE_URL=https://asgspratapsingh.atlassian.net
ATLASSIAN_EMAIL=asgspratapsingh@gmail.com
ATLASSIAN_API_TOKEN=<create at id.atlassian.com/manage-profile/security/api-tokens>
SI_DATA_DIR=./si_dataATLASSIAN_BASE_URL may be any URL from your site — it's normalised to the site
origin automatically (e.g. …atlassian.net/jira/for-you?tab=x →
https://…atlassian.net).
Write safety. DRY_RUN=1 refuses all writes (read-only). ALLOW_WRITES=0
refuses writes even when not in dry-run. Both post_comment and
update_ticket_field respect these guards.
Attachment download. AUTO_DOWNLOAD_LOGS=1 (default) downloads attachments
whose name ends in LOG_ATTACHMENT_SUFFIXES (.log,.txt,.gz,.out,.err) or that
are text/plain, up to MAX_ATTACHMENT_MB (50). Files land in
SI_DATA_DIR/logs/<ticket_id>/.
The HTTP client retries 429/5xx with exponential backoff (honouring
Retry-After), controlled by HTTP_MAX_RETRIES and HTTP_TIMEOUT.
cd jira-confluence-mcp
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e . # installs mcp, httpx, uvicorn
cp .env.example .env # fill in ATLASSIAN_API_TOKEN
# stdio:
python -m jira_confluence_mcp --transport stdio
# HTTP (streamable-http at http://127.0.0.1:8080/mcp):
python -m jira_confluence_mcp --transport httpThis server is one of four processes in the SI Triage POC (this + the Log Intelligence and Historical KB MCPs + the orchestrator). For the full multi-service manual startup sequence,
.envlayout across all four repos, and end-to-end test steps, seeorchestrator-agent/si-triage-automation/README.md→ "Running the full system manually".
{
"mcpServers": {
"jira-confluence": {
"command": "python",
"args": ["-m", "jira_confluence_mcp", "--transport", "stdio"],
"env": {
"ATLASSIAN_BASE_URL": "https://asgspratapsingh.atlassian.net",
"ATLASSIAN_EMAIL": "asgspratapsingh@gmail.com",
"ATLASSIAN_API_TOKEN": "…",
"SI_DATA_DIR": "/absolute/path/to/si_data"
}
}
}
}Set SI_DATA_DIR to the same absolute path for both servers.
si_data/
logs/<ticket_id>/… # THIS server writes downloaded attachments here
# the Log Intelligence MCP reads + indexes themFlow: get_ticket(EA-123) here → files appear in logs/EA-123/ →
ingest_ticket_logs("EA-123") on the Log MCP → agent queries logs →
delete_ticket_logs("EA-123") cleans up.
This server's HTTP transport defaults to 8080; the Log Intelligence MCP uses 8081, so both can run simultaneously.
pytest # in the POC environment
python tests/_runner.py # offline harness when pytest isn't installedCovers auth-header construction, base-URL normalisation, ADF→text flattening, ticket normalisation, log-attachment filtering, Confluence storage-format stripping, search-result normalisation, CQL escaping, and — via a stub HTTP transport (so no network is needed) — ticket fetch with auto-download, JQL search normalisation, write guards, Confluence search/get_page/caching, and child-page listing. 19 tests, all offline.
Live Jira/Confluence calls and running the MCP over a real transport need network access and the
mcp/httpxpackages installed, which the build sandbox blocks. The tests validate all request-building and response-handling logic against real payloads through the stubbed transport.
Download a specific Jira attachment by id into the ticket's log directory.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes | ||
| attachment_id | Yes |
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.
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.
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.
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.
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.
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.
List the direct child pages of a Confluence page.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes |
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.
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.
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.
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.
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.
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.
Fetch a Confluence page as clean plain text plus metadata (cached).
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes |
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.
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.
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.
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.
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.
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.
Fetch a Jira ticket (summary, description, comments, attachments, metadata).
Automatically downloads log-like attachments into the shared data directory so the Log Intelligence MCP can ingest them. Set download_logs=false to skip.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes | ||
| download_logs | No |
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.
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.
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.
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.
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.
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.
Post a comment on a Jira ticket. Guarded by DRY_RUN / ALLOW_WRITES env vars.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| ticket_id | Yes |
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.
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.
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.
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.
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.
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.
Search the Confluence knowledge base; returns ranked, normalised results.
Uses CQL full-text search. Results include title, url, excerpt, and relevance score in the same shape as Jira search results. When mechanism_signal (an exception/error class or quoted error string) is supplied, hits with no token overlap against it are dropped, since a broad site search can match an unrelated write-up on topical vocabulary alone.
| Name | Required | Description | Default |
|---|---|---|---|
| cql | No | ||
| query | Yes | ||
| max_results | No | ||
| mechanism_signal | No |
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.
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.
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.
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.
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.
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.
Search Jira issues with JQL (e.g. to find similar historical defects).
| Name | Required | Description | Default |
|---|---|---|---|
| jql | Yes | ||
| max_results | No |
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.
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.
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.
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.
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.
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.
Update a single Jira field value. Guarded by DRY_RUN / ALLOW_WRITES env vars.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| value | Yes | ||
| ticket_id | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_attachmentget_child_pagesget_pageget_ticketpost_commentsearch_confluencesearch_ticketsupdate_ticket_fieldScored across 8 tools
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.
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.
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.
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.
Jepto MCP server that provides access to client knowledgebase & analytics for connected data sources
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
