AutoSignal

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

With no annotations, the description carries the full burden and does it well: it discloses the free/cost status, privacy behavior (companies named with IČO, private persons anonymous), the rate-limited live fallback for unknown VINs, and what data is absent (mileage, plate lookup). These are exactly the behavioral traits 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?

The first sentence is front-loaded with the core action, registry name, and return contents; two short follow-ups cover limitations and fallback. It is dense but every clause (privacy rules, rate limiting, missing data) earns its place, with only minor compression possible.

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, no-annotation, no-output-schema tool, the description enumerates the returned data domains, privacy treatment, known data gaps, and the unknown-VIN fallback behavior. An agent can decide whether to call it and interpret the result without further context.

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 VIN parameter already documents the 17-character, no-I/O/Q constraint. The description restates the 17-character format but adds no new syntax, normalization, or edge-case guidance 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?

The description states a specific verb (vehicle history check) and resource (official Czech vehicle registry), tied to a 17-character VIN. It lists the exact returned data domains (owner timeline, STK history, import origin, deregistration, seized flags, specs), so an agent can tell precisely what this tool produces versus the valuation/market 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?

It gives clear usage context: free lookup, unknown VINs fall back to a rate-limited live lookup, and it explicitly excludes mileage and license-plate lookups so the agent knows what not to attempt. It stops short of naming a sibling alternative for related needs (e.g. valuation), so it is clear but not fully routing.

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?

No annotations are provided, so the description carries the full burden. It discloses the return shape and that estimates derive from comparable listings, which is useful, but says nothing about accuracy caveats, behavior when comparables are sparse, or whether the call is purely read-only.

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 front-loaded sentence with zero filler that names the verb, the scope, the output shape, and the methodology in one pass.

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 usefully supplies the return structure (min/median/max). However, for a five-required-parameter tool with 20% schema coverage and no annotations, it leaves real gaps around input formats and failure modes.

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 20% (mileage in km is the sole documented field). The description adds no clarification for the four undocumented required parameters — notably 'fuel' is a free-form string with no enum, so format ('petrol' vs 'gasoline' vs 'diesel') is entirely ambiguous and the description does not resolve it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Estimate') and a precise resource ('fair price range for a specific car') and even names the output shape (min/median/max). It is clearly distinct from market-wide siblings like get_market_trend or get_price_history, though it never names an alternative explicitly.

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 implies the context ('for a specific car from comparable listings') but gives no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as get_price_history for historical data. An agent must infer that this is the per-vehicle valuation path.

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?

No annotations are provided, so the description carries the full burden, and it does well: it discloses scope (owned now AND ever, plus operated/leased fleets, not just registry ownership), that the fleet list is paginated and includes former holdings, and that market listings are appended. It does not state read-only nature explicitly (implied by 'get'), nor what happens for an unknown or malformed IČO.

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 front-loaded sentence that puts the resource and key first and then enumerates the payload. It is dense and run-on, but every clause names a distinct returned field rather than padding.

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 and no annotations, the description must explain the return payload, and it does so comprehensively, including the non-obvious 'operated' and 'former holdings' scopes. The gap is operational: pagination is mentioned but no parameter controls it, and error/empty behavior for an invalid IČO is 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?

Only one parameter, with 100% schema description coverage already documenting 'Czech IČO (1–8 digits)'. The description's 'by IČO' and 'Czech company' restate that without adding format, padding, or lookup-failure guidance, so 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?

States a specific verb+resource: the registered fleet profile for one Czech company keyed by IČO, and enumerates what it returns (owned/operated vehicles, holding period, owner-type, fleet list, market listings). It does not explicitly distinguish itself from the sibling search_company_fleets (lookup vs search), so an agent must infer the relationship.

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?

The phrase 'by IČO' implies this is the detail call you make once you have an identifier, contrasting implicitly with the sibling search_company_fleets. However, there is no explicit when-to-use, no stated prerequisite (e.g. resolve the company via search first), and no exclusion of alternatives.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the returned data shape (listing, price history, market stats, prediction, deal rationale) and 'Get' implies a read-only operation, but it says nothing about permissions, cost, latency, or behavior on missing ids.

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 sentence with the verb and key payload front-loaded; every clause enumerates a concrete returned field and 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?

With no output schema, the description appropriately lists what is returned, which is the main thing an agent needs. It falls short only on how to source the deal id and on read-only/error behavior, which are minor for a single-fetch 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?

There is one parameter with 100% schema description coverage ('Deal id'), so the schema already documents it. The description restates 'by its deal id' without adding format, source, or validity constraints beyond the schema — baseline 3 for high coverage.

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 full detail for one deal by its deal id') and enumerates the payload: listing, price history, market stats, prediction, and rationale. This is clearly distinguishable from list/search siblings like search_deals and list_hot_deals, but it does not explicitly name those siblings to route against.

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: it retrieves one deal given an id, presumably after a search. There is no explicit 'use when' or 'use X instead' guidance, and no mention of how an agent should obtain a deal id (e.g., via search_deals or list_hot_deals).

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?

