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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces the retry contract while adding genuinely new context: the request is 'manual-review' and no payment, worker hire, or fulfillment commitment is triggered. That side-effect boundary is exactly the kind of disclosure annotations cannot convey.

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?

Three tight sentences with no filler, front-loaded with the core action and followed by the retry rule and the side-effect boundary. Nothing is redundant.

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 create tool with no output schema, the description adequately covers the idempotency contract and mutation scope, but with 17% parameter coverage it leaves the agent guessing about what location, objective, and evidence_requirements should contain. Minimal but not sufficient for a tool with six parameters.

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 17% (just idempotency_key), and the description covers only that one parameter's reuse semantics. location, objective, deadline, constraints, and evidence_requirements are left entirely undefined in both schema and prose, so the description does not compensate for the coverage gap.

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 and resource ('Create a ... physical verification request') with scope qualifiers ('manual-review', 'in Japan'), which clearly separates it from prepare_verification_request and cancel_verification_request among the siblings. It stops short of explicitly naming a sibling to route against, so it lands just below the top tier.

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?

Gives one concrete operating instruction ('Reuse the same idempotency_key for the same logical request'), which implies retry usage, but offers no when-to-use guidance relative to prepare_verification_request or when not to call it. The 'no payment... created automatically' line sets expectations rather than selection criteria.

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