Provides tools to search and fetch pages from a Confluence (Atlassian) instance, enabling AI assistants to query and read Confluence content in real time.
Provides tools to search and fetch pages from a Confluence instance, enabling AI assistants to query and read Confluence content in real time.
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-server search for recent design docs in the ENG 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.
An MCP (Model Context Protocol) server that connects AI assistants to your Confluence instance. It exposes two tools — search and fetch — letting any MCP-compatible client (Claude Desktop, Cursor, Windsurf, etc.) query and read Confluence pages in real time.
🔍 Fuzzy search — splits multi-word queries into parallel CQL searches and merges results by relevance
📄 Full page hydration — retrieves storage body, version info, labels, and ancestors as clean Markdown
⚡ Disk cache — search and content responses are cached locally to reduce API load
🔒 Read-only — all tools are annotated readOnlyHint: true; nothing is ever written to Confluence
🐳 Docker-ready — one-command deployment via deploy_confluence_mcp.py
Related MCP server: finviet-confluence-mcp
Python 3.11+ and uv or Docker
A Confluence instance accessible over HTTP(S)
cp .env.example .envEdit .env:
CONFLUENCE_URL=https://confluence.example.com
CONFLUENCE_PERSONAL_ACCESS_TOKEN=your_token_hereuv sync
uv run python -m confluence_search.fastmcp_apppython deploy_confluence_mcp.py # builds image + starts container on :43043Or manually:
docker build -t confluence-mcp-server .
docker run -d --name confluence-mcp-server \
--env-file .env \
-p 43043:43043 \
confluence-mcp-serverAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"confluence": {
"command": "uv",
"args": ["run", "python", "-m", "confluence_search.fastmcp_app"],
"cwd": "/path/to/confluence-mcp-server",
"env": {
"CONFLUENCE_URL": "https://confluence.example.com",
"CONFLUENCE_PERSONAL_ACCESS_TOKEN": "your_token_here"
}
}
}
}Point your MCP client at http://127.0.0.1:43043/mcp after starting the Docker container.
search_confluenceExecute a CQL search against Confluence.
Parameter | Type | Default | Description |
| string | required | Natural language query (translated to CQL) |
| int (1–25) |
| Maximum results to return |
| string[] |
| Filter by space keys (e.g. |
| string[] |
| Filter by page labels |
| bool |
| Search titles only (faster, lower recall) |
| bool |
| Parallel term-split search for better recall |
| string |
| Recency filter. Shorthands: |
| string |
| Filter by creation date (same format) |
Returns a ranked list of matching pages with title, URL, space, excerpt, and matched labels.
fetch_confluence_pageHydrate a single page by its Confluence content ID.
Parameter | Type | Description |
| string | Numeric content ID returned by |
Returns the page as a Markdown document including metadata header (URL, space, version, last-modified date, labels, ancestor breadcrumb) followed by the full page body.
All settings are read from environment variables or .env:
Variable | Default | Description |
| — | Base URL of your Confluence instance |
| — | Bearer token for authentication |
|
| Enforce TLS certificate validation |
|
| HTTP timeout in seconds |
|
| Retry attempts for transient failures |
|
| Enable/disable disk cache |
|
| Cache directory path |
|
| Search cache TTL (seconds) |
|
| Page content cache TTL (seconds) |
Variable | Default | Description |
|
|
|
|
| Bind address (HTTP mode) |
|
| Listen port (HTTP mode) |
uv sync
uv run pytest -m unit --cov=confluence_search/ --cov-report=term-missing
uv run ruff check confluence_search/ tests/
uv run ruff format confluence_search/ tests/The test suite requires 100% coverage — enforced in CI.
MIT
Hydrate a Confluence page’s storage body, version data, and ancestry.
| Name | Required | Description | Default |
|---|---|---|---|
| content_id | Yes | Numeric content identifier returned by Confluence search. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is not burdened with stating it is read-only. It adds useful context about what data is retrieved (storage body, version data, ancestry), but does not disclose any additional behavioral traits such as pagination, error conditions, or authentication requirements.
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?
One concise sentence with no filler. It front-loads the core action and data scope. Every word is meaningful, and the description is appropriately brief for a straightforward fetch tool.
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's simplicity, one parameter, and the presence of an output schema (which should explain return values), the description is sufficient for understanding the tool's purpose. It could be slightly more explicit about when to use it versus search_confluence, but overall it provides a complete enough picture.
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% description coverage for the single parameter (content_id), so the schema already fully explains the parameter. The description adds no additional parameter-level detail, which is acceptable given the schema's completeness.
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 specifies the action ('hydrate') and the resource (a Confluence page) with specific data components (storage body, version data, ancestry). This clearly distinguishes it from sibling search_confluence, which presumably locates pages rather than fetching full content.
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: the tool fetches a page's detailed data by content_id. However, there is no explicit guidance on when to use this instead of search_confluence, nor any mention of prerequisites or exclusions. The context of sibling tools exists but the description itself does not point to it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a highlighted CQL search via the shared Confluence orchestrator.
| Name | Required | Description | Default |
|---|---|---|---|
| fuzzy | No | Enable fuzzy search with parallel term splitting for better recall. | |
| limit | No | Maximum number of hits to return. | |
| query | Yes | Natural language query to translate into CQL. | |
| labels | No | Optional list of labels to filter. | |
| spaces | No | Optional list of space keys to filter. | |
| titles_only | No | Restrict search to titles only. | |
| created_after | No | Only return pages created after this point. Same format as modified_after. Default: no filter. | |
| modified_after | No | Only return pages modified after this point. Shorthand: '1d', '7d', '30d', '90d', '6M', '1y', '2y', '5y'. Or ISO date: '2025-01-01'. Default '2y' (last 2 years). Set to null for all time. | 2y |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is established. The description adds the fact that it performs CQL search via an orchestrator, but it does not disclose any optional behaviors like fuzzy matching, result limits, or potential side effects. These are present in the schema, but the description contributes minimal extra behavioral context beyond annotations.
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 and highly concise, with no filler. However, the phrase 'highlighted' is vague and 'shared Confluence orchestrator' may be unnecessary internal jargon, slightly detracting from clarity. Still, it is appropriately brief and front-loaded.
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 8 parameters and an output schema, the description is minimal. It does not explain what 'highlighted CQL search' means, how results are delivered, or any orchestrator-specific behaviors. The schema and annotations cover parameters and safety, but the description lacks sufficient context about the overall search workflow, making it adequate but not complete.
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 baseline is 3. The tool description adds no parameter-level detail; the schema fully defines every parameter with types, defaults, and semantics. Therefore the description does not meaningfully enhance parameter understanding beyond what the schema already provides.
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 ('Execute a ... CQL search') and the resource ('Confluence'), and it distinguishes from the sibling tool fetch_confluence_page by focusing on search. However, the term 'highlighted' is ambiguous and the phrase 'via the shared Confluence orchestrator' introduces unnecessary implementation detail that may confuse rather than clarify.
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 fetch_confluence_page. It does not state any prerequisites, exclusions, or scenarios where a different tool would be more appropriate. The only contextual hint is in the schema's query parameter description, but the tool description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and search are completely distinct operations: one retrieves a specific page by ID, the other finds pages via CQL. There is no ambiguity between the two.
Both names follow a verb_prefix pattern in snake_case, but 'fetch_confluence_page' includes an extra object while 'search_confluence' does not. This is a minor inconsistency, but still predictable.
Only two tools for a Confluence server feels too thin. A typical integration requires at least page creation, updates, and space management, not just fetch and search.
The server covers only read-oriented operations (fetch a page, search) and lacks all write capabilities such as create, update, delete, or list spaces. This is a significant gap for a domain like Confluence.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
An MCP server that integrates with Discord to provide AI-powered features.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pankaj28843/confluence-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
