CXH AUTO 车小花 · 中国新车与二手车行情

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

Annotations already cover read-only, idempotent and non-destructive status, but the description adds real behavioral context the annotations cannot: no price lookup, no quota consumption, no acquisition initiated, and deterministic plain arithmetic. The remaining gap is that it never says what the result looks like or in what unit it is returned, though the integer-fen convention for inputs makes that largely inferable.

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?

The precondition and the required-input rule come first, followed by per-parameter caveats and then a boundary statement, so the most decision-relevant information is front-loaded. The text is dense and largely waste-free, though the asking_fen and resale_drop_fen sentences repeat the 'only when the user explicitly states it' pattern and could be tightened.

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 arithmetic tool with no output schema, the description supplies units, requiredness, preconditions, optional-parameter restrictions and scope boundaries, which is close to everything needed to call it correctly. The only missing piece is how asking_fen and resale_drop_fen affect the computed ceiling, which would let an agent predict the result rather than just supply inputs.

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 0%, so the description carries the burden and does so for all five fields: it fixes the unit ('所有参数为整数分'), marks the three money inputs as mandatory, and constrains the two optional ones (asking_fen is the user-selected quote only; resale_drop_fen is a user-stated resale reduction, not a default new-car pass-through). It stops short of stating how asking_fen and resale_drop_fen enter the formula, which is the one semantic detail a caller might still want.

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 opening sentence gives a concrete verb and output (测算收车上限) plus the three inputs that must be present (预期实际卖价、总成本、目标利润), so the agent knows exactly what this computes. The closing line '此工具只做条件算术，不查价、不扣次数、不发起收购' further separates it from pricing-lookup siblings like compare_quote, search_quotes and get_market_card.

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?

It names a gating condition ('车商明确提供…时'), an alternative action when inputs are missing ('缺项先询问'), and explicit exclusions for two optional parameters (asking_fen only when the user explicitly selected a quote; resale_drop_fen only when the user specified a drop, with no assumption that new-car discounts pass through proportionally). These are concrete when-to-use and when-not-to-use rules rather than implied guidance.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds two things annotations cannot: that the call '共用查询计次' (shares the query quota/count), which is real cost information, and that it does not infer transaction price, inventory, or fair valuation, which bounds what the results mean. It does not describe the response shape, but the behavioral additions are substantive.

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?

A single compact sentence with the comparison target stated first and the caveats after, so it is front-loaded and wastes nothing. The compression costs a little clarity, since '共用查询计次' is terse enough to be ambiguous about exactly what quota is consumed.

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 tool with a nested sixteen-field query object and no output schema, the description covers scope, cost, and output boundaries but says nothing about what a comparison result actually contains (per-record deltas? aggregates? ranking?). It is adequate to decide whether to call the tool, but not to anticipate the response.

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 effectively near zero across a nested query object with roughly sixteen filter fields, so the description has to compensate. It does clarify the highest-value item, that offered_price_fen is the user's price in fen, and implies the query object reuses the same query semantics as the sibling search. The many optional filters (time_basis, max_age_days, mileage and price ranges, limit) get no explanation beyond their names, leaving most of the schema opaque.

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: compare the user's offered price (in fen) against per-record entries from the same query. That is more precise than a tautology and tells an agent this is a benchmarking/comparison operation rather than a search. It stops short of naming how it differs from siblings like search_quotes or review_quote_source, so differentiation is left to inference.

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: you call it when you have a user's offered price and want to see how it stacks up against comparable records. The clause '不推算成交价、库存或公允估值' functions as a partial exclusion, telling the agent not to come here for valuation or inventory questions, which pushes it above a pure 2. There is still no explicit when-to-use versus search_quotes or calculate_purchase_budget.

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

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

