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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not carrying the safety burden. It does add genuinely non-derivable behavior: results are non-binding Safe Rate estimates rather than lender quotes, and the response contains an estimate ID the borrower can use to track changes later. It does not mention the ok:false / missing-parameter return path that the schema documents, but that is a schema-side disclosure.

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?

Two sentences, zero waste, with the scope and PII constraint front-loaded ahead of the estimate-vs-quote caveat. Every clause carries information an agent needs before calling.

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 8 optional parameters fully documented in the schema and no output schema, the description covers the essentials: what is returned conceptually (estimates plus an estimate ID) and what the numbers legally are. It stops short of describing the shape or richness of the rate results, which an agent might want given there is no output schema.

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%, including defaults, enum values, and elicitation behavior for location and purchase_price, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond the schema — no guidance on which combinations matter or how inputs affect pricing.

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 states a specific verb and resource — 'get live mortgage rate estimates for any US location' — plus the PII-free condition that defines this tool's scope. It implies a boundary with the sibling get_my_quotes (this returns estimates, not the borrower's own quotes) and with track_quote_estimate (the returned estimate ID is what feeds tracking), but it never names those siblings explicitly.

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?

Usage is only implied: the reader can infer this is the anonymous pre-application pricing path and that the returned estimate ID routes to tracking, but there is no explicit 'use this when X, use get_my_quotes when Y'. No prerequisites or exclusion conditions are stated, so the agent must infer selection against a large sibling set.

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