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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful cost semantics — free quota is consumed only when results are successfully returned — and notes that merchant_quote supports only record_created and that location is taken from the native source with missing fields retained. It says nothing about result size limits, ordering, or the shape of returned quotes.

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 compact sentences with the resource and the two source modes front-loaded, followed by constraints and then billing. Every clause carries information; the only structural weakness is that source-mode constraints and billing are packed into one run-on sequence rather than separated.

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 single required wrapper object that nests sixteen mostly undocumented properties with no output schema, the description is too thin. It never explains how model_id is obtained (presumably via resolve_model), what business_type or limit do, or what a result contains, leaving the agent to guess on a fairly complex query tool.

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 coverage is effectively 0% for a nested object with roughly sixteen properties, so the description must carry the load. It meaningfully constrains price_kind (seller vs merchant wholesale), ties time_basis to the source (merchant_quote only record_created), and explains location fallback behavior, but leaves model_id, business_type, trim, limit, price/mileage bounds and registration filters entirely to the bare schema.

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?

"查近期新车/二手车报价" names a specific verb (query) and resource (recent new/used vehicle quotes) and immediately splits the resource into the seller_quote and merchant_quote source types. It does not, however, distinguish itself from siblings such as compare_quote or get_market_card, so an agent must infer the boundary between quote retrieval and quote comparison/market analysis.

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?

The description gives concrete routing guidance inside the tool — merchant_quote is peer wholesale only, and storefront discounts or retail listings must use seller_quote — which prevents a common misclassification. It offers no when-to-use/when-not guidance relative to the sibling tools (compare_quote, review_quote_source, get_vehicle_choices), and no prerequisite or fallback path is stated.

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