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

Annotations only cover readOnly/openWorld/idempotent flags; the description adds the re-verify window, the attempts_exceeded/resend_after rate-limiting concept, the rule that human_email is editable only pre-verification, the escalation to support after one retry, and what the email does and does not contain (no price or payment link). That is substantial context beyond structured fields.

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?

Purpose is front-loaded and each clause does work (trigger, timing, edit constraint, escalation, email content). The single dense paragraph makes the operational instructions harder to scan than bullet-style structure would.

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 stateful, side-effecting send step with no output schema, the description covers what happens, when it must happen, failure recovery, and what the recipient receives. The remaining shortfall is undocumented required parameters, which matters given zero schema coverage.

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?

With 0% schema description coverage the description must carry parameter meaning, but it only explains human_email ('may be corrected only before it is verified'). request_id, request_capability, and idempotency_key are never characterized, so an agent must infer their purpose from naming alone.

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?

States a specific verb+resource: 'Send (or resend) the one-time code that verifies the person's email for this request.' The send-vs-verify distinction is unmistakable against the sibling verify_email, and the parenthetical clarifies the resend case.

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?

Explicit trigger: 'Use when next_action is start_email_verification' followed by the exact state enumeration (not_sent, unavailable, expired, replaced, attempts_exceeded after resend_after). It also states the lifecycle points where it is required (before the sample, again before payment if older than the re-verify window).

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