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

Annotations only declare write/non-destructive/non-idempotent; the description adds substantial context beyond them: evidence 'enters quarantine for verification', the receipt 'grants no publication authority', and collection is gated. These are the genuinely useful facts an agent needs before writing. It stops short of describing what a successful call returns or whether resubmission duplicates data — consistent with idempotentHint=false but never stated.

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 action and its bounds are front-loaded in the first sentence, and the remaining sentences are short and each carries a distinct constraint (consent, exclusions, quarantine, gating). A few phrases are compressed to the point of jargon ('release gates', 'signed research receipt'), but 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 tool with a deeply nested schema, no output schema and no field documentation, the description leaves an agent unable to construct a valid payload: fact_type variants, source_url/observed_at requirements, and business_id vs. location_id are all unaddressed. The governance context is thorough, but the operational context needed to actually call it is missing.

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% and the schema's eight fact_type variants (hours, menu_item, service, capability, price_band, phone, website, permanent_closure) along with required source_url and observed_at are explained nowhere. The description does hint at the receipt and the five-finding cap, but it never mentions business_id or location_id, and its ban on 'availability' and 'item prices' sits awkwardly against the permitted capability.available and price_band variants.

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 ('Submit ... public business facts') plus a quantity bound ('up to five') and the receipt requirement, so an agent knows exactly what action this performs. It never names the neighboring write tools (submit_verified_review, report_action_outcome, update_hours), so differentiation from siblings is left to inference.

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?

'Ask the shopper before calling' is an explicit precondition and the content exclusions ('No personal information, availability, item prices, HTML or instructions') bound what may be submitted. However, there is no guidance on when to prefer this over sibling submission tools, and 'Collection is off until release gates are satisfied' suggests the tool may be unavailable without saying how the agent should detect or react to that state.

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