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

Beyond the readOnly, idempotent, and non-destructive annotations, the description adds important behavior: it spends no verification credits, returns success/verifying/queue states, enforces polling limits, retains results for 90 days, and never starts another verification.

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 front-loaded with the core action and cost behavior, then adds polling, retention, and no-new-verification constraints. Every sentence provides useful operational context without repetition.

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 single-status read tool with annotations covering safety and no output schema, the description is complete enough. It explains the returned status values, polling behavior, credit impact, retention window, and that it will not initiate a new verification.

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 single id parameter relies on the description for meaning. The description clarifies that id refers to an existing single verification, but it does not explain where to obtain the ID or address the schema's format constraints such as pattern and maxLength.

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 and resource: read an existing single verification ID. It distinguishes this from starting a verification by saying it never starts another verification, which helps separate it from siblings like bounceban_verify_email and bulk 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?

It gives clear polling guidance: honor try_again_at, poll no more than 10 times within 5 minutes, then stop. It implies this is for checking an existing verification rather than creating one, but it does not explicitly name the sibling tool to use when a new verification is needed.

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