AutoPrivado

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

Annotations only give the generic write/open-world/non-idempotent profile; the description adds substantial behavior: VIN/plate decoding, a rule-based estimate, multi-language copy generation, rate limits per client and per day, and the fact that a public listing page goes live on autoprivado.com. It also flags the secret edit URL as seller-only, which is a disclosure rule an agent could not infer from annotations.

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 action and eligibility constraint, then capabilities, then outputs and limits, so an agent can stop reading early. It is a single dense paragraph with some enumeration that could be better structured, but no sentence 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?

For a 21-parameter write tool with a nested vehicle object and no output schema, the description covers the return values (listing URL plus secret edit URL), the post-creation workflow (posting kits), and rate limits. The gap is per-field meaning for the optional details, which is the only thing an agent could still get wrong.

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?

At 62% schema coverage the schema already documents the key inputs (vin, plate, price, alsoIn, newPrice, contact), and the description adds interpretive context by naming what vin/plate trigger (NHTSA/RDW lookup) and how price estimation works. However, it never explains the many structural/condition parameters (city, colour, owners, gearbox, condition, vehicle overrides) beyond what the schema already states, so it does not compensate for the remaining coverage 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 and resource ('Create a car-for-sale listing') plus the exact scope: private seller, AutoPrivado, only with owner consent. Siblings are all read/decode/estimate tools, so the create-vs-retrieve distinction is unambiguous from the description alone.

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?

Clearly defines the eligible context (private seller, owner consent) and rules out an expectation the agent might otherwise have: AutoPrivado never posts to portals, the seller does it via the posting kit. It does not explicitly contrast with decode_vehicle or estimate_price, which are the obvious alternative paths if the agent only wants a lookup rather than a live listing.

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/non-destructive/open-world, so the bar is lower; the description still adds real value by naming the external data providers, the RDW field set, and confirming 'Nothing is stored'. It omits failure behavior for an invalid VIN or unknown plate, which is the main remaining gap.

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?

Two dense sentences, front-loaded with the primary input and its constraint, followed by source/field detail and a privacy note. No filler; every clause carries information.

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 no output schema, the description does the work of naming return fields (make, model, first registration, fuel, power, APK date) — though only for the RDW path, not the VIN path. The zero-required-parameter ambiguity is the one thing an agent could still get wrong.

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 67% and the undocumented `vin` param is compensated for by the description's '17-character VIN' constraint plus the US/EU coverage caveat. It also reinforces that `country` is NL-only and `plate` is Dutch, matching the enum, though it does not explain precedence if both are passed.

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 (decode) and two concrete resources (17-character VIN, Dutch licence plate), plus the upstream data source for each. This is unmistakably distinct from the listing/price siblings, none of which touch vehicle identity resolution.

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 clear context for each input path — VIN via NHTSA vPIC with an explicit coverage caveat (US-sold and many EU makes), plate via RDW with the fields it yields. It does not state that vin and plate are alternatives and that at least one must be supplied, which matters given zero required parameters.

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/non-destructive, so the safety profile is covered; the description adds genuinely non-obvious traits: deterministic rule-based output, that it explains each step and the typical dealer gap, that prices are never converted from PLN, and that nothing is stored. It stops short of describing latency, rate limits, or output structure in detail, which keeps it off a 5.

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 compact sentences, front-loaded with what the tool returns before caveats about currency and storage. Every clause carries information an agent would otherwise have to guess, 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?

With 7 parameters, a nested object, and no output schema, the description does the necessary work of conveying the return shape (low/mid/high EUR plus step-by-step explanation) and the currency invariant. The remaining gap is that requiredness of newPrice and the vehicle-object fields is only implied, not stated.

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 only 57% and one parameter (km) has no description at all, but the description compensates by tying mileage, condition, new-when-new price, and identity routes together and clarifying that the vehicle object serves as overrides. Only lang and the exact composition of the nested vehicle object are left to the 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?

States a specific verb+resource: a rule-based low/mid/high EUR price range estimated from VIN, Dutch plate, or make/model/year plus mileage and condition. It also draws the boundary against sibling decode_vehicle by framing the tool as an estimator that consumes decoded identity, and against a valuation by saying 'Not a valuation'.

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 useful framing ('Not a valuation', the dealer gap, always EUR) and enumerates accepted input routes (VIN, plate, or vehicle object), so a competent agent can infer when to call it. But it never explicitly says when to prefer it over decode_vehicle or when newPrice is mandatory versus optional, leaving routing to inference.

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, and destructiveHint=false, so safety is covered structurally. The description adds value beyond that by disclosing the failure behavior: expired or deleted listings return not_found, which an agent could not infer 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?

