list_comments

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and access scope are covered. The description adds useful behavioral context: omitting post_id broadens the query to the entire blog, and status filters results. However, it does not disclose pagination behavior, ordering, or how many results are returned by default, even though page_token and max_results exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The main operation and scope are front-loaded, and the moderation example earns its place by showing a common use of the status parameter.

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

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

The core listing behavior and a usage case are covered, and the output schema exists so return values are documented elsewhere. However, the description leaves pagination unexplained: page_token and max_results are parameters an agent may need to use, and no guidance is given for paging through results. This is a meaningful gap for a list tool of this complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for post_id (optional, scope changes to whole blog) and status (PENDING example), but does not explain page_token, max_results, or blog_id. The enum values for status are in the schema, but the remaining parameters lack descriptive support in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List comments', and immediately clarifies scope by saying it can target one post or the whole blog. This makes it clearly distinguishable from siblings like list_posts and list_pages, and the optional post_id behavior is called out explicitly.

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

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

It provides a concrete, actionable use case: Use status="PENDING" to find comments waiting for moderation. It does not explicitly name alternatives or exclusions, but the resource and scope are clear enough that an agent can decide when to call this tool.

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