Which integrations are available for this server?

Provides programmatic access to Atlassian Cloud services for content management, using both classic and scoped API tokens for secure interaction with the Confluence platform. Offers a comprehensive suite of tools for Confluence, including full CRUD operations for spaces, pages, and folders, CQL-based search, version diffing, and management of labels, comments, and attachments.

ctk

by zach-snell

Overview Schema Related Servers Score Discussions

Remote

ctk — Confluence Toolkit

Go Report Card Documentation License

The most comprehensive dedicated Confluence MCP server in the open-source ecosystem. A dual-mode Go binary that works as both a rich CLI tool and an MCP server for AI agents.

8 MCP tools · Full CLI · Write gating · Single binary · Zero dependencies

Why ctk?

	ctk	mcp-atlassian (Python)
Language	Go (single ~15MB binary)	Python (pip install + deps)
Confluence tools	8 dedicated tools	~30 mixed Jira+Confluence
Startup	~50ms	~2s
Folder support	Full CRUD	None
Page diff	LCS-based unified diff	None
Space create	Yes (V1 stable API)	None
Write gating	`CTK_ENABLE_WRITES` env var	None
Auth	Classic + scoped tokens	Classic only

Related MCP server: obx

Features

Dual Mode — CLI for humans, MCP server for AI agents, same binary
V2 API First — Modern Confluence V2 REST API with cursor-based pagination, V1 fallback for CQL search and space create
Folder Support — Full CRUD for Confluence folders — the only dedicated Confluence MCP with folder operations
Page Diff — LCS-based unified diff between any two page versions
Write Gating — Mutation tools only registered when CTK_ENABLE_WRITES=true, safe read-only defaults
Token-Efficient — Consolidated action-based tools minimize schema overhead. XHTML↔Markdown conversion. ResponseFlattener strips metadata bloat
Markdown Interface — Agents send/receive markdown, ctk converts to/from Confluence XHTML storage format internally

Installation

# From source
git clone https://github.com/zach-snell/ctk.git && cd ctk
./install.sh  # builds and copies to ~/.local/bin

# Or build manually
go build -o ctk ./cmd/ctk

Pre-built binaries available on the Releases page.

Quick Start

# Authenticate
ctk auth

# List spaces
ctk spaces list

# Get a page
ctk pages get 12345

# Search with CQL
ctk search --cql "type = page AND space = DEV AND title ~ 'architecture'"

# Create a page (writes enabled)
ctk pages create --space-id 12345 --title "My Page" --body "# Hello World"

CLI Commands

ctk auth                    Authenticate with Confluence Cloud
ctk spaces                  List, get, create spaces
ctk pages                   Page CRUD, versions, diff, move
ctk folders                 Folder CRUD, children
ctk search                  CQL and quick text search

MCP Server

Stdio Transport (Claude Desktop, Cursor, OpenCode, etc.)

{
  "mcpServers": {
    "confluence": {
      "command": "/path/to/ctk",
      "args": ["mcp"],
      "env": {
        "CONFLUENCE_DOMAIN": "your-domain",
        "CONFLUENCE_EMAIL": "you@example.com",
        "CONFLUENCE_API_TOKEN": "your-api-token",
        "CTK_ENABLE_WRITES": "true"
      }
    }
  }
}

Streamable HTTP Transport

ctk mcp --port 8080

Environment Variables

Variable	Description	Required
`CONFLUENCE_DOMAIN`	Atlassian domain (e.g., `acme` for acme.atlassian.net)	Yes
`CONFLUENCE_EMAIL`	Email for the API token	Yes
`CONFLUENCE_API_TOKEN`	Atlassian API token	Yes
`CONFLUENCE_TOKEN_TYPE`	`classic` or `scoped` (auto-detected if omitted)	No
`CTK_ENABLE_WRITES`	Set to `true` to enable mutation tools	No
`CTK_DISABLED_TOOLS`	Comma-separated tool names to hide	No

MCP Tools (8)

