Skip to main content
Glama

confluence_list_comments

List root footer or inline comments on a Confluence page to audit or extract individual comment entries. Use this for page-level comment lists, not full reply threads.

Instructions

Primitive: list root footer or inline comments on a page. For one discussion and all bounded replies, prefer confluence_get_comment_thread; use this for a single page-level comment list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNo
limitNo
cursorNo
statusNo
page_idYes
max_charsNo
body_formatNostorage
comment_typeNofooter
resolution_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the behavioral burden. It communicates a read-only list operation and root-comment scope, but it does not disclose pagination/cursor behavior, sorting semantics, status filters, response shape, or content truncation despite parameters like limit, cursor, status, and max_chars existing.

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 with no waste. The core operation and scope are front-loaded, and the alternative routing takes the second sentence. Every word earns its place.

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 9 parameters, no annotations, and no output schema, this description is too thin. It explains intent but omits essential context about pagination, return content, filtering behavior, and output shape that an agent would need to invoke the tool confidently.

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%, yet the description only mildly clarifies comment_type by saying 'root footer or inline comments' and page_id by saying 'single page-level comment list.' It does not explain sort, limit, cursor, status, max_chars, body_format, or resolution_status, leaving most parameters underspecified.

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 and resource: 'list root footer or inline comments on a page.' It also names the sibling confluence_get_comment_thread and clarifies that this tool is for a single page-level comment list, so an agent can distinguish it from related tools.

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?

The description gives explicit routing guidance: for one discussion with all bounded replies, prefer confluence_get_comment_thread; use this tool for a single page-level comment list. This directly answers when to use this tool versus the key alternative.

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