Annotations already cover read-only, idempotent and non-destructive, and the description adds real behavior: OAuth continuation through the current client, vehicle model preserved, no automatic replay of the price query, no credit deduction, no proof of same account as another web session, and no phone number/verification code/secret needed. The only blemish is the reference to 'query_allowed', a field that appears in neither the input schema nor any output schema, which leaves the agent guessing where that flag comes from.

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-dense but poorly structured: multiple semicolon-joined clauses mix trigger conditions, auth mechanics, side-effect guarantees, and downstream query-replay policy into a single block. Cramming post-call workflow rules into the description makes it harder to front-load the core action.

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?

Given no output schema, the description usefully says what is returned after authorization (current membership and trial status only, nothing replayed). The undefined 'query_allowed' flag is the main completeness gap, since the agent cannot tell whether it comes from a prior tool result or must be inferred.

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?

There is a single parameter, mode, whose only allowed value is 'account'; the description confirms it is fixed to 'account', which is mildly useful reinforcement of the enum. Schema description coverage is 0%, but with one enumerated parameter little compensation is needed. No added syntax or format detail beyond the enum itself.

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: connect the user's 车小花 account via the current client's standard OAuth, with mode fixed to 'account'. It is distinguishable from siblings like search_quotes or get_access_status, though the purpose is wrapped in a long run-on sentence that also covers downstream query-replay rules.

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?

Explicitly names the triggering conditions (user says they are logged in, are a member, or want to connect their own account) and an explicit exclusion (do not call on the first free price check). It also states the follow-up rule ('do not fall back to public search', 'deliver the benefits entry point'), so the agent knows both when to call and what not to do afterward.

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

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

Beyond the readOnlyHint/idempotent annotations, the description discloses consequential behavior: verification does not grant authorization and does not consume price-query quota, the generated instruction is valid for 10 minutes, and continuation requires matched and query_allowed. That is real operational context an agent could not infer from the annotations. Everything else about return values for the plain entitlement path is left implicit.

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 short sentences, each carrying a distinct decision rule, with the most consequential routing rule (use get_market_card instead) front-loaded. No filler or restated boilerplate.

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?

The branching logic and side-effect profile are well covered for a two-parameter tool, and no output schema exists that could offload the return description. However, what the plain entitlement lookup returns (which entitlement fields, what an unentitled result looks like) is never described, so an agent knows when to call it but not exactly what to expect back.

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 0%, so the description must carry the burden and largely does: connection_check is the verification instruction to pass when one is received, and its matched/query_allowed outcomes determine whether to resume querying; issue_for_client requires a connected account and yields a 10-minute instruction. It does not explain the expected string format of connection_check or what the enum client identifiers mean, which keeps it from a 5.

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 opening clause '只查权益才单独调用此工具' identifies the resource (entitlement/rights status) and the calling mode (standalone check), and it immediately contrasts this with the sibling get_market_card. The purpose is clear enough to select the tool, though the description never plainly states what the default no-argument call returns, so it is a step short of a crisp verb+resource definition.

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?

Explicit routing rules are given: call this alone only to check entitlements, and if the user supplied a vehicle model and wants to continue, call get_market_card directly instead. It also names the trigger for each parameter path (a received verification instruction, or a user explicitly wanting to verify another agent) and the prerequisite for issue_for_client (a connected account). Alternatives and exclusions are both spelled out.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The one genuinely additive behavioral claim is '不扣次数' — the call has no quota cost — which is not expressed in any structured field. Beyond that, freshness/latency of the returned metadata and the response shape are undisclosed.

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?

