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

Annotations already declare non-read-only, idempotent, open-world, non-destructive. The description adds real value beyond them: it confirms retry safety via key reuse and explicitly discloses that no payment, worker hire, or fulfillment commitment is created as a side effect. It still does not describe the resulting state or lifecycle of the request, so it stops short of a 5.

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 short sentences, zero filler, with the core action and scope front-loaded before the retry rule and the negative side-effect clause. Every sentence carries distinct information.

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?

With no output schema, the description needn't explain returns, and the side-effect disclaimer is a helpful addition. But for a six-parameter create tool with 17% schema coverage and no enums, the missing semantics for location, objective, deadline, constraints, and evidence_requirements leave an agent guessing at required input quality. Adequate but incomplete.

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%, so the description must carry the burden, yet it explains only idempotency_key (and that explanation duplicates the schema's own description of that field). The required location and objective, plus deadline, constraints, and evidence_requirements, are given no meaning, format, or examples anywhere. 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?

The description gives a specific verb (create) and resource (physical verification request) plus qualifying scope: retry-safe, manual-review, Japan. It does not name a sibling, but the phrase 'no payment, worker hire, or fulfillment commitment' implicitly separates it from prepare/fulfillment-style tools. Clear enough to distinguish the operation without opening the schema.

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 retry condition is explicit ('Reuse the same idempotency_key for the same logical request'), which is genuinely useful when guidance. However, it never says when to choose this tool over prepare_verification_request or check_service_fit, nor does it state prerequisites or when not to use it. Usage is implied rather than routed.

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