AutoIsto

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

Annotations already establish readOnly/idempotent/non-destructive, but the description goes further by disclosing negative scope ('does not return the seller's name, phone, description, VIN or licence plate') and a success sentinel for stale data ('If the car is no longer in the offer, found is false'). This is the kind of behavioral detail the schema and annotations do not carry.

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 dependency, followed by returned/not-returned field lists and the not-found case. Every sentence earns its place, though the parenthetical field enumeration and the concatenated negation clause make it slightly denser than necessary.

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 summarizes them and flags the not-found shape. Combined with the id requirement and the explicit exclusion of contact fields, nothing an agent needs to call this 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% and the single carId param is documented there, so the baseline is 3. The description adds a genuine constraint beyond the schema by forbidding fabricated ids ('do not guess ids') and reiterating the provenance requirement, which reduces hallucinated-id calls.

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+resource ('get car details for one specific car') and immediately anchors it to the sibling that produces the input ('returned by search_cars'). It also enumerates the concrete payload (engine power, body, colour, price history, listing age), so an agent can distinguish it from get_model_price and search_cars 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?

Explicit about when to use it ('user asks for more about one specific car'), what it depends on ('Requires the car id from search_cars'), and what not to do ('do not guess ids'). It further routes the agent elsewhere for contact info ('for contact the user opens the car's url'), which is exactly the when-not guidance 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?

Beyond the readOnly/idempotent annotations, it discloses that the median is suppressed below 20 cars with a plain price, that returned figures are asking not sale prices, that mileage and equipment move the price, and that the response carries sample size, range and date. These are exactly the caveats an agent needs to avoid overclaiming precision.

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 use case, then output shape, then caveats, then exclusions — three tight sentences and a closing prohibition, with no filler. Every clause carries actionable content.

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?

Even though an output schema exists (so return details are optional), the description still names the returned fields and the small-sample suppression rule, closing the one gap an output schema could not convey. 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% and already documents brand, model and the year-needs-model constraint, so the schema carries the load. The description adds only a light touch ('optionally one model year') and does not extend the aggregation/version caveat beyond what the model field description already states.

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+resource with explicit scope: the median ASKING price of a brand/model (optionally one year) from AutoIsto's current Slovak offer. The 'asking, not sale price' framing and the Slovakia-only scope make it impossible to confuse with get_car_details or search_cars.

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 when-to-use ('user asks how much a car model costs in Slovakia, or whether a price is reasonable') paired with explicit exclusions ('not for valuing a specific car's condition, new-car prices or markets outside Slovakia'). The exclusions functionally route the agent away from the sibling get_car_details.

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), so the description goes well beyond them: it discloses the 10-result cap, that criteria are relaxed when nothing matches, that unrecognized words are surfaced in notUnderstood rather than applied, that a link to all results is returned, and that the inventory changes daily so listings may be sold. These are non-obvious behaviors an agent needs to interpret output correctly.

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 purpose and usage, and every section (format rules, examples, limits) is functional. It is on the long side for a single-parameter tool — four examples and two restated length/verbosity rules could be trimmed — but nothing is 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?

Given a one-parameter tool with an output schema, the description still supplies everything needed to call it correctly: intended input syntax, language, worked examples, the one-body-type constraint, exclusion guidance, result limits, and coverage boundaries. No material gap remains for an agent to act on.

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?

Although schema coverage is already 100%, the description adds a great deal of semantic depth the schema lacks: the query must be ONE short phrase in Slovak (Czech tolerated), numbers spoken as the user said them, at most one body type per call with an enumerated vocabulary, and filler/equipment words to omit. The worked examples directly model the expected input format.

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 — finding a used car for sale in Slovakia — and enumerates the exact criteria it can search on (brand, model, body type, fuel, gearbox, year, price, mileage, power, town/district). The scope (AutoIsto listings plus aggregated Slovak portals) is concrete enough to separate it from get_car_details and get_model_price, which serve per-car and per-model queries.

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 when-to-use clause and gives a strong when-not list (no new-car configurators, rentals, leasing offers or cars abroad; only currently-listed Slovak cars in EUR). It does not, however, explicitly route the agent among its siblings (e.g. 'follow with get_car_details for a specific listing'), leaving that inference to the reader.

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