Skip to main content
Glama

confluence_create_page

Create a Confluence page in a space, published or draft, optionally under a parent page, using storage or Atlas document format.

Instructions

Create a published or draft Confluence page in a space, optionally under a parent page. Body is Confluence storage or Atlas document format.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
titleYes
statusNocurrent
subtypeNo
space_idYes
max_charsNo
parent_idNo
representationNostorage

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful context around draft/current status, parent placement, and body formats, but it does not mention permissions, side effects, response behavior, or failure modes for a mutating create operation. That is a meaningful gap for a creation tool with no annotation safety hints.

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 two sentences, front-loads the actionable verb and resource, and every phrase carries meaning. It is compact, readable, and avoids redundant restatement of the tool name.

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 8 parameters, no output schema, and no annotations, two sentences are not enough for a confident call. Missing information includes the return value, permission requirements, max_chars behavior, subtype semantics, and how the draft/current workflow operates. An agent would need to guess on several fields.

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

Parameters2/5

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

Schema description coverage is 0% and there are 8 parameters, so the description must compensate. It does clarify status, parent_id, body, and representation indirectly, but it leaves max_chars and subtype unexplained and provides no format details for the body. This only partially compensates for the low-coverage 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 a specific verb, 'Create,' and a clear resource: a Confluence page in a space, with published/draft status, optional parent, and accepted body formats. This is distinguishable from sibling tools like confluence_update_page, confluence_delete_page, or confluence_create_folder without opening the schema.

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 word 'Create' implies this is for new pages rather than updates, but the description does not explicitly say when to use it over alternatives such as confluence_update_page or confluence_raw_request. It mentions published/draft status but gives no guidance on when to choose a draft versus publishing, and it does not name alternatives or exclusions.

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