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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: the distinct state branches (domain proof vs. draft vs. accepted terms vs. published URL, including the in-flight update case) and the contents of the revision digest (facts, company statements, what ACI verified, open questions). It stops short of documenting pagination, error states, or the fact that the token must come from a prior request.

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?

Front-loaded with the core purpose, and every clause carries content — the state enumeration and the approval instruction are both useful. It is, however, a single heavily nested sentence with stacked parentheticals that costs the reader some parse time.

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 usefully covers what comes back and gives the downstream user-facing step, which is most of the burden for a read tool. The remaining gap is the input side: three required, undocumented parameters leave the agent guessing how to construct a valid call, which for a 3-required-param tool is a meaningful shortfall.

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 all three parameters (reference, listing_token, schema_version) are required with no descriptions anywhere. The description never explains what 'reference' identifies, whether listing_token is single-use, or what schema_version must be, so an agent has no help beyond the bare field names.

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 ('Read the state of a listing request') and enumerates the distinct states it can return, which separates it cleanly from approve_listing, request_listing, and verify_listing_domain. An agent can tell this is the polling/inspection tool for the listing workflow without opening any 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 description implies when the tool fits ('and what to do next', plus the instruction to show the draft and Listing Terms before asking for approval), which is real workflow guidance. However, it never names an alternative sibling or an exclusion condition (e.g., use get_offering for the offering itself, verify_listing_domain for the proof step), so relative routing is left to inference.

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