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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the description is free to add the things annotations cannot: the full status lifecycle (collecting through failed), the fact that results only exist once done, and that home quotes include a flood notice. It omits what happens on an unknown quote_id, whether results persist or expire, and any rate/polling expectations.

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 return contract, then the status vocabulary, then result contents — a sensible order for a polling tool. The closing clause "that belong with the prices" is grammatically awkward and slightly obscures whether the flood notice is separate or bundled.

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 carries the return-value burden and does so reasonably: results ordering, results_url, disclaimer, and the conditional flood notice are all named. It is nearly complete for a simple one-parameter read tool, missing only terminal-state behavior (failed/needs_info payloads) and error handling.

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 single quote_id parameter is never described — no format, no provenance (where the caller obtains it), no statement that an invalid id fails. The description only implies a quote is identified, leaving the one input's semantics entirely to inference.

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 (returns a quote's status and prices) plus the extra payloads it carries (missing fields, per-carrier prices sorted cheapest first). Read-versus-write is unambiguous against siblings like start_quote, submit_quote, and update_quote, so an agent can route to it 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?

Gives concrete user-intent triggers ("what would my insurance cost", "am I overpaying"), which is stronger than most polling tools. It never states when not to call it (e.g., that it only works on an existing quote_id from start_quote/submit_quote) or that it should be polled while status is in a non-terminal state.

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