Skip to main content
Glama
deenesjakoruzh
aashari

Atlassian Confluence MCP Server

by aashari
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Connect AI to Your Confluence Knowledge Base

Transform how you access and interact with your team's knowledge by connecting Claude, Cursor AI, and other AI assistants directly to your Confluence spaces, pages, and documentation. Get instant answers from your knowledge base, search across all your spaces, and streamline your documentation workflow.

NPM Version

What You Can Do

  • Ask AI about your documentation: "What's our API authentication process?"

  • Search across all spaces: "Find all pages about security best practices"

  • Get instant answers: "Show me the latest release notes from the Product space"

  • Access team knowledge: "What are our HR policies for remote work?"

  • Review page comments: "Show me the discussion on the architecture document"

  • Create and update content: "Create a new page in the DEV space"

Related MCP server: MCP Atlassian Server

Perfect For

  • Developers who need quick access to technical documentation and API guides

  • Product Managers searching for requirements, specs, and project updates

  • HR Teams accessing policy documents and employee resources quickly

  • Support Teams finding troubleshooting guides and knowledge base articles

  • Anyone who wants to interact with Confluence using natural language

Quick Start

Get up and running in 2 minutes:

1. Get Your Confluence Credentials

Generate a Confluence API Token:

  1. Go to Atlassian API Tokens

  2. Click Create API token

  3. Give it a name like "AI Assistant"

  4. Copy the generated token immediately (you won't see it again!)

2. Try It Instantly

# Set your credentials
export ATLASSIAN_SITE_NAME="your-company"  # for your-company.atlassian.net
export ATLASSIAN_USER_EMAIL="your.email@company.com"
export ATLASSIAN_API_TOKEN="your_api_token"

# List your Confluence spaces (TOON format by default)
npx -y @aashari/mcp-server-atlassian-confluence get --path "/wiki/api/v2/spaces"

# Get details about a specific space with field filtering
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/spaces/123456" \
  --jq "{id: id, key: key, name: name, type: type}"

# Get a page with JMESPath filtering
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/pages/789" \
  --jq "{id: id, title: title, status: status}"

# Search for pages (using CQL)
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/rest/api/search" \
  --query-params '{"cql": "type=page AND space=DEV"}'

Connect to AI Assistants

For Claude Desktop Users

Add this to your Claude configuration file (~/.claude/claude_desktop_config.json):

{
  "mcpServers": {
    "confluence": {
      "command": "npx",
      "args": ["-y", "@aashari/mcp-server-atlassian-confluence"],
      "env": {
        "ATLASSIAN_SITE_NAME": "your-company",
        "ATLASSIAN_USER_EMAIL": "your.email@company.com",
        "ATLASSIAN_API_TOKEN": "your_api_token"
      }
    }
  }
}

Restart Claude Desktop, and you'll see the confluence server in the status bar.

For Other AI Assistants

Most AI assistants support MCP (Cursor AI, Continue.dev, and others). Install the server globally:

npm install -g @aashari/mcp-server-atlassian-confluence

Then configure your AI assistant to use the MCP server with STDIO transport. The binary is available as mcp-atlassian-confluence after global installation.

Alternative: Configuration File

Create ~/.mcp/configs.json for system-wide configuration:

{
  "confluence": {
    "environments": {
      "ATLASSIAN_SITE_NAME": "your-company",
      "ATLASSIAN_USER_EMAIL": "your.email@company.com",
      "ATLASSIAN_API_TOKEN": "your_api_token"
    }
  }
}

Alternative config keys: The system also accepts "atlassian-confluence", "@aashari/mcp-server-atlassian-confluence", or "mcp-server-atlassian-confluence" instead of "confluence".

Using Environment Variables

You can also configure credentials using environment variables or a .env file:

# Create a .env file in your project directory
cat > .env << EOF
ATLASSIAN_SITE_NAME=your-company
ATLASSIAN_USER_EMAIL=your.email@company.com
ATLASSIAN_API_TOKEN=your_api_token
DEBUG=false
EOF

The server will automatically load these values from:

  1. Environment variables

  2. .env file in the current directory

  3. ~/.mcp/configs.json (as shown above)

Available Tools

This MCP server provides 5 generic tools that can access any Confluence API endpoint:

Tool

Description

conf_get

GET any Confluence API endpoint (read data)

conf_post

POST to any endpoint (create resources)

conf_put

PUT to any endpoint (replace resources)

conf_patch

PATCH to any endpoint (partial updates)

conf_delete

DELETE from any endpoint (remove resources)

Tool Parameters

All tools share these common parameters:

  • path (required): The API endpoint path (e.g., /wiki/api/v2/spaces)

  • queryParams (optional): Query parameters as key-value pairs (e.g., {"limit": "25", "space-id": "123"})

  • jq (optional): JMESPath expression to filter/transform the response (e.g., results[*].{id: id, title: title})

  • outputFormat (optional): Output format - "toon" (default, 30-60% fewer tokens) or "json"

Tools that accept a request body (conf_post, conf_put, conf_patch):

  • body (required): Request body as a JSON object

Common API Paths

Spaces:

  • /wiki/api/v2/spaces - List all spaces

  • /wiki/api/v2/spaces/{id} - Get space details

Pages:

  • /wiki/api/v2/pages - List pages (use space-id query param to filter)

  • /wiki/api/v2/pages/{id} - Get page details

  • /wiki/api/v2/pages/{id}/body - Get page body (use body-format param)

  • /wiki/api/v2/pages/{id}/children - Get child pages

  • /wiki/api/v2/pages/{id}/labels - Get page labels

Comments:

  • /wiki/api/v2/pages/{id}/footer-comments - List/add footer comments

  • /wiki/api/v2/pages/{id}/inline-comments - List/add inline comments

  • /wiki/api/v2/footer-comments/{comment-id} - Get/update/delete comment

Blog Posts:

  • /wiki/api/v2/blogposts - List blog posts

  • /wiki/api/v2/blogposts/{id} - Get blog post

Search:

  • /wiki/rest/api/search - Search content (use cql query param)

TOON Output Format

What is TOON? TOON (Token-Oriented Object Notation) is a format optimized for LLM token efficiency, reducing token costs by 30-60% compared to JSON. It's the default output format for all tools.

Benefits:

  • Tabular arrays use fewer tokens than JSON arrays

  • Minimal syntax overhead (no quotes, brackets, commas where unnecessary)

  • Still human-readable and parseable

When to use JSON instead:

  • When you need standard JSON for other tools

  • When debugging or manual inspection is needed

Example comparison:

// JSON format (verbose)
{"results": [{"id": "123", "title": "My Page"}, {"id": "456", "title": "Other Page"}]}

// TOON format (efficient)
results:
  - id: 123
    title: My Page
  - id: 456
    title: Other Page

To use JSON instead of TOON, set outputFormat: "json" in your request.

JMESPath Filtering

All tools support optional JMESPath (jq) filtering to extract specific data and reduce token costs:

# Get just space names and keys
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/spaces" \
  --jq "results[].{id: id, key: key, name: name}"

# Get page title and status
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/pages/123456" \
  --jq "{id: id, title: title, status: status}"

IMPORTANT: Always use the jq parameter to filter responses to only the fields you need. Unfiltered responses can be very large and expensive in token costs.

JMESPath Syntax Reference:

  • Official docs: jmespath.org

  • Common patterns:

    • results[*] - All items in results array

    • results[0] - First item only

    • results[*].id - Just IDs from all items

    • results[*].{id: id, title: title} - Create objects with selected fields

    • results[?status=='current'] - Filter by condition

Real-World Examples

Explore Your Knowledge Base

Ask your AI assistant:

  • "List all the spaces in our Confluence"

  • "Show me details about the Engineering space"

  • "What pages are in our Product space?"

  • "Find the latest pages in the Marketing space"

Search and Find Information

Ask your AI assistant:

  • "Search for pages about API authentication"

  • "Find all documentation with 'security' in the title"

  • "Show me pages labeled with 'getting-started'"

  • "Search for content in the DEV space about deployment"

Access Specific Content

Ask your AI assistant:

  • "Get the content of the API Authentication Guide page"

  • "Show me the onboarding checklist document"

  • "What's in our security policies page?"

  • "Display the latest release notes"

Create and Update Content

Ask your AI assistant:

  • "Create a new page in the DEV space titled 'API Guide'"

  • "Add a comment to the architecture document"

  • "Update the page content with the new release info"

CLI Commands

The CLI mirrors the MCP tools for direct terminal access. All commands support the same parameters as the tools.

Available Commands

  • get - GET any Confluence endpoint

  • post - POST to any endpoint

  • put - PUT to any endpoint

  • patch - PATCH any endpoint

  • delete - DELETE from any endpoint

CLI Parameters

All commands:

  • -p, --path <path> (required) - API endpoint path

  • -q, --query-params <json> (optional) - Query parameters as JSON

  • --jq <expression> (optional) - JMESPath filter expression

  • -o, --output-format <format> (optional) - Output format: toon (default) or json

Commands with body (post, put, patch):

  • -b, --body <json> (required) - Request body as JSON

Examples

# GET request
npx -y @aashari/mcp-server-atlassian-confluence get --path "/wiki/api/v2/spaces"

# GET with query parameters and JMESPath filter
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/pages" \
  --query-params '{"space-id": "123456", "limit": "10"}' \
  --jq "results[*].{id: id, title: title}"

# GET with JSON output format
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/spaces" \
  --output-format json

# POST request (create a page)
npx -y @aashari/mcp-server-atlassian-confluence post \
  --path "/wiki/api/v2/pages" \
  --body '{"spaceId": "123456", "status": "current", "title": "New Page", "body": {"representation": "storage", "value": "<p>Content here</p>"}}'

# POST request (add a comment)
npx -y @aashari/mcp-server-atlassian-confluence post \
  --path "/wiki/api/v2/pages/789/footer-comments" \
  --body '{"body": {"representation": "storage", "value": "<p>My comment</p>"}}'

# PUT request (update page - requires version increment)
npx -y @aashari/mcp-server-atlassian-confluence put \
  --path "/wiki/api/v2/pages/789" \
  --body '{"id": "789", "status": "current", "title": "Updated Title", "spaceId": "123456", "body": {"representation": "storage", "value": "<p>Updated content</p>"}, "version": {"number": 2}}'

# PATCH request (partial update)
npx -y @aashari/mcp-server-atlassian-confluence patch \
  --path "/wiki/api/v2/spaces/123456" \
  --body '{"name": "New Space Name"}'

# DELETE request
npx -y @aashari/mcp-server-atlassian-confluence delete \
  --path "/wiki/api/v2/pages/789"

Response Handling

Large Response Truncation

When API responses exceed approximately 40,000 characters (~10,000 tokens), the server automatically truncates the response to stay within token limits. When this happens:

  1. You'll see a truncation notice at the end of the response showing:

    • How much of the original response is shown

    • The original response size

    • Guidance on accessing the full data

  2. The full raw response is saved to a temporary file in /tmp/mcp/ (path provided in the truncation notice)

  3. Best practices to avoid truncation:

    • Always use the jq parameter to filter responses to only needed fields

    • Use limit query parameter to restrict result counts (e.g., {"limit": "5"})

    • Request specific resources by ID rather than listing all

    • Use targeted CQL queries for searches

Example of efficient filtering:

# Instead of getting all space data (can be huge):
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/spaces"

# Get only the fields you need:
npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/api/v2/spaces" \
  --query-params '{"limit": "10"}' \
  --jq "results[*].{id: id, key: key, name: name}"

Debug Logging

Enable debug logging to see detailed request/response information:

# Set DEBUG environment variable
export DEBUG=true

# For MCP mode
DEBUG=true npx -y @aashari/mcp-server-atlassian-confluence

# For CLI mode
DEBUG=true npx -y @aashari/mcp-server-atlassian-confluence get --path "/wiki/api/v2/spaces"

Debug logs are written to: ~/.mcp/data/@aashari-mcp-server-atlassian-confluence.[session-id].log

Testing & Development

Using MCP Inspector

The MCP Inspector provides a visual interface for testing tools:

# Install the server globally
npm install -g @aashari/mcp-server-atlassian-confluence

# Run with MCP Inspector
npx @modelcontextprotocol/inspector node $(which mcp-atlassian-confluence)

Or use the built-in development command if you've cloned the repository:

npm run mcp:inspect

This starts the server in HTTP mode and opens the inspector UI in your browser.

HTTP Mode for Testing

You can run the server in HTTP mode to test with curl or other HTTP clients:

# Start server in HTTP mode
TRANSPORT_MODE=http npx -y @aashari/mcp-server-atlassian-confluence

The server will listen on http://localhost:3000/mcp by default. You can change the port:

PORT=8080 TRANSPORT_MODE=http npx -y @aashari/mcp-server-atlassian-confluence

Testing with curl:

# Initialize session
curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2024-11-05", "clientInfo": {"name": "curl-test", "version": "1.0.0"}, "capabilities": {}}}'

# List available tools
curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc": "2.0", "id": 2, "method": "tools/list"}'

# Call a tool
curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc": "2.0", "id": 3, "method": "tools/call", "params": {"name": "conf_get", "arguments": {"path": "/wiki/api/v2/spaces", "queryParams": {"limit": "5"}}}}'

The response comes as Server-Sent Events (SSE) with format:

event: message
data: {"jsonrpc": "2.0", "id": 1, "result": {...}}

Troubleshooting

"Authentication failed" or "403 Forbidden"

  1. Check your API Token permissions:

  2. Verify your site name format:

    • If your Confluence URL is https://mycompany.atlassian.net

    • Your site name should be just mycompany

  3. Test your credentials:

    npx -y @aashari/mcp-server-atlassian-confluence get --path "/wiki/api/v2/spaces?limit=1"

"Resource not found" or "404"

  1. Check the API path:

    • Paths are case-sensitive

    • Use numeric IDs for spaces and pages (not keys)

    • Verify the resource exists in your browser

  2. Verify access permissions:

    • Make sure you have access to the space/page in your browser

    • Some content may be restricted to certain users

"No results found" when searching

  1. Try different search terms:

    • Use CQL syntax for advanced searches

    • Try broader search criteria

  2. Check CQL syntax:

    • Validate your CQL in Confluence's advanced search first

Claude Desktop Integration Issues

  1. Restart Claude Desktop after updating the config file

  2. Verify config file location:

    • macOS: ~/.claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

Getting Help

If you're still having issues:

  1. Run a simple test command to verify everything works

  2. Check the GitHub Issues for similar problems

  3. Create a new issue with your error message and setup details

Frequently Asked Questions

What permissions do I need?

Your Atlassian account needs:

  • Access to Confluence with the appropriate permissions for the spaces you want to query

  • API token with appropriate permissions (automatically granted when you create one)

Can I use this with Confluence Server (on-premise)?

Currently, this tool only supports Confluence Cloud. Confluence Server/Data Center support may be added in future versions.

How do I find my site name?

Your site name is the first part of your Confluence URL:

  • URL: https://mycompany.atlassian.net -> Site name: mycompany

  • URL: https://acme-corp.atlassian.net -> Site name: acme-corp

What AI assistants does this work with?

Any AI assistant that supports the Model Context Protocol (MCP):

  • Claude Desktop

  • Cursor AI

  • Continue.dev

  • Many others

Is my data secure?

Yes! This tool:

  • Runs entirely on your local machine

  • Uses your own Confluence credentials

  • Never sends your data to third parties

  • Only accesses what you give it permission to access

Can I search across all my spaces at once?

Yes! Use CQL queries for cross-space searches. For example:

npx -y @aashari/mcp-server-atlassian-confluence get \
  --path "/wiki/rest/api/search" \
  --query-params '{"cql": "type=page AND text~\"API documentation\""}'

Migration from v2.x

Version 3.0 replaces 8+ specific tools with 5 generic HTTP method tools. If you're upgrading from v2.x:

Before (v2.x):

conf_ls_spaces, conf_get_space, conf_ls_pages, conf_get_page,
conf_search, conf_ls_comments, conf_add_comment, ...

After (v3.0):

conf_get, conf_post, conf_put, conf_patch, conf_delete

Migration examples:

  • conf_ls_spaces -> conf_get with path /wiki/api/v2/spaces

  • conf_get_space -> conf_get with path /wiki/api/v2/spaces/{id}

  • conf_ls_pages -> conf_get with path /wiki/api/v2/pages?space-id={id}

  • conf_get_page -> conf_get with path /wiki/api/v2/pages/{id}

  • conf_search -> conf_get with path /wiki/rest/api/search?cql=...

  • conf_add_comment -> conf_post with path /wiki/api/v2/pages/{id}/footer-comments

Technical Details

Requirements

  • Node.js: 18.0.0 or higher

  • MCP SDK: 1.23.0 (uses modern registerTool API)

  • Confluence: Cloud only (Server/Data Center not supported)

Architecture

This server follows a 5-layer architecture:

  1. Tools Layer (src/tools/) - MCP tool definitions with Zod validation

  2. CLI Layer (src/cli/) - Commander-based CLI for direct testing

  3. Controllers Layer (src/controllers/) - Business logic, JMESPath filtering, output formatting

  4. Services Layer (src/services/) - Confluence API communication

  5. Utils Layer (src/utils/) - Shared utilities (logger, config, formatters, TOON encoder)

Features

  • Generic HTTP method tools - Access any Confluence API endpoint

  • TOON output format - 30-60% token reduction vs JSON

  • JMESPath filtering - Extract only needed data

  • Response truncation - Automatic handling of large responses

  • Raw response logging - Full responses saved to /tmp/mcp/

  • Dual transport - STDIO (for Claude Desktop) and HTTP (for web integrations)

  • Debug logging - Comprehensive logging for troubleshooting

Version History

v3.2.1 (Current)

  • Add raw response logging with truncation for large API responses

  • Improve dependency compatibility

v3.2.0

  • Modernize MCP SDK to v1.23.0 with registerTool API

v3.1.0

  • Add TOON output format for token-efficient LLM responses

v3.0.0 (Breaking change)

  • Replace 8+ domain-specific tools with 5 generic HTTP method tools

  • Add JMESPath filtering support

  • Full Confluence API access via generic methods

See CHANGELOG.md for complete version history.

Support

Need help? Here's how to get assistance:

  1. Check the troubleshooting section above - most common issues are covered there

  2. Visit our GitHub repository for documentation and examples: github.com/aashari/mcp-server-atlassian-confluence

  3. Report issues at GitHub Issues

  4. Start a discussion for feature requests or general questions

Made with care for teams who want to bring AI into their knowledge management workflow.

Available Tools

5 tools
conf_deleteConfluence DELETE RequestA

Delete Confluence resources. Returns TOON format by default.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  • /wiki/api/v2/pages/{id} - Delete page

  • /wiki/api/v2/blogposts/{id} - Delete blog post

  • /wiki/api/v2/pages/{id}/labels/{label-id} - Remove label

  • /wiki/api/v2/footer-comments/{id} - Delete comment

  • /wiki/api/v2/attachments/{id} - Delete attachment

Note: Most DELETE endpoints return 204 No Content on success.

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[*].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[*].id" (IDs only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations absent, so description carries full burden. It describes the action, output format (TOON), and typical response (204), but omits authorization, error handling, and irreversible nature beyond 'Delete'.

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?

Well-structured with clear sections and bullet points. Front-loaded with core action. The list of endpoints is slightly lengthy but overall concise.

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?

Lacks output schema, so description should explain return values. Mentions TOON format and 204 response but not error handling or response structure. Missing guidance on authentication and pagination.

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 parameters are already documented. Description adds concrete endpoint examples for the 'path' parameter but does not significantly enhance understanding of other parameters beyond schema.

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?

Clearly states it deletes Confluence resources via DELETE HTTP method, with specific endpoint examples, differentiating from siblings (get, patch, post, put).

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?

No explicit guidance on when to use this tool vs alternatives. Usage is implied by the action 'Delete' but not clarified with respect to other methods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

conf_getConfluence GET RequestA

Read any Confluence data. Returns TOON format by default (30-60% fewer tokens than JSON).

IMPORTANT - Cost Optimization:

  • ALWAYS use jq param to filter response fields. Unfiltered responses are very expensive!

  • Use limit query param to restrict result count (e.g., limit: "5")

  • If unsure about available fields, first fetch ONE item with limit: "1" and NO jq filter to explore the schema, then use jq in subsequent calls

Schema Discovery Pattern:

  1. First call: path: "/wiki/api/v2/spaces", queryParams: {"limit": "1"} (no jq) - explore available fields

  2. Then use: jq: "results[*].{id: id, key: key, name: name}" - extract only what you need

Output format: TOON (default, token-efficient) or JSON (outputFormat: "json")

Common paths:

  • /wiki/api/v2/spaces - list spaces

  • /wiki/api/v2/pages - list pages (use space-id query param)

  • /wiki/api/v2/pages/{id} - get page details

  • /wiki/api/v2/pages/{id}/body - get page body (body-format: storage, atlas_doc_format, view)

  • /wiki/rest/api/search - search content (cql query param)

JQ examples: results[*].id, results[0], results[*].{id: id, title: title}

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[*].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[*].id" (IDs only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It fully discloses behavior: returns TOON format by default (30-60% fewer tokens), explains cost implications, and provides a schema discovery pattern. However, it does not mention error handling, authentication requirements, or rate limiting. Could be slightly more transparent on edge cases but sufficient for a read tool.

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?

Well-structured with clear sections (IMPORTANT - Cost Optimization, Schema Discovery Pattern, Output format, Common paths, JQ examples). Front-loaded with core purpose and crucial cost advice. Every sentence adds value; no fluff. Appropriately detailed for a complex tool without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive given no output schema: explains output format, how to control it, provides common paths, discovery pattern, and jq examples. With 4 parameters and no output schema, the description fully equips an agent to use the tool effectively, including cost optimization. Sibling tools are all write, reinforcing the read-only nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but description adds significant value beyond schema: explains `jq` with cost-saving context, contrasts `outputFormat` options, gives concrete examples for `path` and `queryParams`. Each parameter is well-contextualized in the tool's usage, making it easier for the agent to choose correct values.

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?

Starts with 'Read any Confluence data', clearly describing the tool as a read-only GET request. Differentiates from sibling tools (conf_delete, conf_patch, conf_post, conf_put) which are all write operations. Also specifies output format (TOON by default) and token efficiency.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides extensive usage guidelines: strongly recommends using `jq` and `limit` to reduce costs, outlines a discovery pattern for exploring schemas, lists common paths with examples, and gives jq examples. Explicitly advises on when to use this tool for reading and implies not for writing by nature of being a GET tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

conf_patchConfluence PATCH RequestA

Partially update Confluence resources. Returns TOON format by default.

IMPORTANT - Cost Optimization: Use jq param to filter response fields.

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Update space: /wiki/api/v2/spaces/{id} body: {"name": "New Name", "description": {"plain": {"value": "Desc", "representation": "plain"}}}

  2. Update comment: /wiki/api/v2/footer-comments/{id}

Note: Confluence v2 API primarily uses PUT for updates.

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[*].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[*].id" (IDs only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
bodyYesRequest body as a JSON object. Structure depends on the endpoint. Example for page: {"spaceId": "123", "title": "Page Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It discloses default output format (TOON) and cost optimization via 'jq' parameter. However, it does not discuss error handling, idempotency, authentication requirements, or side effects beyond the PATCH verb.

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 well-structured with sections and bolded notes, making key information scannable. It is somewhat verbose with examples, but each part earns its place by providing actionable guidance. Could be slightly trimmed without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return format (TOON or JSON) and common endpoint patterns. It covers the main use case (partial updates) and provides API reference URL. Missing details on response structure beyond format, but overall complete for a patch 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?

All 5 parameters have schema descriptions (100% coverage). The description adds value by providing concrete examples for 'path' and 'body', common operations, and cost optimization context for 'jq' and 'outputFormat'. This goes beyond the schema fields.

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 explicitly states 'Partially update Confluence resources' and provides specific examples for updating a space and comment. The name 'conf_patch' and sibling tools ('conf_delete', 'conf_get', 'conf_post', 'conf_put') clearly differentiate it as the partial update operation.

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 mentions that Confluence v2 API primarily uses PUT for updates, which hints at when to use PATCH vs PUT, but does not explicitly state when to use this tool over alternatives. No guidance on when not to use or prerequisites beyond this subtle note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

conf_postConfluence POST RequestA

Create Confluence resources. Returns TOON format by default (token-efficient).

IMPORTANT - Cost Optimization:

  • Use jq param to extract only needed fields from response (e.g., jq: "{id: id, title: title}")

  • Unfiltered responses include all metadata and are expensive!

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Create page: /wiki/api/v2/pages body: {"spaceId": "123456", "status": "current", "title": "Page Title", "parentId": "789", "body": {"representation": "storage", "value": "<p>Content</p>"}}

  2. Create blog post: /wiki/api/v2/blogposts body: {"spaceId": "123456", "status": "current", "title": "Blog Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

  3. Add label: /wiki/api/v2/pages/{id}/labels - body: {"name": "label-name"}

  4. Add comment: /wiki/api/v2/pages/{id}/footer-comments

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[*].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[*].id" (IDs only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
bodyYesRequest body as a JSON object. Structure depends on the endpoint. Example for page: {"spaceId": "123", "title": "Page Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations; description covers output format and cost implications but lacks details on authentication requirements, potential side effects, or behavior for existing resources.

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?

Well-structured with sections and front-loaded important info, but slightly verbose with repeated examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers usage, cost optimization, output format, and common operations; missing auth and error handling, but references external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions. The description adds significant value with endpoint examples, body structures, and jq usage guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates Confluence resources, with specific examples like creating pages, blog posts, labels, and comments. This distinguishes it from sibling tools (get, delete, patch, put).

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?

Provides cost optimization tips and common operation examples, but does not explicitly state when not to use the tool or compare with siblings beyond implied HTTP methods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

conf_putConfluence PUT RequestA

Replace Confluence resources (full update). Returns TOON format by default.

IMPORTANT - Cost Optimization:

  • Use jq param to extract only needed fields from response

  • Example: jq: "{id: id, version: version.number}"

Output format: TOON (default) or JSON (outputFormat: "json")

Common operations:

  1. Update page: /wiki/api/v2/pages/{id} body: {"id": "123", "status": "current", "title": "Updated Title", "spaceId": "456", "body": {"representation": "storage", "value": "<p>Content</p>"}, "version": {"number": 2}} Note: version.number must be incremented

  2. Update blog post: /wiki/api/v2/blogposts/{id}

Note: PUT replaces entire resource. Version number must be incremented.

API reference: https://developer.atlassian.com/cloud/confluence/rest/v2/

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe Confluence API endpoint path (without base URL). Must start with "/". Examples: "/wiki/api/v2/spaces", "/wiki/api/v2/pages", "/wiki/api/v2/pages/{id}"
queryParamsNoOptional query parameters as key-value pairs. Examples: {"limit": "25", "cursor": "...", "space-id": "123", "body-format": "storage"}
jqNoJMESPath expression to filter/transform the response. IMPORTANT: Always use this to extract only needed fields and reduce token costs. Examples: "results[*].{id: id, title: title}" (extract specific fields), "results[0]" (first result), "results[*].id" (IDs only). See https://jmespath.org
outputFormatNoOutput format: "toon" (default, 30-60% fewer tokens) or "json". TOON is optimized for LLMs with tabular arrays and minimal syntax.
bodyYesRequest body as a JSON object. Structure depends on the endpoint. Example for page: {"spaceId": "123", "title": "Page Title", "body": {"representation": "storage", "value": "<p>Content</p>"}}

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses key behaviors: full replacement, version increment requirement, default TOON output, and jq cost optimization. It adequately informs about operational effects.

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?

Well-structured with sections, bold headings, and bullet points. Front-loaded with purpose, then organized by cost, output, and examples. Some redundancy (version increment mentioned twice), but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main aspects for a PUT tool: purpose, parameters, common operations, output format, and token optimization. Lacks error handling or status codes, but sufficient given schema completeness.

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%, but the description adds value through examples (e.g., page update body) and explanations of jq and outputFormat, enriching understanding beyond the schema.

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 states 'Replace Confluence resources (full update)' with specific examples for pages and blog posts, clearly distinguishing it from partial update (patch) siblings.

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 usage for full replacements via 'full update' and 'PUT replaces entire resource', but lacks explicit comparison to conf_patch or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

No tool schema history has been recorded yet.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool corresponds to a distinct HTTP method (DELETE, GET, PATCH, POST, PUT), clearly differentiating their purpose. There is no overlap in functionality between tools.

Naming Consistency5/5

All tools follow the consistent pattern 'conf_' followed by the HTTP method verb in lowercase (e.g., conf_delete, conf_get). This pattern is uniform and predictable.

Tool Count5/5

With 5 tools covering the essential CRUD operations plus partial update, the count is well-scoped for a Confluence API server. It is not too few or too many.

Completeness5/5

The tools provide full coverage of basic resource lifecycle operations (create, read, update, partial update, delete). The descriptions include common API paths for pages, spaces, blog posts, etc., and the GET tool supports search via query parameters, leaving no obvious gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • MCP Atlassian Server

    phuc-nt
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server that connects AI assistants like Cline to Atlassian Jira and Confluence, enabling them to query data and perform actions through a standardized interface.
    37
    53
    MIT

  • MCP Atlassian

    uchinx
    A
    license
    Not graded
    quality
    D
    maintenance
    Model 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.
    1
    MIT

Appeared in Searches

Latest Blog Posts

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/aashari/mcp-server-atlassian-confluence'

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