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

Annotations already flag a destructive, non-idempotent, open-world write, so the baseline is low. The description still adds real behavioral context the annotations lack: that Google sends a code to the owner and that verification is not instant, which sets expectations about downstream steps and timing. It does not state whether restarting an already-started method overwrites or errors, which idempotentHint=false hints at but doesn't clarify.

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?

Two tight sentences, front-loaded with the action and the enumerable choices, with no filler. The closing caution about not promising instant verification is an agent-facing instruction rather than a tool fact, but it earns its place by preventing a common miscommunication.

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 destructive, non-idempotent write with 6 parameters and no output schema, the description covers the high-level flow and the timing expectation but leaves the per-method parameter requirements and the return payload (what identifier or state the caller gets back) entirely unexplained. Adequate to start the call, not adequate to call it confidently with a specific method.

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 only 33% — only site_id and user_goal are documented. The description repeats the method enum (already in the schema) but says nothing about email, phone_number, or mailer_contact, including which of them is required for which method, which is the key ambiguity in a 6-param tool.

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 gives a specific verb ('Start') plus the exact resource (a Google verification method) and enumerates the five valid methods, so the agent knows precisely what action is taken. It implicitly separates from get_google_verification (status read) and complete_google_verification (finishing), but does not name either sibling 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?

The description frames this as beginning one of the methods 'Google offered', which implies the method set must already be known. It gives no explicit precondition (e.g., call get_google_verification first) and does not route the agent away from complete_google_verification when a code has already been received.

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