Tool	Actions
`manage_spaces`	list, get, get_by_key, create
`manage_pages`	get, get_by_title, list, get_children, get_ancestors, list_versions, diff, create, update, delete, move
`manage_search`	cql, quick
`manage_labels`	list, add, remove
`manage_folders`	list, get, get_children, create, update, delete
`manage_comments`	list_footer, list_inline, get_replies, add_footer, reply
`manage_attachments`	list, download, upload, delete
`manage_users`	get_current, search

Security

Three-layer safety model:

Token scopes — Atlassian scopes control which APIs the token can call (403 if missing)
Write gating — Mutation tools only registered when CTK_ENABLE_WRITES=true (read-only by default)
Tool denial — Explicitly hide tools: CTK_DISABLED_TOOLS="manage_folders,manage_labels"

Development

go test -race ./...          # Run tests
golangci-lint run ./...      # Lint
go build -o ctk ./cmd/ctk   # Build

License

Apache 2.0

Available Tools

8 tools

manage_attachmentsC

Unified tool for Confluence attachment operations (list, download)

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'list', 'download', 'upload', 'delete'
`page_id`	No	Page ID (required for list, upload)
`attachment_id`	No	Attachment ID (required for download, delete)
`file_path`	No	Absolute path to the file to upload (required for upload). Note: paths refer to the MCP server's filesystem. In stdio mode this is the local machine.
`comment`	No	Optional comment for the attachment (for upload)
`limit`	No	Number of results per page (default 25)
`cursor`	No	Pagination cursor for next page

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, so the description should disclose behavioral traits like destructiveness (delete), authentication needs, or filesystem assumptions. It only mentions 'list, download' but omits upload and delete, and does not describe side effects or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, but it sacrifices completeness for brevity. It is not front-loaded with the most critical information (all supported actions) and omits important context.

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 has 7 parameters, 4 actions, no output schema, and no annotations, the description is insufficient. It does not explain how actions work together, pagination, or the file_path filesystem context, leaving the agent underinformed.

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?

All 7 parameters have full schema descriptions (100% coverage). The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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

Purpose3/5

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

The description states it is a 'Unified tool for Confluence attachment operations (list, download)', which gives a clear general purpose. However, the input schema reveals four actions (list, download, upload, delete), so the description is incomplete and misleading, reducing clarity.

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 its siblings (e.g., manage_pages, manage_comments). The description does not specify context or prerequisites for each action, leaving the agent to infer usage from the schema alone.

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

manage_commentsC

