Autoza UK

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

Goes well beyond the readOnly/non-destructive annotations: answers are dealer-stated rather than independently inspected, 'unknown' does not mean 'no', sold/withdrawn listings return status no_longer_for_sale with no answers, and mot_history only appears when the dealer has opted in. That is exactly the provenance and failure-mode context an agent needs.

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?

Five dense sentences with no filler, ordered from what the tool answers, to provenance, to failure modes, to input sourcing, to conditional output. Nothing repeats the schema or annotations.

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 structure need not be explained, yet the description still pre-announces the meaningful response states (unknown, no_longer_for_sale, mot_history) that an agent must branch on. Nothing needed 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%, so the baseline is 3, but the description adds real sourcing guidance ('the listing URL or id returned by search_used_cars') and ties include_unanswered to the buyer-visible 'unknown' behavior, giving meaning beyond the field labels.

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 — answering a buyer's questions about ONE listed car — and enumerates the covered topics (previous owners, service history, warranty, keys, previous use, spec). The 'ONE car' scope cleanly separates it from search_used_cars, which returns listings.

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 routes the agent to feed it the listing URL or id returned by search_used_cars, and states the edge cases (unknown answer, no_longer_for_sale). It does not, however, distinguish itself from MOT-related siblings like check_mot_due_date or mot_outlook, so the agent must infer which is authoritative when a buyer asks about MOT.

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 confirm a safe read-only, closed-world operation, and the description adds substantial behaviour beyond that: it returns a named error rather than a figure when a required input is missing, and it caveats ambiguous year-only cases via notes instead of guessing. The Expensive Car Supplement thresholds and the fuel/registration-date interactions are genuine behavioural disclosure.

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 core action and the three regimes, then the supplement exceptions and the error/ambiguous-case behaviour. Dense and purposeful, though the multi-clause supplement sentence is heavy enough to slow scanning slightly.

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 no explanation, and the description covers the remaining burden: regime selection, conditional inputs, error behaviour and ambiguity handling. Nothing an agent needs to invoke 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?

Coverage is 100% so the schema already documents each field, but the description adds cross-parameter semantics the schema states only per-field: which inputs each tax regime requires, that registration_date resolves date boundaries the year alone cannot, and that list_price matters only for the supplement. This conditional-requirement framing is real added value over the flat field list.

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 ('Calculate annual UK vehicle tax (VED / road tax) for a car') and immediately scopes it to the three UK registration regimes. It is trivially distinguishable from siblings like check_mot_due_date or check_clean_air_zone.

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 says 'Use for questions about UK car tax, road tax or VED' and lays out which regime applies to which registration period, which effectively tells the agent when a given input set is appropriate. It does not name a sibling alternative, but the domain is narrow enough that this costs little.

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 a safe read-only, closed-world operation, so the bar is lower. The description still adds real behavioral value: it names the returned fields, explains that a missing input returns an error naming the offending parameter, and states the year requirement is waived for electric cars.

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 and dense with useful facts, with no filler sentences. The domain caveat about English vs Scottish zones is relevant but slightly interrupts the flow before the final usage sentence, keeping it just short of ideal.

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?

Covers inputs, the conditional-requirement edge case, error behavior, and the returned fields. With an output schema present, no further return-value documentation is needed, so the definition is complete for this tool's complexity.

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 parameters are already documented, establishing a baseline of 3. The description's conditional note ('the year is not needed for an electric car') essentially restates what the schema already says via 'Required unless fuel is electric', adding little new semantic detail.

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 and resource (check car compliance with UK clean air zones) plus the output it produces (compliance, daily charge per zone, estimated annual cost). The scope is narrow enough that an agent can distinguish it from siblings like calculate_car_tax or estimate_running_costs without reading the 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?

