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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, leaving the real behavior to the description — which delivers: a 3-free-checks-per-UTC-month quota, an explicit statement that pasted quote text is used for this check only and never stored, and a mapping to POST /api/quote-check. What is not disclosed is what a quota-exceeded response looks like or whether the call is billable beyond the free tier.

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?

Four tight sentences, front-loaded with the action and the return shape, then the input contract, then the quota. The trailing "Same as POST /api/quote-check" earns little for an agent choosing a tool, the only real slack in an otherwise dense description.

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?

No output schema exists, and the description does compensate by naming the return fields. However, with 10 optional parameters and zero required ones, it never says what happens on an empty or under-specified call, nor which combination unlocks the richer text-parsing path versus the numeric path.

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 50% schema coverage across 10 parameters, the description usefully surfaces the either/or input contract (paste, or selling_price plus msrp) that the schema's zero-required-params shape does not express. But vin, make, model, trim, year, and invoice get no mention, so roughly half the surface remains undocumented in both places.

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 ("Check a car dealer's quote") and enumerates the return payload: an A–F grade, flagged fees/add-ons, and dealer-ready lines. It does not differentiate from the sibling score_deal or explain_grade, so an agent cannot tell from this text alone which of the three scoring-adjacent tools to pick.

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?

"Pass paste ... or selling_price and msrp" gives input-selection guidance rather than usage guidance, and the quota line adds a constraint. Nothing says when to choose check_quote over score_deal or explain_grade, so the usage context is only implied by the tool name.

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