A single tight sentence with the verb, key, and full payload listed up front, followed by the error condition. Zero 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?

With no output schema, the description compensates by enumerating the returned fields and the not_found case. For a 2-parameter read tool, an agent has everything needed to call it and interpret the result.

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% and the schema already explains both the id source (search_listings or the /l/<id> URL) and the lang enum purpose. The description adds only that texts/page URLs come in 7 languages, 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 specific verb and resource ('Get one AutoPrivado listing by id') and enumerates exactly what comes back (vehicle data, price/currency, 7-language texts, photo URLs, page URL per language, missing-info checklist). The singular 'by id' framing cleanly separates it from search_listings and create_listing without needing to name them.

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?

'Get one ... by id' plus the schema note that the id comes from search_listings or a URL gives a clear usage context and the retrieval path. It lacks an explicit 'use search_listings instead when...' exclusion, which keeps it below 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value on top: which artifacts are returned, that the contract is conditionally prefilled from a listing id, and that checklist deadlines are derived from the sale date.

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 dense sentence that front-loads the resource and then enumerates the returned artifacts with their conditions. No filler, though the comma-list style is heavy and could be split for readability.

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 no output schema, the description carries the burden of describing returns, and it does so by enumerating the template, checklist, documents, costs and sources. Parameter roles are largely covered by the schema; only minor gaps (default language handling, country-specific coverage) remain.

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 75% and the schema already documents lang, saleDate and listingId. The description reinforces the conditional effects of listingId and saleDate but adds no format, defaults or edge-case detail beyond what the schema states, 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?

The description names a concrete resource bundle (sale-contract template, change-of-ownership checklist, handover documents, costs, official sources) for a specific task: closing a private car sale. It is clearly distinct from siblings like get_listing or create_listing, though it never explicitly contrasts itself with them.

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 implied by the scenario ('closing a private car sale in a country'), and the conditional behaviors are stated ('prefilled when a listing id is given', deadlines 'computed from the sale date'). However, there is no explicit when-to-use/when-not guidance or named alternative, so it stays at implied level.

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, and destructiveHint=false, so safety is covered. The description adds real value beyond that by enumerating the data returned (recommended vs optional portal, home page, listing form, private-seller fee with source, payment service, foreign-seller eligibility), which matters since there is no output 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?

One sentence, front-loaded with the resource and then a compact list of returned attributes; each clause contributes information. The parenthetical country list is slightly redundant with the schema enum.

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 no output schema, the description is doing the necessary work of explaining what each portal entry contains, and the only parameter is fully documented in the schema. An agent has everything needed to call it and interpret results.

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 country parameter has an enum plus the note 'Optional: only this country'. The description merely restates the same country list as the enum, adding no semantics beyond what the schema already provides, 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?

The description states a specific resource (car portals AutoPrivado prepares posting kits for, per country) and enumerates the attributes each entry carries, so an agent knows exactly what this returns. It doesn't explicitly contrast with siblings, but none of them (create_listing, get_listing, search_listings, etc.) cover portal data, so confusion risk is low.

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: the agent can infer this is a reference lookup for portal/posting-kit information, and the optional country parameter signals 'all countries by default, one if specified'. There is no explicit when-to-use statement, no exclusions, and no named alternative tool.

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 carry the safety profile (readOnly, idempotent, non-destructive), and the description adds real value on top: data freshness ('results may be up to a minute old'), extra return fields for cross-listed cars (crossListed, marketPrice, marketCurrency), and the per-market currency rule for price filters. It leaves pagination/default-limit behavior and result ordering unexplained.

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 stated first, filters second, edge-case return behavior third, and freshness last — a sensible front-loaded order with no filler. The parenthetical field lists make it slightly dense but each clause carries information.

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 an 11-parameter, zero-required search tool with no output schema and sparse schema descriptions, the definition covers nearly every filter, the currency semantics, and partial return-shape disclosure. Missing pieces are default limit, ordering, and whether all filters combine with AND.

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 only 27%, so the description does the heavy lifting: it enumerates free text, make, model, country, price range, maxKm, minYear, and fuel, and clarifies that price filters are interpreted in the searched market's currency (PLN in PL, EUR elsewhere). Only 'limit' is left without any narrative meaning.

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 ('Search active private-seller car listings on AutoPrivado') plus the scope restriction (active only, private sellers). This clearly separates it from get_listing (single fetch) and create_listing (mutation) among the 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?

Explains what each filter dimension does and, importantly, the condition under which cross-listed cars appear ('a country search also returns cars cross-listed into that market'). It never explicitly says when not to use it or names an alternative sibling, so it stops 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.