Unified tool for Confluence comments (list_footer, list_inline, get_replies)

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'list_footer', 'list_inline', 'get_replies', 'add_footer', 'reply'
`page_id`	No	Page ID (required for list_footer, list_inline, add_footer)
`comment_id`	No	Comment ID (required for get_replies, reply)
`body`	No	Comment body content (required for add_footer, reply). Accepts markdown by default (# headings, bold, italic, [links](url), - lists, \| tables). Set content_format='storage' to pass raw Confluence XHTML instead.
`content_format`	No	Format of body content: 'markdown' (default) or 'storage' for raw Confluence XHTML. When using markdown: # for headings, bold, italic, \x60code\x60, [text](url) for links, - for lists, \| for tables.
`limit`	No	Number of results per page (default 25)
`cursor`	No	Pagination cursor for next page

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided. Description does not disclose that add_footer and reply are mutation operations with side effects, nor does it mention any behavioral traits like permissions or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that is concise but omits half the available actions, making it incomplete. It is not well-structured for a multi-action tool.

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 7 parameters and 5 actions, the description is too thin. No output schema, no return value info, and missing write actions make it inadequate for full understanding.

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 already provides detailed parameter descriptions. The description adds minimal value beyond listing action names, but does not conflict with schema. Baseline 3 is appropriate.

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

Purpose3/5

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

Description states 'Unified tool for Confluence comments' and lists three actions (list_footer, list_inline, get_replies), but omits the write actions (add_footer, reply) that are present in the schema. This gives a partial purpose, enough to distinguish from sibling tools but incomplete.

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 which action or when to avoid this tool. No mention of alternatives or context for choosing between read vs write operations.

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

manage_foldersC

Unified tool for Confluence folder operations (list, get, get_children)

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'list', 'get', 'get_children', 'create', 'update', 'delete'
`folder_id`	No	Folder ID (required for get, get_children, update, delete)
`space_id`	No	Space ID (required for list, create)
`title`	No	Folder title (required for create, update)
`parent_id`	No	Parent folder ID (optional for create)
`version`	No	Folder version number (required for update — must be current version + 1)
`limit`	No	Number of results per page (default 25)
`cursor`	No	Pagination cursor for next page

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are present, and the description does not disclose behavioral traits such as mutability, idempotency, or authorization requirements. For a tool with multiple actions, this is insufficient.

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 very short (one sentence), but it omits key actions and lacks structure. While concise, it sacrifices completeness.

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?

Without output schema or annotations, the description should provide more context about return values, errors, or usage. It only lists a few actions and does not compensate for the missing structured information.

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 parameters are fully defined in the schema. The description adds no additional meaning beyond what schema already provides, meeting the baseline.

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

Purpose3/5

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

The description states it is a unified tool for folder operations and lists 'list, get, get_children', but the schema includes 'create', 'update', 'delete' actions, so the description is incomplete and slightly misleading.

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 sibling tools like manage_pages or manage_spaces. The description does not differentiate it from alternatives.

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

manage_labelsC

Unified tool for managing page labels (list)

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'list', 'add', 'remove'
`page_id`	Yes	Page ID (required for all actions)
`label`	No	Label name (required for 'add' and 'remove')
`limit`	No	Number of results per page (default 25)
`cursor`	No	Pagination cursor for next page

TDQS

C2.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 disclose behavioral traits like mutability or side effects. It only says 'unified tool' without indicating whether actions are destructive, idempotent, or require authentication.

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 very short (6 words), but it sacrifices essential information for brevity. It is not front-loaded with key details and could be more informative without being 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?

With no output schema, the description should explain return values. It does not. Also, it does not describe pagination behavior or the effect of actions, making it incomplete for a tool with 5 parameters and 3 actions.

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. The description adds no extra meaning beyond the schema descriptions. Baseline score of 3 is appropriate.

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

Purpose3/5

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

The description indicates the tool manages page labels, but the phrase '(list)' is ambiguous; it does not clarify that the tool supports add, remove, and list actions via the action parameter. It distinguishes from siblings by focusing on labels, but the scope is not fully clear.

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 siblings like manage_pages or manage_attachments. The description lacks context on prerequisites or exclusive use cases.

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

manage_pagesC

Unified tool for Confluence page operations (get, get_by_title, list, get_children, get_ancestors, list_versions, diff)

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'get', 'get_by_title', 'list', 'create', 'update', 'delete', 'get_children', 'get_ancestors', 'list_versions', 'move', 'diff'
`page_id`	No	Page ID (required for get, update, delete, get_children, get_ancestors, move, diff)
`space_id`	No	Space ID (required for list, create, get_by_title)
`title`	No	Page title (required for create, get_by_title; optional for update)
`body`	No	Page body content (for create, update). Accepts markdown by default (# headings, bold, italic, [links](url), - lists, \| tables). Set content_format='storage' to pass raw Confluence XHTML instead.
`content_format`	No	Format of body content: 'markdown' (default) or 'storage' for raw Confluence XHTML. When using markdown: # for headings, bold, italic, \x60code\x60, [text](url) for links, - for lists, \| for tables.
`parent_id`	No	Parent page ID (for create)
`version`	No	Page version number (required for update, move — must be current version + 1)
`status`	No	Page status: 'current', 'draft' (for create, update, list filter)
`body_format`	No	Body format to return: 'storage', 'atlas_doc_format', 'view'
`limit`	No	Number of results per page (default 25)
`cursor`	No	Pagination cursor for next page
`sort`	No	Sort order for list (e.g., '-modified-date', 'title')
`target_space_id`	No	Target space ID (for move)
`target_parent_id`	No	Target parent page ID (for move)
`from_version`	No	Starting version number (required for diff)
`to_version`	No	Ending version number (required for diff)

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It simply lists operations without describing side effects, idempotency, authentication needs, or what happens during creation/updates/deletion.

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 omits important information (e.g., all actions). It is not well-structured for a tool with many parameters and actions.

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 (17 parameters, 11 actions, no output schema), the description is insufficient. It does not explain the unified nature, how actions are chosen, or what return values look like.

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 description coverage is 100%, but the description adds extra value for 'body' and 'content_format' by explaining markdown syntax and storage format. This goes beyond the schema descriptions.

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

Purpose3/5

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

The description states it's a 'unified tool for Confluence page operations' and lists several actions, but omits key actions like 'create', 'update', 'delete', 'move' from the description, which are present in the schema. This partial listing reduces clarity.

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 vs. sibling tools (e.g., manage_attachments, manage_comments). There is no mention of context, prerequisites, or alternatives.

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

manage_searchA

Unified tool for Confluence search (CQL and quick text search)

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'cql', 'quick'
`cql`	No	CQL query string (required for 'cql' action). Common CQL patterns: 'type=page AND space=DEV AND title~"architecture"', 'text~"search term" AND type=page', 'label="my-label" AND space=TEAM', 'ancestor=12345 AND type=page', 'creator=currentUser() ORDER BY lastModified DESC', 'lastModified >= "2024-01-01" AND type=page', 'type=blogpost AND space=ENG'
`query`	No	Text to search for (required for 'quick' action)
`limit`	No	Number of results (default 25)
`start`	No	Starting offset for pagination
`include_archived_spaces`	No	Include archived spaces in results

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination behavior, or any side effects. The description adds no behavioral context beyond the schema-defined parameters.

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?

The description is a single, front-loaded sentence that conveys the essential purpose without any wasted words. It is optimally concise.

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 search tool with 6 parameters and no output schema, the description does not explain return value format or provide high-level context about expected results. It is minimal and lacks completeness.

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 baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides.

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 it is a unified tool for Confluence search, specifying two search modes (CQL and quick text). This distinguishes it from sibling tools that manage specific entities like pages or spaces.

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 use for Confluence searches, and siblings cover different operations, so context is clear. However, it does not explicitly state when not to use it or mention alternatives, but the inference is straightforward.

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

manage_spacesC

Unified tool for listing and getting Confluence spaces. Actions: 'list', 'get', 'get_by_key', 'create'. Write operations: false

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'list', 'get', 'get_by_key', 'create'
`space_id`	No	Space ID (required for 'get')
`key`	No	Space key (required for 'get_by_key', 'create')
`name`	No	Space name (required for 'create')
`description`	No	Space description (for 'create')
`limit`	No	Number of results per page (default 25)
`cursor`	No	Pagination cursor for next page
`type`	No	Filter by type: 'global', 'personal'
`status`	No	Filter by status: 'current', 'archived'

TDQS

C2.5/5.0

Behavior2/5

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

No annotations provided; description carries full burden but contradicts itself by stating write operations false while including a create action. No mention of authentication, rate limits, or side effects.

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?

Short but includes a contradiction that wastes explanatory value. Could be more concise without the misleading 'Write operations: false' note.

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?

No output schema, and description fails to explain return values or behavior for actions like list (pagination) or get (format). The contradiction undermines completeness.

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 clear parameter descriptions. The description adds minimal extra meaning beyond listing action names, which are already in the schema.

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

Purpose3/5

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

Description states it is a unified tool for listing and getting spaces, but also includes 'create' as an action while claiming write operations are false, creating confusion about its actual purpose.

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 vs siblings like manage_pages or manage_attachments. The description only lists actions without contextual usage advice.

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

manage_usersB

Search and get Confluence users. Actions: 'get_current', 'search'

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: 'get_current', 'search'
`query`	No	Search query — display name, email, etc. (for 'search')
`limit`	No	Maximum results to return (for 'search', default 20)

TDQS

B3.2/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 behavioral traits. It only says 'Search and get' – enough to imply read operations, but no mention of side effects, permissions, or data safety. The actions suggest no destructive behavior, but this is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: a single sentence plus a list of actions. No wasted words; every element is essential and directly informs the agent's understanding.

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?

The description lacks information about return values for each action (no output schema), authentication requirements, or examples of usage. For a tool with two distinct actions, this is insufficient for an agent to accurately anticipate results.

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 adequately describes each parameter. The description adds minimal value by listing the actions, but does not provide additional semantics beyond what is in 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?

Description clearly states the tool searches and gets Confluence users, and lists the two specific actions: 'get_current' and 'search'. It distinguishes from sibling tools (e.g., manage_pages, manage_spaces) which handle different resources.

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 explicit guidance on when to use this tool versus alternatives, or when not to use it. The description only repeats the actions listed in the schema, providing no context about prerequisites, limitations, or comparison to other tools.

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.

8 tool updatesMar 16, 2026
- First observedmanage_attachments
- First observedmanage_comments
- First observedmanage_folders
- First observedmanage_labels
- First observedmanage_pages
- First observedmanage_search
- First observedmanage_spaces
- First observedmanage_users

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct Confluence domain (attachments, comments, folders, labels, pages, search, spaces, users) with no overlap in functionality.

Naming Consistency5/5

All tools follow a consistent 'manage_<resource>' pattern, making it easy for an agent to predict tool names for different resources.

Tool Count5/5

8 tools is a well-scoped set that covers the major Confluence resources without being overwhelming or too sparse.

Completeness4/5

The tool surface covers core CRUD operations for pages, spaces, attachments, and more, though it misses some advanced features like content restrictions or page tree navigation.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

GitLab MCP Server A
io.github.jmrplens
Go MCP server for GitLab: 2 dynamic tools reach 1000+ REST/GraphQL actions. Free/CE, no paid tier.
CI/CD & DevOps Developer Tools Version Control
2133
Confluence B
io.github.pipeworx-io
Confluence MCP — wraps the Confluence Cloud REST API v2 (OAuth)
Content Management Systems Workplace & Productivity Documentation Access
362
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
remnus AOAuth
io.github.Ranork
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
Note Taking Project Management Workplace & Productivity
370

Related MCP Servers

bbkt
Version Control CI/CD & DevOps Developer Tools
zach-snell
A
license
A
quality
B
maintenance
A Bitbucket CLI and MCP server written in Go for managing workspaces, repositories, pull requests, pipelines, issues, and source code. Supports stdio and HTTP transport.
Updated 2 months ago (2026-07-12 05:12 UTC)
10
4
Apache 2.0
obx
Note Taking File Systems Developer Tools
zach-snell
A
license
A
quality
B
maintenance
A fast, lightweight MCP server and CLI for Obsidian vaults built in Go. 16 multiplexed tools covering 72 actions for notes, search, templates, tasks, links, frontmatter, and vault analysis. Single binary, no plugins required.
Updated 6 months ago (2026-03-07 20:32 UTC)
15
4
Apache 2.0
jtk
Project Management Developer Tools Version Control
zach-snell
A
license
B
quality
C
maintenance
Jira CLI & MCP Server — dual-mode Go binary for Jira Cloud with 9 tools, 4 prompts, permission introspection, and dev-status API.
Updated 3 months ago (2026-06-06 05:02 UTC)
10
1
Apache 2.0
adtk
CI/CD & DevOps Version Control Project Management
zach-snell
A
license
B
quality
C
maintenance
The most comprehensive Azure DevOps MCP server & CLI — 13 tools, 82 actions, single Go binary.
Updated 6 months ago (2026-03-18 21:49 UTC)
14
1
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/zach-snell/ctk'

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