Skip to main content
Glama
aaronsb

Confluence Cloud MCP Server

by aaronsb

manage_confluence_page

Create, update, delete, move, copy, archive, and edit Confluence pages, plus manage comments, labels, and properties. Pull existing content into a scratchpad for editing before publishing.

Instructions

Get, create, update, delete, move, copy, archive, or pull pages for editing. Read and add comments. Manage labels and content properties. Create returns a scratchpad for composing content before publishing. Use pull_for_editing to load existing page content into a scratchpad. Archive/unarchive pages or entire page trees.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoComment text as markdown (for add_comment). Rendered through the same directive parser as page content.
labelNoLabel to remove (for remove_label operation)
titleNoPage title (required for create, optional for update)
expandNoAdditional data to include in the response
labelsNoLabels to add (for add_labels operation)
pageIdNoPage ID (required for get, update, delete, move, copy, get_versions, pull_for_editing, get_comments, add_comment, archive, archive_tree, unarchive)
spaceIdNoSpace ID (required for create, usable for list_archived)
parentIdNoParent page ID (optional for create, required for move, optional for copy)
spaceKeyNoSpace key (for list_archived)
operationYesThe operation to perform
propertyKeyNoContent property key (for get_property, set_property, delete_property)
propertyValueNoContent property value as JSON object (for set_property)
parentCommentIdNoComment ID to reply to (optional for add_comment). Ids come from get_comments; replies to inline comments land on that inline thread.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.0
    • addedInput schema / properties / body
      Added value: +{
      +  "description": "Comment text as markdown (for add_comment). Rendered through the same directive parser as page content.",
      +  "type": "string"
      +}
    • changedInput schema / properties / operation / enum
      Previous value: -[
      -  "get",
      -  "create",
      -  "update",
      -  "delete",
      -  "move",
      -  "copy",
      -  "get_versions",
      -  "pull_for_editing",
      -  "get_labels",
      -  "add_labels",
      -  "remove_label",
      -  "get_properties",
      -  "get_property",
      -  "set_property",
      -  "delete_property",
      -  "archive",
      -  "archive_tree",
      -  "unarchive",
      -  "list_archived"
      -]New value: +[
      +  "get",
      +  "create",
      +  "update",
      +  "delete",
      +  "move",
      +  "copy",
      +  "get_versions",
      +  "pull_for_editing",
      +  "get_comments",
      +  "add_comment",
      +  "get_labels",
      +  "add_labels",
      +  "remove_label",
      +  "get_properties",
      +  "get_property",
      +  "set_property",
      +  "delete_property",
      +  "archive",
      +  "archive_tree",
      +  "unarchive",
      +  "list_archived"
      +]
    • changedInput schema / properties / pageId / description
      Previous value: -"Page ID (required for get, update, delete, move, copy, get_versions, pull_for_editing, archive, archive_tree, unarchive)"New value: +"Page ID (required for get, update, delete, move, copy, get_versions, pull_for_editing, get_comments, add_comment, archive, archive_tree, unarchive)"
    • addedInput schema / properties / parentCommentId
      Added value: +{
      +  "description": "Comment ID to reply to (optional for add_comment). Ids come from get_comments; replies to inline comments land on that inline thread.",
      +  "type": "string"
      +}
  2. First observedv0.5.1

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does reveal that create returns a scratchpad and pull_for_editing loads page content into a scratchpad, but it omits side effects, destructive implications, permission requirements, error behavior, and what operations like delete, archive, or update actually return or change.

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?

Three sentences pack a broad operation list without fluff, front-loading the verbs and then adding the scratchpad behavior and archive-tree note. It could be better structured by grouping operations by category, but it remains compact and readable for its scope.

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?

This is a high-complexity tool with 21 operations, 13 parameters, no output schema, and no annotations. The description provides only an operation list and two hints, leaving per-operation behavior, return values, side effects, and correct selection criteria largely underspecified for safe autonomous invocation.

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 even without rich parameter explanations. The description adds operation-level semantics like scratchpad creation and pull_for_editing, but it does not add meaning for individual parameters beyond what the schema already documents.

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

Purpose4/5

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

The description clearly enumerates concrete operations and resources: get/create/update/delete/move/copy/archive pages, comments, labels, and properties. However, it does not distinguish itself from siblings like edit_confluence_content or navigate_confluence, and the 21-operation list makes the primary purpose diffuse.

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

Usage Guidelines2/5

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

The description gives almost no guidance on when to choose this tool over alternatives, and names no excluded use cases or sibling tools. The only usage hint is internal: pull_for_editing loads existing content into a scratchpad, which is not enough to route an agent across the overlapping sibling set.

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