CarRentalList

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 behavioral detail the annotations cannot: omitting state returns states only, an unknown state returns an empty list plus did_you_mean, and places without their own page link to the state page. Pagination/limit behavior is not mentioned.

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 resource and payload, then layers usage, parameter behavior and edge cases in short sentences with no filler. Slightly dense with four separate behavioral clauses, but every sentence earns its place.

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 browse tool with rich annotations and an output schema, the description covers scope, return contents, alternate-state behavior, unknown input handling and sibling routing. An agent has everything needed to call 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% and the single parameter is fully documented in the schema ("a state to list its cities; omit to list the states"). The description restates this and adds the unknown-state edge case, but adds no new format or value syntax, 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 (list) over a specific resource (US states / cities of one state) and enumerates exactly what each row carries (car count, company count, lowest published daily rate). It is clearly distinguishable from search_vehicles and the other catalog 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?

Gives concrete triggering questions ("where can I rent exotic cars", "which cities have the most supercars") and names search_vehicles as the downstream alternative when you need correct city spelling. It lacks an explicit 'do not use this when...' exclusion, so it falls just short of 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is marginal context — and it delivers: each make row carries car count, company count, and lowest published daily rate, and unknown make/state/city returns an empty list with did_you_mean rather than an error. This empty-result/fuzzy-suggestion behavior is the key non-obvious trait and is disclosed.

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 primary capability, then usage, then edge-case behavior — a sensible order with no filler sentences. It is a single dense paragraph, slightly long, but every clause carries information an agent needs.

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; combined with the empty-list/did_you_mean note and zero required parameters, an agent has everything needed to call this correctly on the first try.

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 baseline is 3, but the description adds meaning beyond it: omitting state/city yields nationwide results, and supplying make switches the output shape from makes to that make's model families (Huracán, Urus, Aventador). The state/city/make interplay is clearer in the description than in the schema alone.

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 (list car makes, and each make's model families) and scopes it precisely (nationwide, state, or city) with the aggregations returned. It is clearly distinguishable from search_vehicles, browse_locations, and the company-oriented 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 names the triggering intents ("which brands or models they can rent somewhere") and the alternative workflow ("check how the catalog spells a make or model before calling search_vehicles"). That is a real when-to-use and when-to-use-something-else rule, not an 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 readOnly/idempotent/non-destructive, yet the description adds substantive methodology: only published daily rates are used, a price change requires two plausible rates within 30 days with the new one still live, new arrivals exclude re-scraped re-listings and bulk imports, and unknown places return did_you_mean. These are non-obvious inclusion rules an agent cannot infer from structured fields.

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?

Purpose and the enumerated lenses are front-loaded, and the edge-case rules follow in a logical order. It is dense but mostly earns its length; the main waste is re-stating enum meanings (rarest, new_arrivals, price changes) that the schema already documents in full, which makes it longer 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?

For a read-only, four-parameter tool with an output schema, this covers what an agent needs: what each kind yields, geographic scoping, and the did_you_mean fallback for unknown places. Return values are handled by the output schema, so nothing material 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 baseline is 3. The description still adds the scoping model — "nationwide or in a state or city" — clarifying how state/city interact with the result set, which the bare schema does not. It does not, however, specify behavior when both city and state are supplied, so it is not a full 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?

Opens with a specific verb+resource ("Show what is interesting in the exotic rental catalog") and enumerates the seven distinct lenses (new listings, price changes, rarest families, most expensive, biggest fleets, most reviewed). An agent can distinguish this highlights/roundup tool from search_vehicles or top_companies 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?

Gives concrete trigger questions ("what's new", "what got cheaper", "what's the rarest car I can rent", "who has the biggest fleet in Miami") and frames itself for news-style summaries, which tells the agent when this tool fits. It does not name a sibling alternative or state when NOT to use it (e.g., for targeted vehicle search), so it stops short of the 5 bar.

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 genuinely useful behavior beyond them: hard truncation caps (up to 50 cars per family, up to 30 per city), the metadata.truncated signal, and that an unknown id errors out.

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 dense paragraph, front-loaded with the core action and then the per-type detail. Every clause carries information, though the inline parenthetical enumerations make it heavier than it needs to be for a single-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 explained, yet the description still sketches what each document type yields. Combined with the truncation and error semantics, an agent has enough to call this correctly; only auth/permission expectations are unstated.

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 id format is already fully documented in the schema, giving a baseline of 3. The description adds real semantic value on top: "Pass the id unchanged" and the failure mode of an unknown id, which the schema does not state.

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 (fetch) and resource (the full document) and scopes it to an id from search, then enumerates the four document shapes and what each contains. It is clear, but it never contrasts itself with the overlapping siblings get_company and get_news_article, so an agent cannot fully disambiguate on the name 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?

"Use this when you have an id from search and need the details of that one result" gives a clear trigger condition and even the follow-up action (cite its url). There is no explicit when-not or alternative-tool statement, which is the only gap.

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), and the description goes well beyond them: it discloses old-slug rename following, the error-with-reason for delisted companies, suggestions for unknown names, and the 60-car fleet cap with fleet_total as the true count. These are exactly the edge behaviors an agent cannot infer from structured fields.

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 scope, then the usage trigger, then edge cases and the fleet cap. The opening field enumeration is somewhat long, but every clause carries information an agent would otherwise have to discover by trial; no filler sentences.

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 shapes needn't be explained, yet the description still tells the agent what categories come back and how to handle failure modes (delisted, unknown), which is more than sufficient for a one-parameter lookup 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 100% and the single parameter's schema description already covers 'slug from url, old slug, or exact name'. The description largely restates this, though the 'follows renames' nuance and the name-fallback behavior add slight value over the schema. Baseline 3 is appropriate.

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 (get) and resource (one company) and enumerates the payload: contact details, rental terms, fleet with daily rates, recent price changes. It is clearly distinguishable from siblings like search_companies and top_companies because it is scoped to a single identified company.

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 an explicit trigger ('when someone names a company or picks one from search_vehicles results') and even the calling pattern (pass company.slug). It lacks an explicit negative case (e.g., use search_companies when you don't have a name/slug), but the context is clear.

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 goes further and discloses non-obvious traits: Markdown fidelity, the 20 KB body cap with a `truncated = true` flag, and error behavior on unknown slugs. These are exactly the runtime behaviors an agent cannot infer from the 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?

Three dense sentences with zero filler: output shape first, then routing guidance, then edge-case behavior. Every sentence carries distinct information and the most decision-relevant content (what you get, when to call it) is front-loaded.

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?

Output schema exists, so return-value documentation is not required, yet the description still characterizes the response adequately. For a single-required-param read tool with full schema coverage and rich annotations, nothing an agent needs 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 the slug description already covers provenance (search_news items[].slug, last segment of a /news/<slug> url), which sets the baseline at 3. The description adds that the input may be given as the slug 'or the /news/ url' (full URL rather than just the trailing segment), which is a mild but real clarification beyond the schema's wording.

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 CarRentalList news article') and enumerates the return payload (Markdown with headings/lists/links, date, related makes, source URL). It also implicitly separates itself from search_news by framing this as the detail-fetch step. An agent can distinguish it from the other siblings without opening 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?

Gives an explicit when-to-use condition ('details of a story found with search_news, or names an article from carrentallist.com/news') and an explicit recovery path ('An unknown slug returns an error; call search_news'). Both the trigger and the fallback alternative are named, leaving nothing 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?

Goes well beyond the read-only annotations by disclosing the computation basis (live, published-rate cars only, never estimated), the null-figure behavior for empty scopes, the meaning of the floor_note output field, and the did_you_mean fallback for unknown inputs. These are exactly the behavioral traits an agent cannot infer from readOnlyHint/idempotentHint.

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 purpose and what is returned, then layers when-to-use, caveats, and edge cases in a logical order. It is on the long side for a five-sentence definition, but nearly every clause carries non-redundant information, so little could be cut without loss.

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 need not enumerate return fields, yet it still covers the edge cases an agent must anticipate: null figures on empty scopes, floor_note interpretation, and did_you_mean on unknown inputs. Nothing needed to call this tool 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 already 100%, so the baseline is 3; the description adds how the five filters act as alternative scopes ('for a make, model family, state, city or class') and warns that a scope yielding no published rate returns nulls. It does not document accepted formats itself, but it meaningfully reinforces the parameter model.

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 ('Summarize the published daily rental rates of exotic cars') and enumerates exactly what the summary contains: count, publish count, min, quartiles, median, max, state split, and extremes with links. This is clearly distinguishable from siblings like search_vehicles or vehicle_availability, which return individual listings rather than aggregates.

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 triggering questions ('what does a 911 Turbo S cost per day in California?', state comparisons, cheapest class to rent), which tells an agent precisely when to reach for this tool. It stops short of naming an alternative sibling or stating when NOT to use it, so it falls just below the top band.

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=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful edge-case behavior that a no-match query returns an empty results list, plus that results are ids for fetch. That is real added context, but return-shape details are largely redundant given the output schema exists.

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 verb and scope, then usage, then the alternative, then the empty-result edge case. Dense and largely waste-free, though the inline example list ('Lamborghini Huracán, Rolls-Royce Cullinan…') adds length that the schema examples already duplicate.

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 search tool with an output schema and full annotation coverage, the description covers scope, usage, alternatives, return pass-through to fetch, and the empty-result case. An agent has everything needed to select and invoke 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 description coverage is 100% and the single parameter's schema description already supplies example queries. The description repeats similar examples (company, car, city, news topic), adding reassurance but no syntax or semantics beyond what the schema states. Baseline 3 is correct when the schema carries the parameter burden.

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) and resource scope (the whole CarRentalList catalog), then enumerates what is searchable: companies, car model families, cities, news articles. It explicitly distinguishes itself from the nearest sibling, search_vehicles, by naming it for filtered car lists.

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 two concrete when-to-use conditions (clients that offer only search+fetch, e.g. ChatGPT connectors/deep research; finding an entity by name before fetching) and an explicit when-not/alternative rule routing filtered car lists to search_vehicles. Nothing is left 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 cover read-only, idempotent and closed-world safety, but the description adds non-obvious behavior: terms filters are exclusive and non-publishing companies are surfaced in excluded_terms_not_published, and the guidance to tell the user to ask them. It also discloses the failure mode (unknown place/make/tag returns empty with did_you_mean). It stops short of covering pagination/limit behavior, though the cursor param is documented in 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?