No annotations are provided, so the description carries the full burden. It does real work by enumerating the data dimensions returned, which tells an agent this is a broad read and roughly how large/rich the payload is. It says nothing about read-only safety, aggregation window/freshness, caching, latency, or what happens for a country with thin data.

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 sentence, front-loaded with the core promise ('Comprehensive market snapshot for a country') followed by the payload inventory. Zero filler. Minor deduction for jargon-heavy terms like 'price pulse' and 'deal hotspots' that are not self-defining.

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?

There is no output schema, and the description compensates well by listing what the response contains section by section. For a defaulted, single-parameter read tool this is close to sufficient; the remaining gaps are sibling differentiation and the default-country fallback, which the schema already states.

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%: the single 'country' parameter has an enum of seven markets and a documented default of CZ. The description only echoes 'for a country' and adds no semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear resource and scope: a comprehensive market snapshot for a single country, enumerating the specific sections returned (price pulse, buyer/seller verdict, brand/body-type breakdowns, 90d trend, supply/freshness, oversupply and fast-mover signals). That is a concrete verb+resource. It does not, however, distinguish itself from siblings like get_market_trend, get_price_movers, or get_weekly_summary, which cover overlapping slices.

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?

The word 'Comprehensive' implies this is the umbrella tool to reach for when the whole picture is needed rather than a single metric, but that routing is left to inference. There is no explicit when-to-use statement and no named alternative for narrower questions (trend-only, movers-only, weekly digest).

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?

With no annotations, the description carries the full behavioral burden. It helpfully discloses the returned metrics and trend window, but it does not state that the operation is read-only, how fresh the data is, whether results are cached, or what errors occur for unknown brand/model combinations.

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 description is a single front-loaded sentence with no filler. It efficiently states the scope and returned metrics.

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?

The return metrics are described, which is useful because there is no output schema. But the required brand and model parameters have no schema descriptions, no annotations exist, and no alternatives are named, leaving the agent to infer formats and routing.

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 0%, so the description must define brand and model. It only says the tool operates on 'one brand+model,' which restates the parameter names without explaining acceptable formats, casing, whether model must be exact, or how to handle missing models.

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 (market trend) and the exact metrics returned: current median/avg price, listing count, and 7d-vs-30d trend for one brand+model. It is clearly narrower than get_market_overview, but it does not explicitly differentiate itself from get_price_history or get_price_movers.

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: call this when you need current market stats for a specific brand and model. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as get_market_overview for broader data or get_price_history for historical series.

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?

With no annotations, the description carries the full behavioral burden. It discloses useful scope details—90-day window, daily granularity, and returned metrics—but does not state read-only status, permissions, rate limits, pagination, currency, or other operational behavior.

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, front-loaded sentence with no wasted words. It communicates scope, granularity, key metrics, and optional filtering efficiently.

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?

The definition gives enough context to understand the core data returned, but with bare schemas, no annotations, and no output schema, it leaves out operational details such as parameter formats and when to choose this tool over sibling market tools.

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 0%, so the description must compensate. It correctly identifies brand and model as required and fuel as optional, covering all three parameters semantically, but it does not specify accepted formats or values for fuel, brand, or 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: 90-day daily price history for a brand+model, optionally filtered by fuel. It also names the returned metrics (median, avg, count), so the purpose is clear, though it does not explicitly differentiate itself from sibling tools like get_market_trend or estimate_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?

Provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only implied usage is the required brand+model inputs and optional fuel narrowing.

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?

With no annotations, the description carries the burden and does substantial work: it discloses the 5–30% band, volume floors, and sample-stability guard, so the agent knows results are aggressively filtered and small-magnitude moves are silently excluded. It also explains that moverScore is credibility-weighted (volume + sample stability) rather than raw magnitude, which prevents misreading the output; missing only sort order and cost/latency traits.

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 sentences, zero filler, and the subject of the query is front-loaded ahead of the filtering and scoring caveats. Every clause carries information an agent cannot get from the schema.

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?

There is no output schema, and the description compensates by describing the returned entity (segment) and its moverScore field, plus the filtering that shapes results. It leaves the rest of the payload shape and the result ordering unspecified, which is the main remaining gap for a tool whose output is its whole value.

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 all four parameters already have descriptions and enum values, establishing a baseline of 3. The description adds context for two of them — it explains the ~30-day window that makes minThen meaningful and that ranking is on median price — but adds nothing for limit, country, or minNow 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?

