Allows reading, writing, searching, and managing attachments on Confluence pages via the Confluence REST API.
Click on "Install 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., "@confluence-mcp search for pages about API in the DEV space"
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.
MCP server for Confluence integration — read, write, search, and manage attachments via the Confluence REST API.
npm install -g @mcd/confluence-mcp-serverOr use with npx:
npx @mcd/confluence-mcp-serverRelated MCP server: Jira & Confluence MCP Server
Add to your MCP settings (e.g. ~/.kiro/settings/mcp.json):
{
"mcpServers": {
"confluence-mcp": {
"command": "npx",
"args": ["@mcd/confluence-mcp-server@latest"],
"env": {
"CONFLUENCE_URL": "https://your-confluence.atlassian.net",
"CONFLUENCE_USERNAME": "your-email@example.com",
"CONFLUENCE_TOKEN": "your-api-token",
"CONFLUENCE_CLOUD": "true"
}
}
}
}For local development, point directly to the compiled output:
{
"mcpServers": {
"confluence-mcp": {
"command": "node",
"args": ["/absolute/path/to/dist/index.js"],
"env": {
"CONFLUENCE_URL": "...",
"CONFLUENCE_USERNAME": "...",
"CONFLUENCE_TOKEN": "...",
"CONFLUENCE_CLOUD": "false"
}
}
}
}Variable | Description |
| Your Confluence instance URL |
| Your username or email |
| Your API token or password |
|
|
search — Search Confluence content (CQL)
get_page — Get page content by ID
get_page_children — Get child pages of a parent page
create_page — Create a new page
update_page — Update page content (inline HTML or file path)
get_attachments — List attachments on a page
download_attachment — Download an attachment to local disk
upload_attachment — Upload a local file as a page attachment, with optional embedding in page body
get_comments — Get page comments
add_comment — Add a comment to a page
Search:
{ "query": "space = DEV AND title ~ \"API\"", "limit": 10 }Update page with inline content:
{ "page_id": "123456", "content": "<h1>Title</h1><p>Updated content</p>" }Update page from file (recommended for large content):
{ "page_id": "123456", "content_file": "/absolute/path/to/content.html" }Upload attachment:
{ "page_id": "123456", "file_path": "/absolute/path/to/file.png" }Upload and embed in page body:
{
"page_id": "123456",
"file_path": "/absolute/path/to/image.png",
"embed_in_body": true,
"comment": "Optional comment"
}Images are embedded as <ac:image>, other files as a view-file macro link.
npm install
npm run buildAdd a comment to a Confluence page
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Comment content (HTML or plain text) | |
| page_id | Yes | Page ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It does not mention prerequisites (e.g., page existence), permission requirements, whether comments are appended, or any side effects beyond the action itself.
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 that uses precise language. Every word contributes directly to understanding the tool's purpose.
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 simple two-parameter tool with full schema coverage, the description is minimally sufficient. However, it lacks context about the expected behavior (e.g., HTML formatting, whether the comment is appended) and use cases, leaving room for ambiguity in an agent's decision-making.
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 100%, so the parameters are already fully documented. The description adds no additional semantic value beyond what the schema provides, meeting the baseline but not exceeding it.
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 ('Add') and the resource ('a comment to a Confluence page'), distinguishing it from sibling tools like get_comments or create_page. It is specific and immediately understandable.
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?
No guidance is provided on when to use this tool versus alternatives such as get_comments or update_page. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Confluence page
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Page title | |
| content | Yes | Page content (HTML) | |
| parent_id | No | Parent page ID (optional) | |
| space_key | Yes | Space key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It only states the action 'Create' without disclosing side effects, required permissions, return format, or any behavioral nuances beyond the basic operation.
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 short sentence with no wasted words. It is well-structured and front-loaded, though it lacks depth beyond the core purpose.
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?
With no output schema and no annotation support, the description provides only the basic purpose. It omits useful context such as return behavior, error conditions, or when to prefer this over update_page.
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 100%, so the schema fully documents all parameters. The description adds no parameter-specific detail, but the high coverage justifies the baseline 3.
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 'Create a new Confluence page' uses a specific verb ('Create') and resource ('Confluence page'), clearly distinguishing from siblings like update_page. It is not a tautology and 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?
No guidance is given on when to use this tool versus update_page or other sibling tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a Confluence attachment
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Page ID | |
| output_path | Yes | Output file path (absolute or relative) | |
| attachment_id | Yes | Attachment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'download' but does not explain whether this is a read-only operation, whether it writes to the output_path (though that is implied by the parameter), what happens if the attachment is missing, or any side effects. The agent gets no insight into the tool's actual runtime behavior.
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, clear sentence that earns its place. It is not bloated, but it also lacks any additional structure or useful detail. For such a simple tool, the brevity is acceptable, though it could have included more information without losing conciseness.
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 absence of annotations and an output schema, the description is insufficient for an agent to fully understand the tool's behavior. It does not explain what the tool returns (file content, success message, etc.), whether it creates directories for the output_path, or how errors are reported. The tool is simple, but the description leaves too much to imagination.
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 100% with basic descriptions like 'Page ID' and 'Attachment ID'. The tool description adds no additional meaning beyond the schema. Since the schema already documents all three parameters adequately, a baseline score of 3 is appropriate; the description does not compensate or enrich the parameter understanding.
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 'Download a Confluence attachment' uses a specific verb and resource, clearly distinguishing it from sibling tools like get_attachments (which likely lists attachments) and upload_attachment (which uploads). It directly states the action and object, making the purpose 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as needing the page_id and attachment_id obtained via get_attachments, nor does it contrast with other tools. The description leaves the agent to infer usage from the operation name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get attachments from a Confluence page
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Page ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior on its own. It only says 'Get attachments' without clarifying whether it returns metadata or file content, whether pagination applies, or what side effects (if any) exist. The read-only nature is implied but not explicitly stated.
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 unnecessary words. It is front-loaded with the action and resource, making it efficient 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?
The tool is simple with one parameter, but the description leaves ambiguity about the return value (metadata vs. file content) given the sibling tool download_attachment. With no output schema and no annotations, the description is adequate but not fully complete for a user to anticipate the tool's behavior.
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 input schema already provides a description for page_id ('Page ID') with 100% coverage. The description adds no additional meaning or format details beyond the schema, so a baseline 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 action ('Get') and resource ('attachments from a Confluence page'), making the tool's purpose understandable. It does not explicitly distinguish from sibling tools like download_attachment, but the verb and naming provide a reasonable distinction.
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 gives no guidance on when to use this tool versus alternatives such as download_attachment or get_page. It does not mention any prerequisites, intended scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments from a Confluence page
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| start | No | Start index for pagination | |
| page_id | Yes | Page ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. However, it only states 'get comments' without explaining pagination behavior, return format, ordering, or whether all comment types are returned. This lacks essential context for a tool that likely supports pagination via limit and start parameters.
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 and efficient, though extremely brief. It earns its place but does not provide additional detail that would enhance structure.
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 has no annotations and no output schema, so the description should compensate by explaining return values and behavioral nuances. It does not mention what the response looks like, whether pagination is required, or any filtering options. The schema provides parameter details but not sufficient contextual completeness for an agent to understand tool output and usage fully.
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 input schema covers all three parameters (page_id, limit, start) with descriptions, achieving 100% schema coverage. The description itself adds no parameter-specific semantics, so the baseline of 3 applies.
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 comments from a Confluence page, using a specific verb and resource. It is distinct from sibling tools like get_page or get_page_children, which focus on page content and hierarchy, not comments.
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 such as search or get_page. There is no mention of scenarios where this tool is appropriate or not, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Confluence page content
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Page ID | |
| include_body | No | Include page body content |
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. 'Get Confluence page content' only states the basic read operation and implies nothing about the return format, the effect of include_body, or any other behavioral nuances. It adds no transparency beyond the tool's name.
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 sentence with zero fluff, which is very concise. However, its brevity borders on under-specification, sacrificing useful detail. It is well-structured and front-loaded, but lacks the informative value that would earn a 5.
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 there is no output schema and no annotations, the description is not complete enough. It doesn't explain what the response contains, how include_body changes the result, or what edge cases exist. The presence of sibling tools for related operations makes the lack of usage context more noticeable.
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 100%: both page_id and include_body have meaningful descriptions. The tool description itself adds no parameter-level meaning, but the schema already documents the parameters, so a baseline 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 uses a specific verb+resource ('Get Confluence page content') that clearly identifies the tool. It distinguishes from siblings like get_page_children and get_attachments, though it doesn't explicitly state what 'content' excludes. It is clear but not as rich as a fully differentiating description.
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. There is no mention of using it for full page retrieval, nor any indication of when to prefer search or get_page_children. The agent receives no context about which scenario this tool addresses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get child pages of a Confluence page
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| start | No | Start index for pagination | |
| parent_id | Yes | Parent page ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action ('Get child pages') and reveals nothing about pagination behavior, permissions, ordering, or return format. This is a minimal statement with no additional 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 a single, front-loaded sentence with zero wasted words. It efficiently conveys the purpose without redundancy.
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?
This is a simple read tool with fully documented parameters, making the description minimally adequate for invocation. However, there is no output schema and no behavioral context, so the description does not fully compensate for the lack of annotations. It is viable but leaves gaps for the agent.
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 input schema has 100% parameter description coverage, so the schema already documents each parameter (limit, start, parent_id). The description adds no extra semantics beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('child pages of a Confluence page'), which distinguishes it from sibling tools like get_page and search.
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 vs alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool might be more appropriate, leaving the agent to infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Confluence content
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| query | Yes | Search query (CQL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Search Confluence content' only implies a read operation. It does not disclose what is returned, pagination behavior, whether results are limited to pages, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately sized for its limited content, though it could benefit from additional information without losing conciseness.
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 lacks an output schema and annotations, and the one-line description does not clarify what 'Confluence content' includes (e.g., pages, attachments, comments) or how to effectively compose CQL queries. This leaves significant ambiguity for agent decision-making, making the description incomplete for the tool's complexity.
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 input schema provides 100% coverage for both parameters (query as CQL and limit as maximum results), so the description does not need to add parameter details. However, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' with the resource 'Confluence content', clearly distinguishing it from sibling tools like get_page and create_page. It is unambiguous and immediately conveys the tool's core function.
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 search versus alternative tools such as get_page or get_attachments. It lacks explicit context like 'use this to find pages by query' or any exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a Confluence page with new content.
IMPORTANT: For large HTML files, use 'content_file' parameter to provide the file path. The tool automatically handles:
Escaping unescaped & characters to &
Cleaning HTML structure (removes DOCTYPE, html, head, body tags)
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title (optional, keeps existing if not provided) | |
| content | No | New content HTML (provide either 'content' or 'content_file', not both) | |
| page_id | Yes | Page ID | |
| minor_edit | No | Mark as minor edit | |
| content_file | No | Absolute path to HTML file (alternative to 'content', recommended for large files). Must be an absolute path like /Users/xxx/file.html |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses automatic behaviors (escaping & characters, cleaning HTML structure) and notes the large-file path recommendation. This goes beyond a simple 'update' statement, though it omits details on permissions or return values.
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 concise and front-loaded with the main purpose. The IMPORTANT note and bulleted list are well-structured with no redundant 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 mutation tool with no output schema, it lacks explicit mention of what the tool returns (e.g., success status, updated page object) and potential errors. It covers the core usage and automatic behaviors, but not all operational aspects.
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 coverage is 100%, so the baseline is 3. The description adds marginal value by recommending content_file for large files and clarifying automatic HTML handling, but does not significantly expand on the schema 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 Confluence page' with a specific resource. It distinguishes itself from sibling tools like create_page and get_page by the verb 'update'.
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 clear context that this tool updates existing pages, and adds practical guidance on using content_file for large files. It does not explicitly mention when not to use it or alternatives, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file as an attachment to a Confluence page. The file must be specified by its absolute path on the local filesystem. Optionally embed the attachment in the page body.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Optional comment for the attachment | |
| page_id | Yes | The Confluence page ID to attach the file to | |
| file_path | Yes | Absolute path to the file to upload | |
| embed_in_body | No | If true, append the attachment reference to the page body after upload. Images will be embedded as <ac:image>, other files as download links. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the requirement for an absolute local path and the optional side-effect of embedding the attachment in the body. However, it omits other behavioral details such as permissions, overwrite behavior, limits, or response format.
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 two concise sentences, front-loaded with the core purpose and immediately followed by a key constraint and optional behavior. No filler or redundant 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?
The description covers the basic purpose and key constraint, and the schema fully defines parameters. However, with no output schema and no annotations, there is no information about return values, errors, or permission requirements, leaving the full context incomplete for an unattended agent.
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 100%, so the schema already documents all parameters. The description adds no meaning beyond the schema—it only repeats the absolute path requirement and embed option, which are already in the property 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: 'Upload a file as an attachment to a Confluence page.' It identifies the resource (Confluence page attachment) and distinguishes from siblings like get_attachments and download_attachment. The optional embed behavior is also mentioned.
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 when to use by stating an upload action, but it does not explicitly contrast with alternatives or state prerequisites. An agent can infer it is for adding attachments rather than retrieving them, but no exclusion guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action: search, page retrieval, children, attachments (list vs download), comments (list vs add), page create/update, and attachment upload. No two tools appear to do the same thing.
Most names follow a clear verb_noun pattern (get_page, create_page, update_page, upload_attachment). The mix of verbs like search, get, download, add, create, update, upload is reasonable and readable, though not perfectly uniform.
With 10 tools, the set is well-scoped for a Confluence MCP server covering search, page content, comments, and attachments. Each tool has a clear role without feeling excessive.
Core content operations are covered (search, read, create, update, comment, attachments), but there are no delete operations for pages, comments, or attachments. This is a notable gap for full lifecycle management, though typical workflows are still possible.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect to Atlassian Jira, Confluence, and Compass to search, create, and manage your work.
Confluence MCP — wraps the Confluence Cloud REST API v2 (OAuth)
Connect to your MediaWiki using simple credentials and manage content without OAuth. Search, read,…
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucaszzz1202/confluence_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server