Skip to main content
Glama

List Footer Comment Replies

list_footer_comment_replies
Read-only

Retrieve replies (child comments) for a specific footer comment using its ID. Supports sorting, pagination, and body format selection.

Instructions

List replies (child comments) of a footer comment.

Args:
    comment_id: Parent comment ID.
    body_format: Body representation.
    sort: Sort field.
    cursor: Pagination cursor.
    limit: Max results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNo
limitNo
cursorNo
comment_idYes
body_formatNo
Behavior2/5

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

With readOnlyHint=true and destructiveHint=false already present in annotations, the description's only additional behavioral info is that it lists child comments. It omits details about pagination, sorting behavior, error handling, or return shape, offering minimal transparency beyond the annotations.

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 text is brief and front-loaded with the core purpose; the args list is neatly formatted. There is no redundant prose, making it an efficient reference, though the minimalism borders on under-specification.

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 no output schema and five parameters, the description fails to indicate the return format, pagination semantics, supported body_format values, or sort fields. It only states the action and lists parameter names, leaving significant gaps for an agent to correctly invoke the tool.

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?

The schema has 0% description coverage, so the description must compensate, but each parameter line merely restates the parameter name (e.g., 'sort: Sort field', 'cursor: Pagination cursor') without adding meaning. Only comment_id gains context as 'Parent comment ID'; body_format, sort, and cursor remain underspecified.

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 first sentence clearly states it lists replies (child comments) of a footer comment, specifying the resource and action. While it differentiates from list_page_footer_comments and get_footer_comment by scope, it does not explicitly name alternatives, so it stops short of full sibling differentiation.

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?

No guidance is given on when to use this tool versus list_page_footer_comments or get_footer_comment. The description only defines the operation and its arguments, with no mention of prerequisites, exclusions, or alternative tool recommendations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pascalhubacher/confluence'

If you have feedback or need assistance with the MCP directory API, please join our Discord server