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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful non-obvious context: results are masked/audit-safe identifiers only, and may include callback/A2P SMS status where present. This informs agents about output sensitivity without relying solely on annotations.

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?

A single, front-loaded sentence covers the action, resource, purpose, and return-characteristic in compact form. Every clause contributes information, with no filler or redundancy.

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 read-only list tool with two optional parameters and an output schema, the description covers the core purpose, result masking, and included status types. Minor gaps remain: 'recent' is not quantified, tenant_id scoping is unstated, and pagination/defaults are not mentioned, but annotations and output schema reduce the burden.

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 needed to compensate by explaining limit and tenant_id semantics, but it does not mention either parameter. The schema's min/max for limit and type for tenant_id are visible, but the agent gets no guidance on how tenant_id scopes results or what the default limit behavior is.

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 states a specific verb ('List'), resource ('AI Receptionist call-loop receipts'), and audience ('for human review'), making it clear this is a queue/listing tool. It also adds distinguishing detail by mentioning callback and A2P-gated inbound SMS status, separating it from sibling packet/status tools.

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?

The phrase 'for human review' implies when the tool is appropriate, but the description does not explicitly contrast it with siblings like ai_receptionist_callback_packet or ai_receptionist_status, nor does it state when not to use it. Usage context is clear but alternatives are not addressed.

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