A
licenseA
qualityC
maintenanceA Model Context Protocol server that enables AI assistants like Claude to access and search Atlassian Confluence content, allowing integration with your organization's knowledge base.
5
7,081
61
ISC
Confluence MCP
by cosmix
The Confluence MCP server enables AI assistants to interact with Confluence content programmatically through a standardized interface. With this server, you can:
Authenticate to Confluence using a personal API token
Retrieve specific pages by ID and search using CQL (Confluence Query Language)
List all available spaces
Create new pages (including child pages) and update existing content
Retrieve and add comments, including threaded replies
Retrieve and add attachments using base64 encoded content
Clean and transform Confluence content for AI consumption
Benefit from built-in API communication, error handling, and data transformation
Protection through basic rate limiting to prevent API abuse
Enables retrieving, searching, creating, and updating Confluence pages and spaces, as well as handling content transformation for AI consumption.
Referenced as a separate MCP server available from another repository, indicating integration capabilities with Jira.
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 MCPsearch for pages about API documentation 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.
Confluence MCP
A Model Context Protocol (MCP) server for Confluence, enabling AI assistants to interact with Confluence content through a standardized interface.
ℹ️ There is a separate MCP server for Jira
Features
Authenticate to Confluence using a personal API token
Retrieve and search Confluence pages and spaces
Create and update Confluence content
Retrieve and add comments to pages
Retrieve and add attachments to pages
Clean and transform Confluence content for AI consumption
Handle API communication, error handling, and data transformation
Basic rate limiting to prevent API abuse
Related MCP server: Confluence MCP Server
Prerequisites
Bun (v1.0.0 or higher)
Confluence account with API access
Installation
# Clone the repository
git clone https://github.com/cosmix/confluence-mcp.git
cd confluence-mcp
# Install dependencies
bun install
# Build the project
bun run buildConfiguration
To use this MCP server, you need to set the following environment variables:
CONFLUENCE_API_TOKEN=your_api_token
CONFLUENCE_BASE_URL=your_confluence_instance_url # e.g., https://your-domain.atlassian.net/wiki
CONFLUENCE_USER_EMAIL=your_emailClaude Desktop / Cline Configuration
Add this configuration to your settings file:
{
"mcpServers": {
"confluence": {
"command": "bun",
"args": ["/absolute/path/to/confluence-mcp/dist/index.js"],
"env": {
"CONFLUENCE_API_TOKEN": "your_api_token",
"CONFLUENCE_BASE_URL": "your_confluence_instance_url/wiki",
"CONFLUENCE_USER_EMAIL": "your_email"
}
}
}
}Development
# Run in development mode
bun run dev
# Run tests
bun testAvailable Tools
The Confluence MCP server exposes the following tools:
get_page
Retrieve a Confluence page by ID. Format refers to the return format of the content and can be text or markdown. The includeMarkup parameter allows retrieving the original Confluence Storage Format (XHTML) markup, which is useful for updating pages while preserving formatting.
{
"pageId": "123456",
"format": "text",
"includeMarkup": true
}search_pages
Search for Confluence pages using CQL (Confluence Query Language). Format refers to the return format of the content and can be text or markdown. The includeMarkup parameter allows retrieving the original Confluence Storage Format (XHTML) markup for each page.
{
"query": "space = DEV and label = documentation",
"limit": 10,
"format": "text",
"includeMarkup": true
}get_spaces
List all available Confluence spaces.
{
"limit": 50
}create_page
Create a new Confluence page. The parentId is optional and can be used to create a child page under an existing page.
{
"spaceKey": "DEV",
"title": "New Page Title",
"content": "<p>Page content in Confluence Storage Format (XHTML)</p>",
"parentId": "123456"
}update_page
Update an existing Confluence page.
{
"pageId": "123456",
"title": "Updated Page Title",
"content": "<p>Updated content in Confluence Storage Format (XHTML)</p>",
"version": 1
}get_comments
Retrieve comments for a specific Confluence page. Format refers to the return format of the content and can be text or markdown.
{
"pageId": "123456",
"limit": 25,
"format": "text"
}add_comment
Add a comment to a Confluence page. The parentId is optional for creating threaded replies.
{
"pageId": "123456",
"content": "<p>This is a new comment.</p>",
"parentId": "789012"
}get_attachments
Retrieve attachments for a specific Confluence page.
{
"pageId": "123456",
"limit": 25
}add_attachment
Add an attachment to a Confluence page. The fileContentBase64 should be the base64 encoded string of the file content.
{
"pageId": "123456",
"filename": "document.pdf",
"fileContentBase64": "JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFI+P...",
"comment": "Uploaded new version of the document"
}LICENCE
This project is licensed under the MIT License - see the LICENCE file for details.
Available Tools
9 toolsadd_attachmentC
Add an attachment to a Confluence page
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ID of the page to attach the file to | |
| comment | No | Optional comment for the attachment version | |
| filename | Yes | Desired filename for the attachment | |
| fileContentBase64 | Yes | Base64 encoded content of the file |
TDQS
C2.9/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as required permissions, error handling, file size limits, or side effects. The burden is on the description, and it fails to provide this context.
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 with no waste. However, it may be too brief for a tool with four parameters, but it earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema or annotations, the description is minimally adequate but omits important contextual details like permissions, file size limits, or behavior on duplicate filenames.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, so baseline 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 'Add an attachment to a Confluence page' uses a specific verb ('Add') and resource ('attachment to a Confluence page'), which clearly distinguishes it from sibling tools like 'add_comment' or 'create_page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_attachments' for reading), nor any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_commentB
Add a comment to a Confluence page
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ID of the page to add the comment to | |
| content | Yes | Comment content in Confluence Storage Format (XHTML) | |
| parentId | No | Optional ID of the parent comment for threading |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Add a comment' but omits details such as required permissions, whether comments are appended or inserted, or if any side effects occur. This is insufficient for a mutation tool.
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 with no wasted words. However, it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what happens upon successful comment creation, error conditions, or return values. It falls short, making it incomplete for safe agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all parameters. The description adds no additional meaning beyond 'Add a comment', so it meets the baseline for high coverage.
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 uses the verb 'Add' and the resource 'comment to a Confluence page', which differentiates it from sibling tools like add_attachment or create_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_comments or update_page is provided. The description lacks any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_pageC
Create a new Confluence page
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the new page | |
| content | Yes | Content of the page in Confluence Storage Format (XHTML) | |
| parentId | No | Optional ID of the parent page | |
| spaceKey | Yes | Key of the space where the page will be created |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'create', implying a write operation, but omits details about permissions, content validation, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but somewhat under-specified. One sentence is appropriate for the purpose, but it could include more key details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is too sparse. It does not explain return values, error conditions, or relationships between parameters.
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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema, but it does not repeat or contradict it.
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 'Create a new Confluence page' clearly states the verb and resource, distinguishing it from tools like update_page. However, it could be more specific about the scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_page or add_attachment. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_attachmentsB
Retrieve attachments for a specific Confluence page
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of attachments to return (default: 25) | |
| pageId | Yes | ID of the page to retrieve attachments for |
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It lacks detail on pagination, error handling, permissions, or what happens if the page does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, but lacks necessary detail for a complete understanding. It is concise but under-specified.
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 simple retrieval tool, the description is minimal. No mention of output format, pagination, or behavior with missing pages. Could be more complete given lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described. The description adds no additional meaning beyond the schema, so baseline 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 action (retrieve) and resource (attachments for a specific Confluence page). It distinguishes from siblings like add_attachment (write) and get_comments (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to use get_page or other retrieval tools. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_commentsA
Retrieve comments for a specific Confluence page
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of comments to return (default: 25) | |
| format | No | Format to return comment content in (default: text) | |
| pageId | Yes | ID of the page to retrieve comments for |
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states 'retrieve', which is minimally transparent; it omits details like pagination, error scenarios, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Efficient and to the point.
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?
While the tool is simple with 3 parameters and no output schema, the description does not explain the return format or pagination behavior, which is relevant for 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?
Schema covers all 3 parameters (100% coverage). The description adds no additional meaning beyond the schema, so baseline 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 verb 'Retrieve' and the resource 'comments for a specific Confluence page', distinguishing it from sibling tools like add_comment or get_page.
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 implies when to use (when comments are needed), but does not explicitly mention when not to use or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pageB
Retrieve a Confluence page by ID
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format to return the content in (default: text) | |
| pageId | Yes | ID of the Confluence page to retrieve | |
| includeMarkup | No | Whether to include the original Confluence Storage Format (XHTML) markup in the response (default: false). Useful when you want to update the page later in order to preserve formatting. |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose any behavioral traits beyond the basic function. It omits details on authentication, error handling, or what happens when the page ID 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence without unnecessary words. It could be slightly more detailed without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too minimal. It does not explain the return format, error scenarios, or provide enough context for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself documents all parameters. The description adds the phrase 'by ID', which is already implied by the required 'pageId' parameter. No additional semantic value.
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 verb 'Retrieve' and the resource 'Confluence page by ID', which is specific and distinguishes it from sibling tools like create_page or update_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as search_pages. There is no mention of exclusions or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_spacesC
List all available Confluence spaces
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of spaces to return (default: 50) |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'list all available', but does not disclose pagination behavior, rate limits, or what 'available' means (e.g., excludes archived spaces). No behavioral traits beyond the bare operation are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of completeness. It could include more detail without becoming verbose, so it is adequate but not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or sibling context in the description, the tool is under-documented. It lacks details about space ordering, filtering, or response structure, making it less complete than expected for a list-all operation.
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 coverage is 100% with one parameter 'limit'. The description adds the default value (50) not present in the schema, providing useful context. However, it does not elaborate on the parameter's effect beyond the schema's description.
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 'List all available Confluence spaces' clearly states the verb 'list' and the resource 'spaces', making the tool's purpose unambiguous. It differentiates from sibling tools like get_page (single page) and search_pages (search) by focusing on listing all spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as search_pages or get_page. It merely states the listing action without context on limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_pagesA
Search for Confluence pages using CQL (Confluence Query Language): query := expression [operator expression]* expression := field | function() | function | "phrase" | term operator := AND | OR | NOT | space field := date | after | before | during | lastmodified | modifiedafter | modifiedbefore | creator | from | to | content | title | body | subject | filename function() := now() | today() | yesterday() | this_week() | last_week() | this_month() | last_month() | this_year() | last_year() function := has | is | is | is | label | type | in value := string | quoted_string | date_format date_format := YYYY-MM-DD | YYYY-MM | YYYY quoted_string := "string with spaces" term := alphanumeric_string
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | CQL search query | |
| format | No | Format to return the content in (default: text) | |
| includeMarkup | No | Whether to include the original Confluence Storage Format (XHTML) markup in the response (default: false) |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. While it details the CQL syntax, it fails to disclose behavioral traits such as pagination behavior beyond the limit parameter, error handling, rate limits, or what fields are returned in search results. Critical gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose but becomes lengthy due to the detailed CQL grammar. While thorough, it could be more concise by referencing external documentation. It maintains structure with a pseudo-BNF format, but the length may hinder quick parsing by an AI agent.
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 description thoroughly covers the CQL syntax, meeting the tool's primary complexity. However, it omits essential contextual details such as output format, result structure, error handling, and authentication requirements. Without an output schema, these omissions reduce completeness for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters. The description adds significant value for the query parameter by providing a full CQL grammar, enabling the agent to construct complex queries. Other parameters are adequately described in the schema, so the net addition is meaningful but not transformative.
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 'Search for Confluence pages using CQL', specifying the verb (search) and resource (Confluence pages) with a distinct method (CQL). This differentiates it from sibling tools like get_page (single page retrieval) or get_spaces.
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 via CQL search but does not explicitly define when to use this tool over siblings. It lacks guidance on alternatives or when not to use it, though the CQL focus makes the context moderately clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_pageB
Update an existing Confluence page
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | New title of the page | |
| pageId | Yes | ID of the page to update | |
| content | Yes | New content in Confluence Storage Format (XHTML). CRITICAL: Content MUST be valid XHTML. Providing plain text or Markdown will result in the markup being displayed literally, not rendered as rich text. | |
| version | Yes | Current version number of the page |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states 'update an existing page'. It omits critical details like optimistic locking via version number, required permissions, or error conditions (e.g., wrong version, access denied).
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 efficiently states the core purpose. While it lacks additional context, it is front-loaded and wastes no words. A slight expansion for guidelines would improve it without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters and no output schema, the description should explain return values, conflict resolution, and how to determine success. It does not, and it offers no differentiation from sibling tools like add_comment or add_attachment.
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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, which already has detailed parameter descriptions (e.g., content must be XHTML). No extra value from the description.
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 'Update an existing Confluence page' clearly states the verb (update) and resource (existing Confluence page). It distinguishes from sibling tools like create_page, which creates new pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_page or get_page. There is no mention of prerequisites like the need for the correct version number or concurrency handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.5/5.0
Disambiguation5/5
Each tool targets a distinct resource (page, comment, attachment, space) and action (create, get, update, list, search, add), with no overlap in purpose.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case, such as create_page, get_spaces, search_pages, making them predictable.
Tool Count5/5
9 tools is well-scoped for a Confluence integration, covering essential operations without being overwhelming or sparse.
Completeness4/5
The tool set covers most core workflows for pages, attachments, comments, and search, but lacks deletion operations (e.g., delete_page) and update/delete for comments and attachments.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Related MCP Servers
- FlicenseBqualityDmaintenanceA Model Context Protocol server that provides secure access to Atlassian Confluence, allowing users to search, create, update, and manage Confluence pages and spaces through natural language commands.10192
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol server that integrates with Atlassian Confluence and Jira, enabling AI assistants to search, create, and update content in these platforms through natural language interactions.1MIT
- -licenseNot gradedqualityNot gradedmaintenanceA Model Context Protocol server that enables interaction with Atlassian products (Confluence and Jira), supporting both Cloud and Server/Data Center deployments for searching, creating, and managing content through natural language.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/cosmix/confluence-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server