Names a specific resource (brand+model+fuel segments ranked by median price movement over ~30 days) and states the filtering/ranking logic, which is far more specific than siblings like get_market_trend or get_price_history. It stops short of explicitly naming which sibling answers a related question, but the resource itself is unambiguous.

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: an agent can infer this is for spotting the biggest credible price shifts rather than tracking one vehicle or reading overall market stats. There is no explicit 'use this when... use get_price_history/get_market_trend instead when...' routing, so selection still requires 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?

With no annotations, the description carries the full burden. It usefully discloses the three returned metrics, but does not state whether this is a read-only aggregate, how 'this week' is defined (calendar week, rolling 7 days, timezone), or what data source/freshness to expect.

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, front-loaded sentence with zero waste. It immediately tells the agent what 'this week at a glance' includes.

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 zero-param tool with no output schema, the description must explain return values, and it does list three metrics. However, it leaves ambiguity about what 'best deal' means (highest discount, absolute savings, etc.) and whether 'average savings' is a currency amount or percentage, so it is only partially complete.

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?

The tool takes zero parameters, so there is no parameter semantics to explain. The baseline of 4 applies; the description correctly indicates no inputs are needed.

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 the resource ('this week') and the exact metrics returned: new deal count, best deal, and average savings. It is clear what the tool produces, though it doesn't explicitly distinguish itself from siblings like get_market_overview or list_hot_deals.

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?

There is no guidance on when to use this tool versus alternatives such as get_market_overview, get_market_trend, or list_hot_deals. The phrase 'at a glance' implies a summary use case, but no explicit when/when-not conditions are given.

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?

With no annotations, the description carries the full burden, and it does disclose one meaningful behavior: brands without active deals are excluded and results carry deal counts. It says nothing about whether filters apply to the deals being counted, result ordering, size limits, or read-only/rate-limit characteristics.

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 short sentences, zero padding, with the core scope ('currently have active deals, with deal counts') front-loaded before the filter note.

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 9-parameter tool with no annotations and no output schema, the description should clarify the return shape (brand plus count, likely an array) and confirm that filters restrict the deals counted rather than the brands listed. The existing text covers intent but leaves those operational questions open.

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 78%, so the schema already documents fuels, price bounds, countries, mileage, discount, and price-dropped. The description adds only a cross-reference ('same filters as search_deals'), which helps an agent borrow semantics but does not explain how the filters scope the brand aggregation.

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 the resource (brands) and the scope constraint (only brands with active deals) plus the payload (deal counts), which cleanly distinguishes it from siblings like list_models, list_countries, and search_deals. It never uses an explicit verb, relying on the tool name to supply the 'list' action.

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?

'Accepts the same filters as search_deals' implies the intended workflow (facet/count view over the same filtered deal set), but there is no explicit statement of when to pick this over search_deals or list_models, and no exclusions. Usage must be inferred from the filter note.

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?

With no annotations, the description carries the full behavioral burden but only partially meets it. It discloses the active-deals filter and that counts are included, but it does not say whether the operation is read-only, what the counts represent, or how results are ordered or returned.

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 description is a single front-loaded phrase with no filler, and every element earns its place. It is slightly under-specified rather than over-long, and the slash construction 'Countries/markets' is mildly ambiguous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description gives the core scope and mentions counts but leaves return-shape details unexplained. It is adequate for an agent to understand the general output, but not complete enough to know exactly what each count represents or how the result set is structured.

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?

The tool takes zero parameters, so parameter semantics are not applicable and the baseline is 4. The description does not need to explain any input parameters.

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 the resource (countries/markets) and a specific scope (currently have active deals) plus an output trait (with counts), which distinguishes it from sibling list tools like list_brands or list_hot_deals. It is clear but not framed as a full verb-resource statement, and it does not explicitly contrast with close alternatives such as get_market_overview.

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?

There is no explicit when-to-use or when-not-to-use guidance. The description implies the tool is for finding markets that have active deals, but it does not name the alternative tools or the conditions under which an agent should choose this over search_deals or get_market_overview.

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?

With no annotations, the description carries the full disclosure burden. It usefully states the result ordering (deal score, discount vs market descending), but omits read-only confirmation, result-count limits, pagination, and how multiple country filters combine.

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 front-loaded sentence with no filler; the ranking criterion, the most decision-relevant detail, is included inline rather than padded out.

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 simple, zero-required-parameter read tool with no output schema, the description conveys what the results are and how they are ordered. Only minor gaps remain, such as how many deals come back and whether the country list acts as an OR filter.

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 optional 'countries' parameter is documented with its default (CZ) and enum values. The description adds no meaning beyond that, 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 names a specific resource (deals) with an explicit scope and ranking rule ('top deals right now, ranked by deal score, biggest discount vs market first'). It's clear what the tool returns, but it never distinguishes itself from the close sibling search_deals, leaving the agent to infer the boundary.

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?