A single compact sentence with the payload (what metadata is returned) first and the cost qualifier second. Nothing is repeated and no words are wasted.

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 zero-parameter, read-only tool with no output schema, naming the four returned categories (data source, time window, coverage, limits) plus the billing behavior gives an agent enough to decide whether the response answers its question. It falls short of complete only in not stating how the metadata should influence subsequent calls.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No misleading hints are given about inputs.

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 names a concrete resource set — real-time data provenance (数据来源), time window (时间口径), coverage and limits (覆盖与限制) — so an agent knows this returns metadata about the data rather than the data itself. It is not explicitly distinguished from the adjacent sibling get_access_status, which is the only thing keeping it below a 5.

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: '不扣次数' signals the call is free, which encourages calling it before expensive analysis, but there is no explicit 'call this when...' or 'do not use this for...' statement. The overlap with get_access_status (access/entitlement) versus this tool (data coverage/limits) is left for the agent to infer.

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

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

Annotations only cover the read-only/idempotent safety profile; the description adds cost behavior (no credit deduction, free selection card, free catalog verification), default 365-day history, what a result contains (wholesale, retail, and new-car risk reference, delivered as a native card rather than HTML), and the special account_connection_required delivery path. None of that is derivable from the annotations, and nothing contradicts them.

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?

The key routing rule is front-loaded, which is good, but the body is a dense run-on block that interleaves parameter guidance, fallback behavior, delivery format, and terminology rules (product naming, 'not non-store quote' phrasing). Several sentences serve presentation policy rather than tool selection, and the lack of structure makes the operative instructions harder to extract.

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 nested-schema, no-output-schema tool, the description covers the important behavioral contract: default history window, no-guess fallback, card delivery, and account-connection handling. It is only incomplete on the many numeric/filter fields inside `query`, which an agent would have to infer from names alone.

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 0%, so the description must carry parameter meaning. It does explain `vehicle` (brand+series or hints like C300), that all explicit conditions go in `query` and no model_id is passed, how `trim` accepts user configuration hints, and the 365-day history default. But city, province, model_year, price/mileage ranges, limit, time_basis, max_age_days, and response_mode are left entirely undocumented, so the compensation is only partial.

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 action chain: auto-identify the real model ID, match existing model-year trims, and query market prices in one call. It also explicitly names the sibling tools it replaces (resolve/choices/capabilities/access), so an agent can tell this apart from those tools 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?

It says explicitly not to pre-call resolve/choices/capabilities/access, tells the agent what to put in `vehicle` versus `query`, and states that ambiguous or multi-candidate input returns a free selection card instead of guessing. That is when-to-use, when-not-to-use, and fallback routing all in one place.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds two useful non-obvious traits: it will not generate forward-looking predictions and it does not consume quota/credits. It leaves the async polling semantics vague, e.g. whether a not-yet-finished job returns partial progress or requires re-calling.

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?

A single front-loaded sentence with semicolon-delimited clauses, each carrying a distinct fact (what it reads, the precondition, and two exclusions). Dense but no filler; a slightly clearer separation of the two return modes would improve it.

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 one-parameter read-only retrieval tool with annotations and no output schema, the description states scope, precondition, and exclusions well enough to invoke it correctly. The remaining gap is what the agent should expect back (analysis payload vs. progress state) and how to handle an incomplete or expired job.

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 one parameter and 0% schema description coverage, the description carries the burden; it does clarify that job_id must already exist, implying provenance from a prior query, which is genuine added meaning. It does not describe the format, lifetime, or validity of job_id, so compensation is partial.

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 definition opens with a specific verb (读取/read) and a concrete resource: the historical analysis for a market quote the user just queried, or the supplementary-collection progress for public quotes. It does not, however, name the sibling that actually initiates such a job (e.g. search_quotes or get_market_card), so an agent must infer where job_id comes from.

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 clause '仅已有job_id' gives a real precondition: call this only after a job already exists, i.e. for polling or retrieval rather than initiating. Beyond that it gives no explicit alternative or when-not guidance, and it never points to the tool that creates the job, so the routing decision is only implied.

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

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

Beyond the readOnly/idempotent annotations, the description discloses non-obvious behavior: a 60-second fresh cache, serving cache for up to 5 minutes with background refresh, an optional force_refresh, quota not re-charged when switching model years, and card-first delivery with no local files, no shell commands, and no HTML generation. These are genuinely useful disclosures. The only weak spots are the vague closing clause about future values being published only after validation.

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?

