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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds behavioral details about cursor pagination and the exclusion of addresses for performance, going beyond the annotations without contradicting them.

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 three sentences, direct and free of fluff. It efficiently states the action, the response characteristics, and the alternative tool, with no redundant information.

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?

For a simple list tool with optional pagination, the description covers the core purpose, pagination behavior, response shape (lightweight, excluding addresses), and when to use a different tool. With an output schema present, the context is complete without over-explaining.

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?

Both parameters (limit and cursor) have clear descriptions in the schema, giving 100% coverage. The tool description does not add extra semantics beyond the schema, but it does reinforce the pagination concept, so the baseline of 3 is appropriate.

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 clearly states the tool lists agents in the current account context with cursor pagination, and distinguishes itself from agent_get by noting it returns lightweight records without addresses. This gives a precise, unambiguous purpose.

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?

Explicitly directs users to agent_get for full single-agent detail, indicating when not to use this tool. It also explains the lightweight response is intentional to avoid N+1 round-trips, providing context for when this listing is appropriate.

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