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

Annotations already mark this as a read-only, idempotent, non-destructive call, and the description adds substantive behavior beyond them: results are estimates only and nothing is booked, some routes return no price and offer a callback instead, and the response shape (route, driving miles, low-first price range, delivery window, exact-price link) is characterized. The partial-failure path is the kind of trait an agent cannot infer from structured fields and genuinely changes how it should report results.

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?

Information is front-loaded: when to use, then inputs, then returns, then edge cases, then exclusions. There is some redundancy - 'interstate moving, cross-country moving, moving a 1-4 bedroom home or studio to another state' restates the same scope, and the quoted 'how much to move my house or apartment' sentence partly duplicates the opening - but the phrasing serves intent matching rather than padding.

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?

For a five-parameter estimation tool this is complete: inputs, output contents, the no-quote callback branch, the non-binding disclaimer, the large-home workaround, and the three excluded scenarios are all covered. An output schema exists, so the description's return-value summary is a bonus rather than a necessity.

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?

With 0% schema description coverage, the description carries the full burden and largely succeeds: origin/destination accept city+state or ZIP, size accepts studio or 1-4 bedrooms, first_available_date is optional and YYYY-MM-DD, and cubic_feet is the escape hatch for 5+ bedroom homes. The remaining gap is that no exact string format for 'size' is given (e.g. '3' vs '3 bedrooms') and the defaults for size/cubic_feet are not addressed.

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 specific verb and resource - estimating the cost of a long-distance interstate household move - and immediately delimits scope ('between two US states with Cross Country Movers'). It explicitly distinguishes itself from named siblings (get_quote for car shipping, get_international_quote for non-US moves) and from local moves, so an agent can route correctly 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?

Both the positive case ('how much to move my house or apartment to another state') and the negative cases are spelled out with the alternative to use instead: local/in-state moves, car shipping via get_quote, and non-US moves via get_international_quote. The guidance is prescriptive rather than implied.

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