AutoIsto CZ

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

Annotations already declare a safe read-only, idempotent, closed-world operation, and the description layers on genuinely new behavior: what is returned (technical data plus the AutoIsto price verdict), what is deliberately withheld (seller name, phone, description, VIN, licence plate) and how to get it, plus the not-found signal ('found is false'). This is unusually rich disclosure for a read tool.

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?

Front-loaded with the trigger condition, then prerequisites, then return/withholding behavior, then the failure case. Every sentence carries distinct information (what, what not, where to get the alternative, error signal) with no 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?

For a single-parameter read tool with an output schema and full annotation coverage, the description closes the remaining gaps an agent would care about: id provenance, the exclusion list, the url fallback, and the found=false case. Nothing needed to call it correctly is missing.

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 100%, so the carId schema already carries the baseline. The description adds provenance semantics the schema does not: the id must come from search_cars results and must not be fabricated, which is real usage-critical meaning beyond the field definition.

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?

Specific verb + resource ('get details for one specific car'), and it immediately scopes what detail means (engine power, body, colour, price history, listing age). It distinguishes itself from the sibling search_cars by naming that it operates on one car returned by a prior search.

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 trigger ('when the user asks for more about one specific car returned by search_cars'), explicit prerequisite (car id from search_cars), and an explicit prohibition ('do not guess ids'). It also routes the user elsewhere for contact info (the car's url).

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 safety profile (readOnly, idempotent, non-open-world), so the description carries the substantive behavioral burden and does: it discloses that figures are omitted when samples are too small, that asking prices are not sale prices, that leaving the offer is not proof of a sale, and that mileage/equipment affect the figure. This is exactly the kind of caveat an agent needs to present results honestly.

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?

Dense and mostly front-loaded: trigger, then output contents, then caveats, then exclusions. Every sentence earns its place, but the single long paragraph packs return contents, caveats and exclusions together and could be slightly tighter for scanning.

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 need not be explained, yet the description still tells the agent which fields come back (median asking, median last, sample size, month) and how to frame them. Combined with the required-parameter rule and market scope, nothing needed to call it correctly is missing.

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 100%, so the schema already documents brand, model and year, including the model-variant collapsing note. The description reinforces the year requirement and the 'any mileage' scope of the asking price but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 precise verb+resource+scope: the median asking price and median last price for one brand/model/model-year in the Czech Republic. The scope constraints (whole-model aggregate, one year, Czech market only) implicitly separate it from search_cars and get_car_details, which deal with individual listings/details.

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?

Opens with an explicit trigger phrase ('Use this when the user asks how much...or whether a price is reasonable') and closes with explicit exclusions (not for a specific car's condition, new-car prices, or non-Czech markets). It also states the prerequisite: a year is required, and the agent should ask the user if missing.

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 establish the safe read-only, idempotent, closed-world profile, and the description adds substantial behavior beyond them: return of up to 10 cars with price verdicts, criteria-relaxation reporting, a notUnderstood list for unfilterable words, a link to all results, daily offer churn (cars may already be sold), and seat counts estimated for 6+.

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?

Front-loaded with the trigger condition and information-dense throughout; every sentence carries usable content (examples, body-type rule, ignored-word behavior, limits). It is a single long block rather than bulleted, which slightly hurts scanability but not substance.

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?

Despite the output schema existing, the description still summarizes the response shape and the relaxation/notUnderstood channels, and it covers limits, geographic scope, and data-freshness caveats. Nothing an agent needs to call this correctly appears to be missing.

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 100% and the schema documents format and length, yet the description adds real semantics: a single Czech/Slovak phrase, numbers as the user said them, prices in CZK, filler and equipment words ignored, and four worked examples that fully define acceptable input.

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 concrete verb+resource ('find a used car for sale in the Czech Republic') and enumerates the filterable dimensions (brand, model, body type, fuel, gearbox, year, price, mileage, power, seats, town/region). It also delimits its sources (AutoIsto listings plus Czech portals), which separates it from the detail and pricing siblings.

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 scoped with 'Use this when the user wants to find...' plus hard exclusions ('no new-car configurators, rentals, leasing offers or cars abroad'). It also gives the operational rule of one body type per call and tells the agent to split into two calls for two body types.

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