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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: the output contains an 'attributions' array and a professional-advice disclaimer that must be passed through to end users, and it warns that 'Review every included cost' matters. It doesn't say whether costs are estimated from defaults when fields are omitted.

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?

Three short sentences, front-loaded with the core action and followed by the two constraints that actually change behavior (rate assumption, attribution pass-through). No filler, though the 'Review every included cost' sentence is somewhat elliptical about what to review.

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?

An output schema exists, so return values needn't be spelled out, and the description wisely focuses on the pass-through obligations. But for a ten-parameter tool where most fields have silent defaults (20% down, 0.92% tax, 0.5% PMI), an agent gets no guidance on what happens when those are omitted — a meaningful gap for correct invocation.

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 only 20%, and the description mentions just four of the ten inputs (price, down payment, loan term, rate) with no added meaning beyond the field names. The other six — pmiPct, monthlyHoa, propertyTaxRatePct, annualPropertyTax, annualHomeInsurance and the down-payment default behavior — are neither described nor their defaults explained, and 'Review every included cost' is too vague to compensate.

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 — 'Calculate a monthly mortgage and housing-cost estimate' — and names the inputs it consumes. It is clearly distinct from the sibling tools (comps, net sheet, offer comparison), though it doesn't explicitly route to any of them.

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 implied: an estimate based on buyer-supplied price, down payment, term and rate. The caution that a rate is 'an assumption, not a live lender quote' frames the context well, but there is no explicit when-to-use/when-not guidance or named alternative (e.g. wa_net_sheet for full closing costs).

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