The text is one dense block of semicolon-separated clauses that leads with low-level parameter constraints instead of the tool's purpose, and it mixes schema rules, caching behavior, and output formatting without headings or ordering. The content is largely substantive, but the lack of front-loading and structure forces the reader to parse the whole paragraph to extract the call contract.

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 complex nested-schema tool with no output schema, the description covers the essentials: what is returned (quotes, years, history distribution, interactive card), how compact versus full responses differ, and freshness and caching semantics. That is enough for an agent to call it correctly, though the return shape details are conveyed loosely rather than systematically.

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 on a 14-property nested object, the description compensates substantially: it explains the query nesting rule, that history_days and response_mode sit at the outer level, that city and province are mutually exclusive and must not be null, that numeric fields take integers, that trim must be the full string from get_vehicle_choices including the year prefix, and what compact versus full return. It still leaves limit, the price and mileage ranges, time_basis, and max_age_days unmentioned.

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 concrete verb and resource set: return recent quotes, selectable model years, and a real historical weekly quote distribution over 7–365 days, plus a native interactive card. That makes the tool distinguishable from get_market_insight and compare_quote. However, this purpose statement is buried after several clauses of parameter constraints, so an agent must read to the middle of the paragraph to learn what the tool actually does.

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?

It gives real routing guidance: do not repeat a query for a second price column, prefer response_mode=compact in conversation but use 'full' when per-item full text is needed, use delivery_status to avoid redundant queries, and use get_vehicle_choices for the complete trim string. It does not explicitly say when to choose this tool over get_market_card or search_quotes, so sibling differentiation is only partial.

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

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

Annotations already cover read-only, idempotent, closed-world, and non-destructive behavior. The description adds useful context beyond that: free, no query-count deduction, source types, two-step selection, and explicit limits about prices and inventory.

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?

The paragraph is compact and front-loads the return scope, then workflow, exclusions, and cost. The cost point is split across 免费 and 选车不扣查询次数, a minor redundancy, but overall efficient.

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 explain the two-stage return of years then trims. However, for a nested input object with many filters and required enum fields, it leaves parameter usage and return structure underspecified.

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 0% and the description does not explain the nested query fields, including required model_id, business_type, and price_kind, or optional city, trim, mileage, and year filters. The mention of 年款 and 配置 only loosely hints at model_year and trim and does not compensate for the documentation gap.

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 the tool returns model years and trims from recent records, public references, and catalog, and explicitly limits it to vehicle selection with no prices. That scope distinguishes it from quote-oriented siblings such as search_quotes and compare_quote.

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?

It gives a clear workflow: show model years first, then read full trims for the selected year, and it excludes pricing and proof of local inventory or recent quotes. It does not name the alternative sibling tools to use when pricing is needed.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description is not needed for basic side-effect disclosure. It still adds real value beyond them: it tells the agent that the call reuses the original membership / successful-query count (a billing/quota consequence that appears nowhere in structured fields), and restates no-subscribe/no-charge/no-message as the explicit guarantee.

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?

One tightly packed sentence with the verb and resource front-loaded and the no-side-effect guarantee trailing as a qualifier — no filler. It is arguably undersized for a fifteen-field nested filter, but that shortfall is better attributed to completeness than to verbosity.

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 tool whose input is a nested fifteen-property query object with enums and no output schema, the description says nothing about what comes back (quote list shape? limit semantics?) or how the filters interact. The only contextual support is the read-only annotations and the quota-reuse note, which is not enough for an agent to construct a correct query without opening the 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?

