atlassian-browser-mcp

Overview Schema Source Related Servers Discussions Admin

Update Page

confluence_update_page

Destructive

Updates an existing Confluence page by ID, letting you change its title, content, parent, layout, emoji, and version comment using Markdown, wiki, or storage formats.

Instructions

Update an existing Confluence page.

Input Schema

Name	Required	Description	Default
`emoji`	No	(Optional) Page title emoji (icon shown in navigation). Can be any emoji character like '📝', '🚀', '📚'. Set to null/None to remove.
`title`	Yes	The new title of the page
`content`	No	The new content of the page. Format depends on content_format parameter and may be Markdown (default), wiki markup, storage format, or XHTML storage format. Either 'content' or 'content_file' must be provided, but not both.
`page_id`	Yes	The ID of the page to update
`parent_id`	No	Optional the new parent page ID
`page_width`	No	(Optional) Page layout width. Options: 'full-width', 'default'. Defaults to null (preserve existing).
`content_file`	No	(Optional) Absolute or relative filesystem path to read the new page body from (UTF-8). Use this instead of 'content' when the body is too large to pass comfortably as a tool argument. Mutually exclusive with 'content'.
`table_layout`	No	(Optional) Table width preset applied to all markdown tables. Options: 'full-width' (1800 px), 'wide' (960 px), 'default' (760 px). Only applies when content_format is 'markdown'.
`is_minor_edit`	No	Whether this is a minor edit
`content_format`	No	(Optional) The format of the content parameter. Options: 'markdown' (default), 'wiki', 'storage', or 'xhtml'. Use 'xhtml' when providing Confluence XHTML storage format (same as 'storage'). Wiki format uses Confluence wiki markup syntax	markdown
`include_content`	No	(Optional) Whether to include page content in the response. Defaults to false since callers already have the content at update time
`version_comment`	No	Optional comment for this version
`enable_heading_anchors`	No	(Optional) Whether to enable automatic heading anchor generation. Only applies when content_format is 'markdown'

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.1Nov 2, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedOutput schema / description
```
Removed value: -"Generic wrapper for non-object return types."
```

Changed7 schema fields changedv1.2.1Jul 12, 2026

addedInput schema / properties / content / default
```
Added value: +null
```

changedInput schema / properties / content / description

Previous value: -"The new content of the page. Format depends on content_format parameter"New value: +"The new content of the page. Format depends on content_format parameter and may be Markdown (default), wiki markup, storage format, or XHTML storage format. Either 'content' or 'content_file' must be provided, but not both."

addedInput schema / properties / content_file

Added value: +{
+  "default": null,
+  "description": "(Optional) Absolute or relative filesystem path to read the new page body from (UTF-8). Use this instead of 'content' when the body is too large to pass comfortably as a tool argument. Mutually exclusive with 'content'.",
+  "type": "string"
+}

changedInput schema / properties / content_format / description

Previous value: -"(Optional) The format of the content parameter. Options: 'markdown' (default), 'wiki', or 'storage'. Wiki format uses Confluence wiki markup syntax"New value: +"(Optional) The format of the content parameter. Options: 'markdown' (default), 'wiki', 'storage', or 'xhtml'. Use 'xhtml' when providing Confluence XHTML storage format (same as 'storage'). Wiki format uses Confluence wiki markup syntax"

addedInput schema / properties / page_width

Added value: +{
+  "default": null,
+  "description": "(Optional) Page layout width. Options: 'full-width', 'default'. Defaults to null (preserve existing).",
+  "type": "string"
+}

addedInput schema / properties / table_layout

Added value: +{
+  "default": null,
+  "description": "(Optional) Table width preset applied to all markdown tables. Options: 'full-width' (1800 px), 'wide' (960 px), 'default' (760 px). Only applies when content_format is 'markdown'.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "page_id",
-  "title",
-  "content"
-]New value: +[
+  "page_id",
+  "title"
+]

Addedv1.0.1Apr 14, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether content is fully replaced, whether omitted optional fields are cleared or preserved, that a new version is created, or whether title collisions or version conflicts can fail the call. For a destructive 13-parameter mutation this is a thin contribution.

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?

A single front-loaded sentence with zero waste. It is efficient, though the terseness is achieved by omitting information rather than by tight compression, which the other dimensions already penalize.

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?

An output schema exists and annotations cover the hints, but a destructive 13-parameter page-replacement tool warrants more than one sentence. Key facts an agent needs — that the body is replaced wholesale, that a version is created, and how this differs from section-level updates — are absent.

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 all 13 parameters (including the content/content_file exclusivity, content_format options, and page_width/table_layout) are already documented in the schema. The description contributes no additional parameter meaning, which matches the baseline 3 when the schema does the heavy lifting.

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?

States a specific verb and resource ('Update an existing Confluence page'), which is unambiguous on its own. It does not distinguish itself from close siblings such as confluence_update_page_section or confluence_create_page, so an agent must infer the boundary from tool names alone.

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?

There is no guidance on when to use this tool versus alternatives like confluence_update_page_section (partial updates) or confluence_create_page. No prerequisites, no conditions, no exclusions are stated.

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

Deploy Server