Skip to main content
Glama

confluence_get_content_tree

Fetch a Confluence page/folder hierarchy as an indented text tree in one call, avoiding recursive child lookups. Choose compact, outline, or detailed modes; cursor pagination handles large trees.

Instructions

HIGH-LEVEL: Get a page or folder hierarchy in one MCP call, rendered as an indented text tree (title [id], a trailing / marks folders). Prefer this over recursively calling confluence_list_children: the server reads v2 descendants, consumes cursor pagination, and rebuilds the hierarchy. output_mode=compact (default) returns the deepest view that fits the output budget and lists collapsed branches in omittedBranches, so a follow-up call can expand only what matters; output_mode=outline returns just the direct children with child counts and is the cheapest way to map a large or unknown tree first; output_mode=detailed returns raw node objects and is only worth it when parentId, childPosition or status are needed. Retained document versions, which Confluence stores as "Versions of ..." child content, are excluded by default so history cannot consume the item budget ahead of sibling branches; set include_version_history=true to include them, and status.excludedVersionHistory reports what was skipped. status separates fetchedItems from renderedItems and names every truncationReason. When status.nextCursor is returned, pass it back as cursor with the same root_id, depth and output_mode to continue the traversal; when truncationReasons contains output_budget, raising max_chars renders more of what was already fetched without extra API calls.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNo
cursorNo
root_idYes
max_charsNo
max_itemsNo
root_typeNopage
output_modeNocompact
include_version_historyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers: the server reads v2 descendants and consumes cursor pagination, rebuilds the hierarchy, excludes version-history content by default so it cannot consume the item budget, and status separates fetchedItems from renderedItems and names every truncationReason. It also discloses continuation behavior via nextCursor and that raising max_chars renders already-fetched data without extra API calls.

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?

The description is long but every clause carries behavioral information and it front-loads the high-level purpose before details. A bulleted structure would improve scanability slightly, but there is little redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 8-parameter tool with no annotations and no output schema, the description covers invocation, output format, mode trade-offs, pagination continuation, truncation semantics, and version-history exclusion. An agent has enough to select and drive the tool correctly without external documentation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description defines the meaningful behavior of output_mode (compact/outline/detailed), include_version_history, cursor/nextCursor, depth/root_id for continuation, max_chars effect, and item-budget behavior linked to max_items. This substantially compensates for the empty parameter descriptions.

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?

States a specific verb+resource: get a page or folder hierarchy as an indented text tree, with notation (title [id], trailing / for folders). It also distinguishes itself from the named sibling confluence_list_children by positioning this as a single-call alternative to recursive calls.

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

Usage Guidelines5/5

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

Explicitly instructs to prefer this over recursively calling confluence_list_children, and gives mode-selection rules: outline for cheaply mapping large/unknown trees, detailed only when parentId/childPosition/status are needed, compact as default. It also explains when to pass cursor back and when raising max_chars is worthwhile.

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