Loading ToolBench
Confluence MCP server for Cloud/Server/Data Center search/read/create/update
The server implements 6 well-named tools with clear, consistent descriptions and proper Zod schemas. All tools follow verb_noun naming convention (confluence_get_*, confluence_search_*, confluence_create_*, confluence_update_*). Descriptions are concise and action-oriented (average ~100 chars). Zod schemas properly define types, constraints (min/max for numeric params), and optional flags. However, output schema structure is not explicitly documented, responses are inferred from code comments. Parameter descriptions are good but could be more prescriptive about formats (e.g., storage format details for bodyStorageValue). Error handling returns structured error responses but lacks actionable recovery guidance. Missing field descriptions for some complex inputs (expand parameter purpose could be clearer).
Configure the Confluence connection for this MCP server process. Use this when CONF_* env vars were not set or when switching to another Confluence site.
Create a Confluence page. Supports optional parentId. Returns unified fields.
Execute raw Confluence CQL search. Returns unified fields: id, type, title, spaceKey, url, version.
Get the current Confluence connection status without returning secrets.
Get current authenticated Confluence user (whoami).
Get a Confluence page by ID. Returns unified fields and bodyStorageValue.
Get a page block between two invisible anchor macros. Returns only the matched block to save tokens.
Output schema structure not explicitly documented. Code infers response shape from jsonContent() wrapper, but agents cannot see field definitions for returned page objects. Missing documentation of 'id', 'type', 'title', 'spaceKey', 'url', 'version', 'bodyStorageValue' fields.
Error responses provide minimal guidance for recovery. errorContent() returns only error.message without context about whether the error is retryable, what caused it, or what the agent should try next. E.g., a 404 for missing page should suggest search_pages as alternative.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Get a page outline by parsing headings from body.storage. Returns unified fields plus headings[] for low-token navigation.
Get a single page section by heading. The server fetches full storage internally but only returns the matched section to save tokens.
Preview a heading-based section update. Returns the currently matched section, the proposed replacement, and a hash that must be echoed to the confirmed update call.
Search Confluence pages by keyword. Returns unified fields: id, type, title, spaceKey, url, version.
Update a Confluence page content. Auto increments version. Returns unified fields.
Update one page section by heading. The server fetches full storage internally, replaces the matched range, and writes back the whole page so the model only sends the section content.
Parameter 'expand' in confluence_get_page and confluence_execute_cql_search described as 'Comma-separated expand fields' but no documentation of valid field names or when to use it. LLM cannot determine which fields are valid without API documentation.
confluence_update_page marks 'bodyStorageValue' as required but 'title' as optional. If both are optional, it could allow empty updates. If body is truly required, documentation should clarify the intent (update title only? body only? both?).
No pagination support documented for confluence_search_pages and confluence_execute_cql_search. limit parameter caps at 25 and 50 respectively, but no mention of offset/cursor or total count in response. Large result sets could fill context window.
Confluence storage format (XHTML) for bodyStorageValue requires knowledge of Atlassian Document Format. Description should provide format hints, link to documentation, or examples. LLMs cannot reliably generate valid XHTML without explicit guidance.