Purpose is front-loaded, then usage scenarios, then edge behavior and the sibling handoff. Sentences are dense and one clause chain ('verified ownership and published rental terms: minimum renter age, delivery, unlimited mileage and deposit') runs long, but nothing is 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 13-param, zero-required filter tool with a full schema and an output schema, this is complete: it covers purpose, selection scenarios, filter semantics, the empty-result path (did_you_mean), the excluded-companies reporting, and the sibling for single-company lookups. Return shape can be left to the output 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?

Schema coverage is 100%, so baseline is 3, but the description adds real semantics beyond per-param text: it explains that terms filters are publish-or-exclude and that omitted companies are reported separately, and clarifies sort=rank as the site's own order. It doesn't add format details for the place/make strings, which the schema already handles.

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 ('Find independent exotic car rental companies') plus the dimensions searchable (state/city, make, specialization, rating, verified ownership, terms). It also explicitly distinguishes itself from the sibling get_company, so an agent can route without reading either 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?

Gives concrete when-to-use triggers with real user phrasings ('I'm 23, who rents to me in Las Vegas with delivery?'), names the three query shapes it serves, and points to get_company for the single-company case. No alternatives are left 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 readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are ordered newest first, and matching degrades from ALL terms to ANY term when no article contains every word. It does not discuss pagination mechanics or rate limits, but the added matching semantics are the important part.

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 resource, then usage, then the fallback nuance. It is a single dense paragraph and slightly overlong, but every clause (ordering, search fields, alternative tool, empty-query default, OR-match) carries information an agent needs.

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-value explanation is unnecessary, and the description covers what it does not: ordering, matching behavior, defaults when no arguments are supplied, and the handoff tool for full text. Nothing needed to invoke 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 baseline is 3, but the description adds semantics the schema does not carry: the query OR-matching fallback (match = any), the newest-first ordering that makes cursor/limit meaningful as paging, and the fact that make restricts to articles 'about' a make rather than merely mentioning it. That is real value beyond the field descriptions.

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 (Search) plus resource (CarRentalList's exotic car news) and the exact fields searched (headline, excerpt, keywords) and ordering (newest first). It also distinguishes itself from the sibling get_news_article by naming it as the follow-up for full text, so an agent can route between the two without opening schemas.

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 triggers are given ('someone asks for news about a car, a make or an event (Monterey Car Week, a new Ferrari)') plus the alternative path (call get_news_article with a slug for full text). It also states the no-parameter behavior (latest articles), so both the selection condition and the fallback are unambiguous.

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 read-only, idempotent, non-destructive behavior, so the description only needs to add non-obvious traits. It does: null daily_price means unpublished (with an explicit instruction to say "contact for price" and never estimate), and unknown inputs return an empty page with did_you_mean rather than an error. That is genuinely useful beyond the annotations, though result envelope details overlap with the 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?

Front-loaded with purpose and scope, then usage triggers, then edge-case handling — a logical ordering with no filler. It is denser and longer than a single-line tool needs, but each sentence (null price policy, did_you_mean fallback) carries distinct actionable 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 a 12-parameter, zero-required filter tool with a full output schema and annotations, the description covers selection, filters, null-price policy, and failure recovery. The only omission is how price-range and priced_only combine, which the schema silently handles well enough that an agent can call 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 description coverage is 100%, so the schema already carries the parameter semantics; baseline is 3. The description reinforces that model matches the site's model families and that prices are company-published daily rates, but adds no syntax or defaults beyond 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 and resource (find exotic/luxury rental cars from independent US rental companies) plus the exact payload the tool yields: daily rate, renting company, and citation page. It names the specific sibling fallbacks (browse_locations / browse_makes) for the unresolvable cases, so the agent can distinguish it 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?

Gives three concrete triggering questions (who rents a specific car, what is available in a state/city, what a car costs per day), which maps cleanly onto the make/model/query, state/city, and price parameters. It also states the boundary case (unknown city or make) and the two alternatives to call 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for going further: editions are frozen at the start of their month, and an unknown month returns an error listing the stored editions. This error/immutability behavior is exactly the kind of context annotations cannot express.

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 dense sentences, front-loaded with what the tool returns before usage and parameter notes. Minor waste in re-listing the category champions ('largest fleet, highest rated, best in Miami/LA/Vegas...') which the schema enum already enumerates, but the rest of the text is information-dense.

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 spelled out, and the description covers the remaining unknowns: edition immutability, default month, and error behavior on bad input. Only small ambiguity remains around as_of, which is referenced but not identified as a response field.

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 meaning beyond the schema: month selects a past frozen edition (default is the current one) and an unrecognized month produces an error enumerating valid editions. It also clarifies that as_of is the edition's date, which the schema does not define at all.

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 ('monthly ranking of the best independent exotic car rental companies in the US') and enumerates the concrete payload: top 10 with composite scores, category champions, and market stats. This clearly separates it from siblings like get_company or search_companies, which return individual records rather than an editorial ranking.

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 intent: 'Use this when someone asks who the best, top-rated or biggest exotic rental companies are, or about a past month's ranking.' That is a clear when-to-use condition, but it does not name an alternative or exclusion (e.g. use search_companies for arbitrary filtering), so routing against siblings is only partly addressed.

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/idempotent/non-destructive annotations: model names are matched as site model families (G63 = G 63 AMG = G-Wagon), unknown models return an empty result with did_you_mean, ambiguous model names resolve to the most-listed make with others surfaced in other_makes, and min_price null means no published rate rather than an estimate. These are exactly the edge-case behaviors an agent needs before 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?

Front-loads what is returned, then when to use it, then edge-case behavior in one dense paragraph. Slightly run-on with the model-family and ambiguity clauses chained together, 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?

Output schema exists, so return values needn't be enumerated, yet the description usefully characterizes them (states, cities, car/company counts, min_price) plus the null-price and empty-result semantics. Nothing needed to invoke or interpret this tool 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; the description still adds real meaning by explaining that `make` matters only when the model alone is ambiguous and that family-level matching applies to `model`. `state` scoping is implied ('the states and cities that list it') without extra syntax 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: find the US states/cities where a single exotic model is rentable, with car/company counts and lowest published daily rate. The described output shape (geographic distribution + price floor for one model) is distinct enough from the generic search_vehicles/browse_* siblings that an agent can route to it without opening 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?

Gives explicit triggering questions ('where they can rent a specific model', 'which city has the most of one model') with concrete examples (Ford GT, Carrera GT, SF90, Huracán). It does not, however, name a sibling tool to use instead or state when this is the wrong choice versus search_vehicles.

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