'Right now' hints at a live, curated feed versus historical tools like get_price_history, but there is no explicit when-to-use or when-not-to-use guidance. The most relevant alternative, search_deals, is never named, so the agent must guess which one to call.

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?

No annotations exist, so the description carries the full burden, and it discloses almost nothing: not whether the counts are deal counts, whether results are paginated, how filtering across the 11 optional parameters combines, or whether only models with active deals exclude models without them. 'With counts' is the only behavioral hint.

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 short sentence with no filler; the scoping to brand and the 'with counts' detail are front-loaded. It is efficient, if under-informative rather than bloated.

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 tool with no annotations and no output schema, the description is far too thin: it never explains the filter semantics, the meaning of the returned counts, or result ordering/limits. The only richness comes from the input schema itself.

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 73%, leaving yearMin, yearMax, and bodyTypes undocumented in the schema, and the description adds nothing about any of the 11 parameters beyond confirming that brand is the pivot. It does not explain how filters like minDiscount, priceDropped, or countries interact with the 'active deals' constraint.

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 fragment clearly identifies the resource (models) and the scope (models for a given brand that currently have active deals, with counts), which is distinguishable from the sibling list_brands. It lacks an explicit verb, but 'Models for a given brand...' plus 'with counts' tells an agent what set is returned.

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?

The phrase 'that currently have active deals' implies when the tool is useful, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives such as search_deals or list_hot_deals. An agent must infer the routing decision entirely.

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?

No annotations are provided, so the description carries the full burden; it does disclose the qualifying condition (price drop measured between the two most recent price points), which is genuinely behavioral. However, it says nothing about result ordering, limits, or whether the list is capped, which matter for a listing tool with zero annotation coverage.

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 front-loaded sentence that defines the filter without any filler or restatement of the tool name.

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-optional-param list tool with no output schema or annotations, the key ambiguity — what counts as 'recently reduced' — is resolved precisely. Only secondary details like ordering or result caps are absent.

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 optional `countries` parameter already documents its enum and default (CZ). The description adds no meaning beyond that, 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 resource (deals) with a precise quantitative filter — 1–40% drop between the two latest prices — so an agent knows exactly what set is returned. It doesn't explicitly differentiate from siblings like get_price_movers or list_hot_deals, leaving overlap to inference.

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?

The threshold definition implies when the tool applies, but there is no explicit when-to-use guidance and no naming of alternatives such as get_price_movers or list_hot_deals, which a caller would need to disambiguate.

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?

With no annotations, the description carries the full burden and does substantial work: it scopes the data source to the Czech vehicle registry, discloses the OSVČ matching asymmetry, and explains the two-part return value. It says nothing about partial-match semantics, result limits, or what happens on zero results, which leaves residual gaps.

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 sentences, zero waste. The capability statement comes first and the edge-case caveat follows, so the essential information is front-loaded for an agent skimming definitions.

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?

Single-parameter tool with no annotations and no output schema, and the description covers the data source, searchable keys, the tricky OSVČ case, and the shape of the answer. Minor gaps remain around result-set behavior and match semantics, but nothing essential is missing for a correct call.

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 earns above that by adding semantics the schema cannot express — IČO matching on OSVČ must be exact, and the same field accepts either a name or a numeric identifier. It still doesn't clarify whether name matching is prefix, substring, or fuzzy.

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), a specific resource (Czech companies in the vehicle registry), and the returned value (fleet size, vehicles held now / ever). The search-by-name-or-IČO framing makes it clearly distinct from get_company_fleet, which is a lookup for a known 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?

Explicitly states the key usage constraint: sole traders (OSVČ) are only findable by exact IČO, never by name, which prevents a whole class of failed calls. It does not name an alternative tool or say what to do when no result is found, so it stops short of full routing guidance.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses pagination and the shape of each returned deal (listing, market stat, deal score, % below median), but says nothing about what defines 'below-market', permission/auth requirements, or result ordering semantics beyond what the schema covers.

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 sentences, front-loaded with the core verb and scope, with the pagination/return contract second. The inline filter enumeration is dense and slightly redundant with the schema, but it aids fast scanning and nothing is padded.

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?

No output schema exists, and the description compensates by naming the returned fields per deal. For a 17-parameter, all-optional filter tool this is close to sufficient; only the meaning of 'deal score' and 'below median' and pagination totals are left unexplained.

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 88%, so the schema already documents nearly every parameter including units (CZK, km) and examples. The description's parenthetical filter list mirrors the schema rather than adding interpretation, so 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+resource: search used-car deals filtered by market below-median pricing, with the filter dimensions enumerated. An agent immediately knows this is the browsable/filterable listing tool, though it does not explicitly distinguish itself from siblings like list_hot_deals or list_recently_reduced.

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 'Search below-market used-car deals with filters' and the paginated return, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as get_deal (single record) or list_hot_deals (curated subset). The agent must infer the boundary from names alone.

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