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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds genuinely useful behavior beyond them: the quote may be incomplete, pricing fields only exist 'once complete,' and required_disclosures must be shown verbatim before any purchase. However it does not disclose failure modes — what is returned for an expired or unknown quote_id, or whether quote data changes over time — which matters for an agent deciding whether to re-fetch.

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 purpose sentence is buried under a fragmented opening, and roughly two-thirds of the text is an inline legal copy of eleven disclosures that duplicates the required_disclosures field the tool already returns. That list is long, will go stale ('Currently:'), and consumes context on every call regardless of whether a purchase is being made.

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?

The description covers what is returned, the prerequisite workflow, and the pre-purchase disclosure obligation, which is substantial for a one-parameter read tool with no output schema. It omits the incomplete/expired quote case and any guidance on caching or re-fetching, so an agent still lacks a full picture of the tool's lifecycle behavior.

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 100% and the schema already states 'The quote_id create_quote returned.' The description's mention of create_quote echoes that without adding format, lifetime, or validation meaning, so the baseline of 3 applies.

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 opens with a noun-phrase fragment ('The quote's status and, once complete, its pricing, checkout_url, purchase_options and required_disclosures') rather than a verb+resource statement such as 'Retrieve a Premium Lock quote by id.' The resource is identifiable and it names the return fields, but the agent must infer that this is a read of an existing quote from create_quote, and there is no explicit differentiation from siblings like purchase_quote or complete_purchase.

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?

It gives concrete sequencing: first collect the consumer's email, then look for a declarations page and route it to read_declarations_page, otherwise collect fields for create_quote, and it anchors quote_id to create_quote's return value. It stops short of saying when NOT to call it (e.g., when a quote_id is unknown or the quote is expired) and never explicitly contrasts it with purchase_quote or complete_purchase.

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