The schema is a single required nested `query` object with roughly fifteen properties and effectively no descriptions, so the description carries the burden of explaining fields like time_basis, max_age_days, price_kind, mileage bounds, and limit. It explains none of them, adding zero meaning beyond the schema; only the schema's own price_kind description compensates for a small part of the gap.

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 (预览/preview) plus two concrete resources — the watch (盯车) conditions for the current model and the matching quotes — and explicitly rules out creating a subscription. It does not, however, differentiate itself from the close sibling search_quotes, which an agent could easily confuse with a quote-matching preview.

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?

Implied usage is clear enough: call this to inspect what a watch would produce before committing. The clause '不创建订阅、不收费或发送消息' signals it is a safe pre-check rather than a commitment, but no alternative tool is ever named, so the agent must infer the boundary with search_quotes on its own.

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

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, and the description does not contradict them ('识别' is a read/lookup). It adds genuinely new behavioral context beyond annotations: the operation is free of charge, the resolver must not fabricate or strip model-year prefixes, and ambiguous variants require clarification. It does not describe what a successful match returns or how failures are surfaced.

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?

The purpose is front-loaded in the first clause, which is good, but the remainder is a semicolon-chained stream of workflow rules with no separation between purpose, preconditions, and clarification policy. Every rule is arguably relevant, but the run-on packing makes it harder to scan than a structured list.

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 resolution tool with no output schema and an undocumented input, the description should cover both the input shape and the shape of a result. It partially compensates by explaining the location_choice_required outcome state and the clarification path, but never tells the agent what a successful match looks like or how to interpret a partial match.

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 0% and the single parameter 'text' is never named or explained in the description. The agent must infer from '识别用户地区与车型' that text carries the user's free-form region/model utterance. With a 1–100 character constraint and no format guidance, the description leaves the key input under-specified.

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 opening clause '免费识别用户地区与车型' gives a specific verb (识别/resolve) plus two resources (region, vehicle model) and adds the differentiating trait that it is free. It also names the sibling get_vehicle_choices as the required next step, so an agent can position this tool in the flow. The purpose is slightly buried under procedural rules, keeping it from a 5.

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?

It gives explicit conditional guidance: verify with get_vehicle_choices after matching, select a specific region first when location_choice_required, keep province conditions, and ask for clarification on imported/domestic/new-energy ambiguity. These are strong when-to-do-what rules. There is no guidance on when NOT to use this tool or which other siblings (e.g., compare_quote, get_market_card) should be called instead.

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

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

Beyond the annotations (readOnly, non-destructive, idempotent, closed-world), the description adds billing behavior (valid members read on demand, no trial deduction), membership gating, and the precise semantics of the public_record_matched result field. It also conditions the cross-app jump on the user having opened original_page, all of which an agent could not infer from structured data.

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?

The trigger condition is front-loaded and each sentence adds distinct information (trigger, input provenance, billing, result semantics, jump restriction). Some sentences are long run-ons with multiple clauses, but none are pure filler.

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?

The tool has two params, no output schema, and annotations covering safety, and the description covers the missing pieces: input provenance, membership/billing effects, and the meaning of the key result field. What remains thin is the shape/format of the inputs and any behavior for invalid or expired references.

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 0%, so the description must carry the meaning. It successfully establishes that reference is an opaque identifier from a prior 车小花 response that must not be fabricated, and ties quoted_at_ms to the original quote row. It does not clarify the timestamp unit/format or the 28-character reference shape, so it does not fully 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?

The description opens with an explicit trigger and a specific verb-resource pair: verifying whether a peer used-car quote is still linked to the original listing and whether the original listing's price has changed. This is clearly distinguishable from siblings like compare_quote and search_quotes, which handle comparison and listing rather than linkage verification.

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?

It states when to call (a dealer explicitly wants to check a specific row's linkage/price change) and gives a hard constraint: pass only the reference and quoted_at_ms already returned by 车小花, never guess the ID. It also notes that quotes without an original-listing link are for reference only, implying they are not valid verification targets. No sibling tool is named as an alternative for adjacent needs, which keeps it short of a 5.

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

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.