Ends with an explicit trigger list ('Use for ULEZ, CAZ, clean air zone or emissions-charge questions'), which routes the agent well. It also clarifies domain boundaries (only 3 of 8 English zones charge private cars; Scotland's LEZs issue penalties not charges), though it never names a sibling tool to prefer or avoid.

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 declare a safe read operation; the description goes well beyond that with domain behavior: the third-anniversary/annual rule, the NI four-year first test, the 'one calendar month minus a day' retention rule and its reset consequence, and the fallback that returns a pointer to the MOT record rather than a due date when first_registered is in the past.

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 core purpose is front-loaded and every sentence carries information, but the middle section is dense with stacked clauses and jurisdiction caveats, making it slightly heavier than needed for a two-parameter tool.

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 described. Given that, the description covers the remaining gaps an agent needs: jurisdiction rules, which parameter applies to which situation, the renewal-date consequence, and the fallback behavior when no due date can be produced.

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 baseline is 3; the schema already documents ISO format and which param suits an MOT'd vs non-MOT'd car. The description reinforces this routing and adds genuinely new semantics around the past-first_registered edge case, pushing it modestly above baseline.

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 a specific verb+resource ('Work out when a car's MOT test is due') and immediately adds the second capability (earliest testable date that preserves renewal). It is clearly distinct from siblings like mot_outlook, calculate_car_tax, and get_uk_price_guide without the agent needing to open a 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 states exactly when to use each input ('Pass first_registered for a car that has never had an MOT, or mot_expires for one that has') and names the triggering question types ('MOT due dates, MOT timing, or when a car needs testing'). It also scopes the jurisdiction (GB/DVSA vs NI/DVA), removing ambiguity about applicability.

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 state that this is a safe read; the description goes much further by disclosing partial totals for motorcycles/vans, the not_included explanation flag, 'available false' for caravans/motorhomes/trucks and NI vehicles, and the no_longer_for_sale status for withdrawn listings. It also states that uncomputable components are omitted rather than guessed, which is exactly the kind of modelling caveat an agent needs.

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-loads the core purpose in the first sentence and each following sentence carries a distinct exception or input rule. It is dense but no sentence is purely filler, though the density is on the heavy side for a two-parameter tool.

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, the description pre-empts the surprising return shapes (partial totals, available false, status no_longer_for_sale) so the agent can interpret responses correctly. Combined with the input guidance and edge-case coverage, 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% for both parameters, so the schema already documents listing_id and listing_url. The description adds only the provenance hint that these come from search_used_cars, which is marginally useful but not substantive new semantics.

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 (estimate) and resource (running costs for a specific Autoza vehicle over a year in GBP), plus the scope of components included. It is clearly distinguishable from siblings like calculate_car_tax and get_uk_price_guide because it covers a whole running-cost bundle tied to a listing.

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?

Tells the agent how to supply input ('Pass the listing URL or id returned by search_used_cars') and enumerates the cases where it should expect non-standard results (partial totals, available false, no_longer_for_sale). It stops short of naming an alternative tool to use instead for the excluded vehicle types, so it is not a full 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?

Beyond the readOnly/non-destructive annotations, the description discloses data provenance (DVSA Class 4 test records, Great Britain only), an important methodology nuance about rectification passes counting as first-time passes versus DVSA's own initial-test measure, and generation-coverage behavior with an explicit warning when a year falls outside the guide. This is exactly the kind of interpretation-critical context annotations cannot 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?

The opening sentence front-loads the resource and its three output types, and subsequent sentences each add distinct value (provenance, methodology caveat, generation behavior, usage triggers). It is dense at four sentences, but no sentence is filler, so it stays 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?

With an output schema present, return values need no explanation; the description instead covers scope, data source, interpretation caveats, optional-parameter behavior, and usage triggers. An agent has everything needed to decide to call it and to interpret the numbers correctly.

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 both parameters are already documented in the schema, including the flexible model_slug formats and the list-all behavior. The description largely restates that (generation coverage, per-year pass rate) rather than adding syntax or format detail the schema lacks. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific resource (a used car model's reliability data) and enumerates the concrete outputs: common faults, best/worst model years, and DVSA MOT first-time pass rates. The scope is narrowed to UK models and GB DVSA records, which makes it easy to separate from generic car tools. It never names a sibling like mot_outlook or check_mot_due_date, so differentiation is implied by scope rather than stated.

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 guidance is given: reliability questions, fault lookups, which year to buy or avoid, and pre-purchase checks. It also states the no-argument listing behavior and the registration_year use case, which is strong routing context. No when-not-use conditions or named alternatives are provided, keeping 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 cover the read-only/non-destructive safety profile, and the description adds substantial context beyond them: the data source (live dealer listings), the aggregation behavior (typical/lowest/highest), the degraded-case behavior ('where too few cars match... it says so'), and the semantic caveat that these are asking prices, not valuations.

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 sentences, each carrying distinct information (source, output figures, fallback behavior, scope/pricing semantics, use cases), with the core capability front-loaded. Slightly dense, but nothing is redundant.

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?

With an output schema present, the description does not need to enumerate return fields, yet it still clarifies what the figures mean and how the tool behaves when data is thin. For a 3-optional-parameter read tool, an agent has everything needed to call and interpret it correctly.

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 schema already documents make, model, and vehicle_type, including the default of 'car' and the enum values. The description restates the narrowing behavior and the vehicle-type switch without adding syntax or format detail beyond the schema, so 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 specific verb and resource ('Get current UK used-car asking-price guidance') plus the data source ('live dealer listings on Autoza') and the exact values returned (median, lowest, highest asking price). This is clearly distinguishable from siblings like search_used_cars and estimate_running_costs.

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?

Gives concrete use cases ('what do X cost used in the UK', 'sanity-check whether an advertised price is reasonable') and an explicit exclusion ('not trade or valuation estimates'). No sibling tool is named as an alternative, but the when-to-use guidance is clear enough to route an agent.

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 it as a safe, closed-world read, so the safety bar is met. The description adds genuinely new behavioral facts: the data provenance (DVSA test records, Great Britain), the fleet-level nature versus per-car prediction, and that uncovered models are reported plainly rather than guessed — the last point being important for trusting the model-level output.

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-loads the core purpose and keeps everything in one dense paragraph with no filler sentences. It is slightly long and mildly repetitive (coverage caveats appear twice: "for the models we cover" and "says plainly when a model is not covered"), which keeps it off a 5.

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?

With an output schema present, return values need no explanation here. The description still covers provenance, scope, model-coverage behavior, and usage triggers, leaving only minor gaps such as how the mileage-band output is presented alongside the base estimate.

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 baseline is 3. The description goes beyond it by explaining the semantic role of make/model (adds a model pass rate compared fairly against same-age cars, and only for covered models) and of the mileage-band movement, which the schema alone does not convey.

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 — the odds a used car passes its next MOT first time by age and mileage — plus the data source (DVSA MOT records with odometer readings, GB). It also distinguishes itself from get_model_reliability and check_mot_due_date by framing the output as a fleet pass rate with optional model comparison.

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?

Gives three explicit trigger scenarios (will a high-mileage car pass, how much mileage matters, is this car likely to need MOT work), which is strong when-to-use guidance. It also excludes a misuse case ("a rate across the tested fleet, not a prediction for one car"), but never names a sibling tool as the alternative, so it falls 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?

Goes well beyond the readOnly/openWorld annotations by disclosing non-obvious behavior: optional filters are relaxed one at a time when nothing matches and the response reports which were relaxed, SOLD/SALE AGREED/DEPOSIT PAID listings carry availability_caution, and missing prices yield price_gbp null with a price_note for suspiciously low prices. These are exactly the side effects and quirks an agent cannot get from annotations or schema.

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 what it searches and for whom, then adds conditional behaviors in compact clauses. It is a long description (five sentences of dense detail), but nearly every clause carries operative information about filtering, flags or defaults.

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?

With 12 optional parameters, a filter-relaxation policy and caution flags, this is a complex tool, and the description covers the default stock type, the relaxation fallback, and the interpretation of unusual results. Return values are also summarized even though an output schema exists, so an agent has everything needed to call and interpret it.

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 high (83%), so the schema already documents make interpretation, enum values, ranges and location formats. The description mostly reinforces existing parameter meaning ('Searches cars unless vehicle_type...') rather than adding new per-parameter syntax, so 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 specific verb (search) plus resources (live used cars for sale from UK dealers on Autoza), gives the units (GBP, miles), and scopes itself with 'searches cars unless vehicle_type asks for vans, motorcycles or other stock.' This clearly separates it from siblings like get_uk_price_guide, ask_about_car or mot_outlook.

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?

Ends with an explicit trigger: 'Use when someone wants to find, browse or compare actual vehicles currently for sale in the UK.' That is a clear usage condition, but no sibling is named as the alternative (e.g. get_uk_price_guide for valuation-only questions), so routing is left partly inferential.

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