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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), and the description adds genuinely non-redundant behavior: look-alike letter normalization and the explicit privacy boundary that it never identifies the owner or the vehicle's location. It does not address rate limits or data sourcing, but the added behavioral detail is meaningful.

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 sentences, front-loaded with the core action and its result, followed by the type override and the privacy disclaimer. The final 'Use it to check a specific plate number' sentence partly restates the opener, which is mild redundancy but serves as a routing hint.

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 details need not be explained, and all five parameters are fully described in the schema. The description supplies purpose, normalization behavior, privacy boundaries and usage, leaving it essentially complete for an agent to 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 documents country, number, region, locale and type in detail, including the enum for locale. The description only echoes the normalization note and the type-override behavior, adding marginal meaning beyond structured fields. 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 (validate) plus resource (plate number), and adds the concrete output (which region the code belongs to). It also declares scope boundaries ('check a specific plate number'). It does not explicitly name a sibling such as get_license_plate_country or get_license_plate_image, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear usage directive ('Use it to check a specific plate number') and explains that passing type checks against a specific plate type's format. That is actionable context, but there are no exclusions and no alternatives named for cases where another sibling tool is the right choice.

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 open-world, so safety is covered. The description adds genuinely new behavioral context: answers are probabilistic and carry a confidence level plus source, and the agent is told to propagate that uncertainty rather than assert rules. That is exactly the kind of disclosure annotations cannot convey.

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, both dense and front-loaded: the first lists exactly what rules are resolved, the second delivers the critical output caveat. No filler, no restatement of the tool name or title.

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

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

An output schema exists, so return structure need not be explained, and the description still adds the important caveat about confidence and sourcing. The one gap is boundary-setting: it claims 'temporary vehicle import' while a dedicated get_vehicle_import_rules sibling exists, leaving overlap unresolved for the agent.

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 passport, destination, plate, weight and locale are all documented in the schema itself (including the green-card and vehicle-weight purposes). The description adds no additional parameter meaning beyond restating that the call is pairwise. Baseline 3 applies when the schema does the heavy lifting.

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

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

Names the resource precisely (entry rules for a single passport+destination pair) and enumerates the dimensions it resolves: entry mode, length of stay, day-counting method, visa-run reset, temporary vehicle import. The phrase 'for one passport and destination' implicitly separates it from route-oriented siblings, but it never names get_route_visa_rules or get_vehicle_import_rules despite obvious overlap. Solid purpose, weak explicit sibling differentiation.

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 stated scope: use it for a specific passport/destination pair. However, there is no explicit when-to-use guidance, no exclusion of the sibling tools that also cover visa and vehicle-import rules, and no mention of prerequisites. The agent must infer boundaries from overlap.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context by explaining how to read the index (world average = 100, higher = more expensive), but says nothing about output shape, latency, or auth. With annotations carrying the behavioral burden, a 3 is appropriate.

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 short sentences, front-loaded with what the tool does and immediately followed by the interpretation rule and the usage trigger. The index explanation is slightly redundant with the scale parenthetical but each sentence 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 an output schema present, return values need not be described, and annotations cover the safety profile. The description supplies the metric's interpretation and a usage trigger, which is sufficient for a 3-parameter read-only comparison tool; only sibling routing 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%, and the locale parameter's own schema text already explains language and units behavior in detail. The description adds no parameter-level meaning beyond what the schema 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?

States a specific verb (compare) and resource (food price index) plus the scale semantics (world average = 100, higher = more expensive). This distinguishes it from get_country_food_prices and rank_food_prices by scope ('between two countries'), though it never names those 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 a clear triggering condition: 'Use it when someone asks where food is cheaper between two countries.' No exclusions or named alternatives are provided, so the agent must infer when get_country_food_prices or rank_food_prices is the better fit.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the ordering behavior (cheapest-first), which is genuinely useful, but says nothing about rate limits, staleness of 'current' prices, or auth. A 3 reflects modest added value on top of rich 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?

Three tight sentences with zero filler, front-loading the operation and scope before the return shape and the usage trigger. Every clause 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?

With an output schema present and annotations covering safety, the description carries only operation, scope, ordering, and a usage trigger, which is sufficient to invoke correctly. Minor gaps: no hint about how 'current' data is sourced or updated, and no contrast with the overlapping fuel siblings.

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%, including the locale guidance and fuel_type default, so the baseline is 3. The description only restates that one fuel type is compared and the 2-10 country range; it adds no meaning beyond what the schema already documents.

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 (compare), resource (current fuel prices), and scope (one fuel type across 2-10 countries), plus the return shape (sorted table cheapest-first). An agent can distinguish this from siblings like get_fuel_prices or find_cheapest_fuel 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 trigger: 'Use it when someone asks which of two or more named countries has cheaper or more expensive fuel.' That is clear context, but it names no alternatives or exclusions, so an agent still has to guess how it differs from find_cheapest_fuel or rank_food_prices-style siblings.

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, openWorld, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: output is a EUR range with per-country breakdown, and it flags partial results when a country on the route lacks data—an important caveat an agent must surface to the user.

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 core capability, then the routing rule and alternative. Every clause carries information; 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?

An output schema exists, yet the description still summarizes the return shape (EUR range, per-country breakdown, partial-result flags) and gives clear when-to-use routing. Nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter (locale, waypoints, vehicle_class) is already fully documented including enum meanings and defaults. The description's '2-10 place names' restates the schema's waypoint constraints but adds no format or unit detail beyond it, 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 (estimate) and resource (toll cost) with precise scope: 2-10 place names, per-km tolls, vignettes, bridges/tunnels, EUR range with per-country breakdown. It is distinguishable from siblings like get_toll_rates (rates, not a route estimate) and plan_road_trip (whole-trip planning).

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 routing guidance: 'Use it only for the toll cost between named places when no other trip details are asked; for a whole trip use plan_road_trip.' Both the inclusion condition and the named alternative 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?

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description restates ordering and scope but adds little behavioral context beyond the schema, such as rate limits, caching, or output format (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-loads the core ranking action and order behavior, but repeats 'order=most_expensive' and 'region or worldwide' across clauses, adding mild redundancy. Still compact and readable.

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

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

Covers purpose, usage context, and ordering. With a rich schema, output schema, and annotations handling safety and returns, the definition is nearly complete for an agent; it omits only a note on locale/language effect, which the schema covers.

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 all five parameters are fully documented in the schema. The description only restates the order and region parameters without adding syntax, defaults, or usage nuance 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 ('Rank countries') and resource (fuel price by region), with the ordering behavior. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like compare_fuel_prices or get_fuel_prices.

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 clear context: useful for route planning and for answering 'where is fuel cheapest/most expensive' in a region or worldwide. It does not mention when not to use it or name alternative tools, 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.

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

Annotations already declare readOnly/idempotent/openWorld, so safety is covered. The description adds genuinely useful behavior: a hard 48-hour recency window, a 10°×10° size cap, strongest-first ordering, and FRP in megawatts — all of which shape how results should be interpreted and how big a box the agent may request.

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 tightly packed sentences, front-loaded with what the data is and how fresh it is, then the usage case and the bbox format in a parenthetical example. 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 an output schema present, return values need no explanation, and the description covers source, recency, size limit, ordering, and units. It stops short of noting result caps or behavior when no detections exist, but that is a minor omission for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are already documented with ordering rules, an example, and enum values. The description repeats the west,south,east,north ordering with a second worked example (Portugal), which guards against a common lon/lat mix-up but adds no information the schema lacks — 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 source (NASA FIRMS VIIRS), resource (satellite fire detections), and scope (last 48 hours, ≤10°×10° bbox, sorted strongest-first, FRP in MW). No sibling tool overlaps with wildfires, so the agent can identify it instantly.

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 it for wildfires right now near a place or in a country" gives clear temporal and spatial triggering context. It does not name alternatives or exclusions, but there is no competing fire tool in the sibling list, so little is left ambiguous.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by disclosing what the tool produces (a 0-100 suitability score with sleep, driving and solar sub-scores over a 7-day horizon), which is the kind of domain 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?

Front-loaded with the core output plus the key routing rule, and no sentence is wasted. However, the final sentence largely restates the second ('use this ... when the user names a place' vs 'use it for the weather in one named city, town or place'), which is mild redundancy.

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 needn't enumerate return fields, yet it still summarizes them; annotations cover the safety profile and the schema covers all three parameters. Nothing an agent needs to select and correctly invoke this tool 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%, including locale semantics ('set it on every call') and country_code disambiguation, so the schema already carries parameter meaning. The description only reinforces the city concept via examples and adds nothing about locale or country_code, making 3 the appropriate baseline.

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

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

States a specific resource (travel weather suitability for campervan travel/sleep at a named place), the scoring model (0-100, sleep/driving/solar, today + 7 days), and explicitly distinguishes itself from get_country_travel_weather. An agent can tell exactly what this returns and how it differs from 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 an explicit routing rule: 'Use this, not get_country_travel_weather, when the user names a place,' with concrete examples (Barcelona, Málaga, Alicante). It also scopes the time horizon (today, tomorrow, this week), so both the when-to-use and the when-to-use-something-else conditions are covered.

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, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful behavior beyond them: the relative index scale and that a yearly history is returned, which tells the agent the response shape is a time series.

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 what the tool returns and immediately followed by when to call it. No filler, no repetition of the title, and the index baseline is placed where it is needed.

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 still sketches the payload (index plus yearly history). For a two-parameter read-only tool this is nearly complete; only the single-country vs comparison routing is left implicit.

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 both parameters (country_code, locale) are fully documented in the schema, so the schema does the heavy lifting. The description adds only the scale interpretation, not any parameter-level guidance such as the locale's effect on output language.

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 ('food price index for one country') and clarifies scope with the index scale (world average = 100). It implicitly separates itself from siblings like compare_food_prices and rank_food_prices via 'for one country', but never names or explicitly contrasts 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?

Gives a clear triggering condition: use when someone asks how expensive food, groceries or living is in a country. It stops short of stating when not to use it, e.g. routing multi-country comparisons to compare_food_prices or rank_food_prices.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: this is an aggregation call that answers a broad question 'in one call', which tells the agent it is the breadth-first option rather than a narrow lookup. It stops short of noting freshness, latency, or how comprehensive each bundled section is, so it is strong but not exhaustive.

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 purpose is front-loaded and the usage routing comes last, which is the right order. However, the capability enumeration is a long, dense run of items that could be tightened; every clause is relevant but the sentence is heavy.

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 the tool's complexity, an output schema that handles return values, and annotations that cover the safety profile, the description supplies the missing pieces an agent needs: the scope of content, the trigger conditions, and the sibling alternative. It could be a 5 with a note on how authoritative or time-sensitive each bundled section is, but nothing essential to invoking it correctly is 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%, so the schema already documents country_code, locale and passport in detail. The description only touches parameters indirectly with '(with passport)', which restates the schema's own note that passport adds entry-rule and stay-duration output. Baseline 3 is appropriate 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?

The description states a specific resource (a full pre-trip country briefing for driving a car/campervan) and enumerates exactly what is bundled, from entry rules and stay duration to fuel, tolls, holidays, safety, plugs, customs and food prices. It also distinguishes itself from the many sibling single-topic tools, so an agent can tell it apart from get_fuel_prices, get_toll_rates, check_visa_rules, etc., 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?

It explicitly names the trigger conditions ('asks what to know about a country, the nuances or a guide for travelling there, or is preparing a trip to it') and the exclusion ('use the single-topic tools for one narrow question'). When-to-use, when-not, and the alternative are all stated, 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?

Annotations declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, covering the safety profile. The description adds useful scope context (country-level aggregation, 0-100 scoring model, 7-day forecast window) beyond the annotations, but does not disclose caching, latency, rate limits, or failure modes. Given the rich annotations, 3 is appropriate.

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?

Single dense paragraph but front-loaded with the core purpose and output list, then the routing rule, then the usage triggers. Slightly long and could be split, but every clause carries information; no obvious waste.

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 the description needn't explain return values, and it correctly summarizes the outputs instead. For a read-only, two-parameter tool with full schema coverage and rich annotations, the description covers purpose, scope distinction, and usage triggers. Remaining gap: no mention of latency, geographic coverage, or data freshness, which would help an agent set expectations.

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% – both country_code and locale are fully documented in the schema, including the ISO format and the locale fallback behavior. The description does not add syntax or format details for the parameters beyond what the schema provides. Baseline 3 is correct when the schema carries the full 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+resource (travel weather for a whole country) and enumerates the exact outputs (travel score, sleep score, solar yield, driving conditions, etc.). It explicitly distinguishes itself from the sibling get_city_travel_weather by scope.

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?

Names the alternative (get_city_travel_weather) for city-level queries and lists concrete user questions that should trigger this tool: 'what the weather is like in a country', 'where in a country it is warmer/colder/sunnier', 'which cities are best or worst this week', 'whether it is too cold or rainy to sleep in a van now'. This is explicit when-to-use guidance with a clear boundary against the sibling.

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, openWorldHint, and destructiveHint=false, so the safety and caching profile is covered. The description adds two genuinely useful facts beyond that — 150+ currency coverage and daily rate updates (data freshness) — but says nothing about rate type, latency, or rate limits.

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, well front-loaded, but the second sentence largely duplicates the first ('converting an amount between currencies') and adds only the vague 'exchange rates' use case. Roughly half the text does not earn 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?

An output schema exists, so return-value explanation is unnecessary, and annotations carry the safety profile while the schema carries full parameter detail. What remains — purpose, currency coverage, and update cadence — is present, leaving only minor gaps around rate semantics.

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 all four parameters, including the enum-rich locale field with its per-call instruction, are documented in the schema itself. The description contributes no parameter-level meaning, so the baseline of 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 and resource: converting an amount between two currencies, and adds live-rate scope (150+ currencies, daily updates). It doesn't differentiate from siblings because no sibling operates on currency, so nothing further is needed.

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 second sentence, 'Use it for exchange rates and converting an amount between currencies,' is a restatement of the purpose rather than conditional guidance. No when-not-to-use, no prerequisites, and no alternative tool is named — though the sibling list contains no competing currency 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context: each rule ships with a verbatim official quote and source link, and a country without data returns an error rather than an empty result. That error semantics disclosure is the kind of thing 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?

Front-loaded with the core purpose and the most decision-relevant detail (error behavior) before the usage sentence. The content list is repeated twice (once as 'food bans, cash declaration, alcohol and tobacco limits…' and again as 'alcohol, tobacco, cash, meat and other food, goods limits'), which is mild redundancy 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?

An output schema exists, so the description need not explain return structure; it still usefully notes the quote/source-link payload and the error-on-missing-data behavior. With 100% parameter coverage and full annotations, the agent has everything needed to call it correctly, leaving little beyond a sibling comparison unaddressed.

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 country_code, from and locale are fully documented in the schema. The description adds only the implicit point that the 'from' country is optional and origin-sensitive; it contributes no syntax or format beyond what the schema already provides. Baseline 3 is correct.

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 ('Customs rules when driving into a country') and enumerates the covered domains (food bans, cash declaration, alcohol/tobacco limits, goods value, fuel canister). It does not explicitly name a sibling such as get_vehicle_import_rules, so the boundary is left implicit, but the purpose is unmistakable.

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 it for what you may bring in by car: alcohol, tobacco, cash, meat and other food, goods limits' gives clear positive context, and the error-case warning ('never present that as nothing is restricted') is genuinely useful guidance. There is no explicit when-not-to-use or named alternative, 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond what those hints provide — no mention of rate limits, auth, or whether a missing slug errors versus returns empty.

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 the verb, resource, and retrieval key all present and no filler. Every word 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?

With an output schema present, return values need no explanation, and rich annotations cover the safety profile; the description therefore only needs to establish scope, which it does. Minor gap in not acknowledging the missing-event behavior or the list_events prerequisite.

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 locale parameter has a rich description covering language/units fallback behavior. The description adds no parameter meaning beyond what the schema already documents, so the baseline of 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 (get), resource (vanlife event), and scope (single, by slug), which cleanly distinguishes it from the list_events sibling without needing the schema. It falls short of 5 only because it does not name the sibling or a distinguishing boundary 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?

The word 'single ... by its slug' implies the tool is for retrieving one known event, and the required slug implies a prior list/search step, but neither is stated. No alternatives (list_events) or prerequisites are named, leaving usage 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 openWorld, so the safety profile is covered. The description adds useful scope behavior: coverage across all API-supported countries, the full fuel-type set, and that omitting country_code downgrades the response to a summary list. It says nothing about data freshness beyond 'current' or rate limits, so it is not 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?

Front-loaded with the resource, then the fuel coverage, then the parameter behavior. The final sentence largely repeats the country_code behavior already stated one sentence earlier, which is mild redundancy, though the petrol/gasoline/autogas synonyms add value for query matching.

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, and the description covers scope, fuel types, and both operating modes. The main gap is that it never routes the agent away from the closely related compare_fuel_prices and find_cheapest_fuel siblings, which are the most likely mis-selection candidates.

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 documents both locale and country_code in detail. The description's 'Pass country_code to get one country in detail; omit it for a summary list' restates what the schema field description already says, and it ignores locale entirely. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Current retail fuel prices') and enumerates the covered fuel types, so the agent knows exactly what data comes back. It also distinguishes the two operating modes (single country vs. overview). It stops short of naming the directly competing siblings (compare_fuel_prices, find_cheapest_fuel), so an agent could still pick the wrong fuel tool.

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 when-to-use context: 'Use it for the price of petrol, diesel, LPG/autogas/propane or CNG in one country; without a country it gives an overview.' This maps intent (single price vs. overview) to the presence of country_code. No exclusions or named alternatives are given, so it does not reach a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds the 400-day range limit and, importantly, the error-on-missing-data behavior that an agent must not misreport. This is genuine beyond-annotation context.

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 compact sentences with no filler, and the scope (three holiday kinds, one country, up to 400 days) is front-loaded before the error caveat. Slightly dense but 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?

An output schema exists, so return-shape explanation is not needed. With annotations covering safety and the schema covering all five parameters at 100% coverage, the description supplies exactly the missing pieces: scope, the range limit, and the error-interpretation caveat.

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 explains from/to defaults, the 400-day cap, the kind enum, and locale. The description adds only the note that school holidays are often regional with ISO 3166-2 codes and that traffic days are France-only, which mostly duplicates the schema's kind description. 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 set — public holidays, school holidays, and official peak traffic days — scoped to one country over a bounded period, which is unambiguous. It lacks an explicit verb framing and does not name a sibling, but no sibling tool covers holidays, 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?

It states the use cases directly ("Use it for public holidays, days off, school holidays and peak traffic days") and gives an operational rule about error results — "never present that as 'no holidays'". It does not name a when-not case or a competing tool, but the guidance is concrete and actionable.

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, destructiveHint=false and openWorldHint, so the safety and determinism profile is fully covered. The description adds domain content about what is returned but no operational behavior such as caching, freshness, or fallback behavior when a region code is unknown. Useful, but nothing beyond what the annotations and output schema already convey.

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, the content-bearing enumeration first and the usage directive second, with no filler. The first sentence is dense with parenthetical lists but every clause maps to a real output field, so little 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?

An output schema exists, so the description need not explain return structure, and it correctly focuses on scope and content instead. For a two-parameter, read-only lookup this is close to complete; the only gap is the missing sibling disambiguation against check_license_plate and list_license_plate_countries.

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 both parameters (ISO alpha-2 country, locale enum) are already described thoroughly in the schema, including the instruction to set locale on every call. The description adds no parameter-level detail (e.g. country-code case sensitivity), so the schema does all the work; baseline 3.

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 concretely enumerates the resource contents: a country's plate format (standard, size, format), plate types (diplomatic, police, taxi), and region codes grouped by region, with concrete examples (77, 199). This tells the agent exactly what data comes back. It never differentiates itself from the closely named siblings check_license_plate or list_license_plate_countries, so it stops just short of a 5.

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 second sentence gives explicit trigger conditions — 'Use it for what a plate region code means ... and a country's plate format.' That is clear, actionable context. However, it offers no exclusions and does not name the alternative tools (e.g. check_license_plate for validating an actual plate), which the routing agent would benefit from.

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 the read-only, idempotent, non-destructive profile, so the description only needs to add context — and it does: output is an inline PNG plus SVG/PNG links, the number must match the country's standard format, and several plate classes are refused. No auth, rate-limit, or failure behavior is described, but for a stateless rendering tool that is minor.

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 short front-loaded sentences with no filler; the scope restriction appears before the closing usage line. The final sentence ('Use it to draw or show a picture of a plate') partially restates the opening, costing a little tightness.

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

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

With an output schema present, return values need not be explained, and all four parameters are fully described in the schema. The description covers scope, format constraint, and output media; only error behavior for a malformed/invalid plate number is left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'number' constraint ('must match the country's standard format') but adds nothing about region handling or the locale parameter, which the schema already documents thoroughly.

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 ('Draw an illustrative image of a country's standard civilian license plate') and immediately scopes it to civilian standard plates, excluding official, police, military and diplomatic ones. This separates it cleanly from siblings like check_license_plate (validation) and get_license_plate_country (metadata).

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 it to draw or show a picture of a plate' gives a clear positive trigger, and the official/police/military/diplomatic exclusion defines when-not for plate categories. However, it never names the alternative tools (check_license_plate, list_license_plate_countries) an agent might confuse this with, so routing 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral facts: that the response includes the source of the value, and that the CEE17 campsite hook-up data is Europe-specific — a real geographic scope limit not visible in 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?

Front-loaded with the returned data types, which is the right ordering. The second sentence largely restates the first ('socket and plug types', 'mains voltage', 'campsite hook-ups'), so a small amount of redundancy keeps it from a 5.

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

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

An output schema exists, so return values need no further explanation, and the read-only annotations carry the safety burden. With the required country_code, the locale behavior, and the Europe-only caveat all accounted for, an agent has everything needed to call this 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%, with both country_code (ISO 3166-1 alpha-2) and locale fully documented in-schema. The description only echoes 'one country', adding no format or syntax detail 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?

The description names a precise resource set — IEC plug types A–N, mains voltage and frequency, value provenance, and the CEE17 campsite connector — scoped to 'one country'. No sibling tool touches plugs/voltage, so an agent can select this unambiguously from the tool list.

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 second sentence explicitly enumerates the query intents it serves (socket/plug types, adapters, mains voltage, campsite hook-ups), giving clear when-to-use context. It stops short of exclusions or naming an alternative, though no sibling overlaps this domain.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the batch limits (up to 10 passports) and hints at a 'tightest leg' aggregate in the response, which is modest extra context but no auth, rate-limit, or failure-mode detail.

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 route-scoping benefit front-loaded and no filler. It is dense but readable; the closing 'plus the tightest leg of the route' clause is informative though slightly compressed.

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, and the 100%-covered input schema handles parameters. The description covers what the tool does for a 4-param, one-required read tool; only cross-tool routing guidance is thin.

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 locale, weight, countries and passports are all already documented with semantics and enums. The description restates the passport limit (10) but adds no format or meaning beyond the schema; baseline 3 is correct.

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 (visa rules) scoped to a route, plus the batch capability (up to 10 passports) and the distinguishing 'tightest leg' output. It differentiates itself from siblings like check_visa_rules by implication of route-wide batching, but never names the 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?

Usage is implied by the framing ('in one call', multi-country, multi-passport), which suggests this is the batch/route variant, but there is no explicit when-to-use vs. check_visa_rules guidance or exclusion criteria. An agent must infer the routing from the phrasing alone.

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 the safety profile is fully covered. The description adds useful content context (verification date and source per entry, vehicle classes) but says nothing about pagination, rate limits, or response structure beyond what the output schema likely provides.

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 resource and its contents, then usage. The long content enumeration is dense but each item adds informational value; 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?

Output schema exists so return-value explanation is unnecessary, and annotations cover safety. The description sufficiently conveys scope and content for a two-parameter read tool; only the relationship to the route-toll sibling is left implicit.

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 both country_code and locale are already well documented in the schema. The description implies country scoping and the vehicle-class dimension but adds no syntax or format detail 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 specific resource (toll reference for one country) and enumerates concrete contents: payment system, per-km rates by vehicle class, vignette prices, concession sections, toll bridges/tunnels. It does not name or distinguish itself from the sibling estimate_route_tolls, which covers a closely related route-based use case.

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 second sentence gives clear context: use it for toll roads, motorway fees, and whether/at what cost a vignette is needed in one country. However, it never names the obvious alternative (estimate_route_tolls) or states when a per-route estimate is preferable, so there are no explicit exclusions.

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, openWorld, and non-destructive, so the safety profile is covered. The description earns credit by disclosing the external data provenance (FCDO + GDACS), the alert-level scale, and importantly that this is a point-in-time snapshot rather than a forecast — a real behavioral constraint not captured by the 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?

Three compact clauses: scope and contents first, the freshness caveat second, usage triggers last. No filler and nothing repeated from the schema or annotations.

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

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

An output schema exists, so return-value details are not needed. Given the read-only, single-lookup nature of the tool and the annotation coverage of safety, the description supplies everything needed to select and call it correctly: source, scope, freshness semantics, and the alert scale.

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 both parameters are well documented in the schema itself (country_code format, locale language/units behavior). The description adds nothing about either parameter, 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 scoped to 'one country' and enumerates the two concrete data streams it returns (UK FCDO advisory level and GDACS disaster events with green/orange/red alert levels). This distinguishes it cleanly from siblings like get_country_travel_brief, get_active_fires, or get_country_travel_weather.

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 intents ('whether it is safe to go to a country now', 'travel warnings or natural disasters') and a negative boundary ('Not a forecast'). It does not name a sibling to use instead for related needs (e.g. fire-specific or weather queries), so routing when this is the wrong choice is left partly 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, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the coverage caveat that an unverified country 'returns nothing rather than a guess', telling the agent that an empty result means no data rather than an error or a zero-day allowance.

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 with zero filler: the second sentence, the coverage caveat, is arguably the most decision-relevant information and is given equal weight. Nothing is repeated from the schema or annotations 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?

With only two well-documented parameters, rich read-only annotations, and an output schema handling return shape, the description needs to cover only purpose and surprising behavior — and it does both, including the empty-result semantics. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — both 'country' and 'locale' are documented in the schema, including the locale enum and its fallback behavior. The description adds only 'in one country', which restates the single-country scoping already implied by the required country parameter. Baseline 3 is correct when the schema carries the parameter semantics.

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

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

The description names a specific resource — temporary admission rules for a foreign-plated vehicle in one country — and enumerates the exact facts returned (allowed days, per entry vs per window, carnet, green card). An agent can tell it apart from general customs or visa tools on field content. It stops short of 5 because no sibling (e.g. get_customs_rules, check_visa_rules) is explicitly contrasted.

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 tool name and the phrase 'in one country', which makes the country-scoped lookup obvious. However, there is no explicit statement of when to use this versus get_customs_rules or check_visa_rules, and no prerequisites or exclusions are given. Adequate but with a clear routing 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 declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds genuinely new behavioral context the annotations cannot convey: the temporal scope ("today's conditions and the coming days, not a forecast for a later month") and the warning that warmest ranking puts deserts first.

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, then progressively narrower guidance. Somewhat dense with parenthetical examples and guillemets, but every clause carries routing information rather than 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 an output schema present, return values need no explanation, and the description covers scope, ranking mode, region handling, and the key temporal pitfall. The only omission is any mention of locale/units behavior, which is left to the schema description.

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 goes beyond the schema by explaining intent mapping ("warm and pleasant" → default score; region=europe example) and the consequence of sort=warmest. It does not add format details for limit/locale 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?

Starts with a concrete verb+resource: "List the N countries where today's weather is best for travelling by campervan, highest 0-100 travel score first." It also implicitly separates itself from the per-place siblings (get_country_travel_weather, get_city_travel_weather) by being the global ranking tool.

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 conditions: "when no country is named and someone asks where to go for warm or good weather right now," plus the region variant and a precise exclusion rule for sort=warmest that disambiguates "warm and pleasant." It also states the negative case (later-month forecasts are out of scope).

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds domain scope (what counts as an event) but omits a meaningful behavioral trait: the schema default status='upcoming' means past events are excluded unless overridden, which an agent would not learn from the description.

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 compact sentences, front-loaded with the resource and scope, then the filter options. No redundant or filler text.

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, and the annotations carry the safety profile. The only real gap is the undisclosed default status filter, which is a minor but relevant omission for a list 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 83% and the enums and locale parameter are already richly documented in the schema. The description names the filterable dimensions but adds no syntax, defaults, or format detail (e.g. the 2-letter country code, the limit cap) beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb ('List') and resource ('vanlife events'), then enumerates the event categories it covers (expos, festivals, meetups, forums, road trips) and the filter dimensions. This clearly separates it from the singular sibling get_event.

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 filter list ('status, type, country, or free-text search') implies how to narrow results, but there is no explicit when-to-use guidance, no mention of the alternative get_event for fetching a single event, and no exclusions. Usage is inferable but not stated.

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, openWorldHint and destructiveHint=false, covering the safety profile for this catalog lookup. The description only adds that results include a code, region count and sample plate — useful for interpreting output, but not much behavioral depth beyond the 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?

A single compact sentence that front-loads what the tool returns and contains no filler or redundancy.

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 explain return structure, and it already summarizes the payload fields. For a single optional-parameter read-only catalog tool this is essentially complete, lacking only sibling routing guidance.

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 'locale' parameter is fully documented in the schema, including its fallback behavior. The description adds nothing about the parameter, 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 clear verb-resource pairing (listing countries for which license plate data exists) and even previews the returned fields (international code, region count, example plate). It does not explicitly differentiate itself from close siblings like get_license_plate_country or check_license_plate, but the plural/list framing makes its role legible.

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 must infer that this is a discovery/enumeration step before drilling into a specific country via get_license_plate_country. There is no explicit when-to-use or when-not-to-use statement, nor any reference to 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value by disclosing what the output contains and that it 'Returns a link to the full roadbook the user can open, edit and share'. It does not mention that generation may be asynchronous or require polling get_roadbook_build_status, which is the one behavioral trait still hidden.

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 and the trailing sentences about the returned link and the 'use this first' routing rule are well placed. The middle sentence is a long comma-heavy enumeration of outputs that is dense to parse, though each item does earn 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?

With an output schema present, return values need not be explained, yet the description still summarizes them; all 17 parameters are covered by the schema. The only meaningful omission is the async/roadbook-build workflow implied by the get_roadbook_build_status sibling, which the description does not address.

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 all 17 parameters are individually documented with formats, enums, ranges and defaults. The description restates only the 2-10 waypoint bound and the budget categories, adding no syntax or semantics beyond the schema, so the baseline of 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 gives a specific verb and resource ('Plan a road trip by campervan or car between 2-10 places with the OpenVan.camp roadbook') and enumerates the concrete outputs (distance, driving time, day-by-day plan, budget, per-country entry rules, Schengen 90/180, LEZ stickers, holidays, plugs). It is clearly distinguishable from narrower siblings such as get_route_visa_rules, estimate_route_tolls or get_country_travel_brief, which cover only single slices of what this tool bundles.

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 first when the user describes a trip from A to B' gives an explicit trigger and priority ordering relative to the sibling lookup tools. It stops short of naming when NOT to use it, and given the existence of get_roadbook_build_status it never explains the follow-up workflow if the roadbook is still building.

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 openWorldHint, so safety is covered; the description adds the index interpretation (100 = world average) and the consequential locale behavior (answer and interactive card language/units, fallback to app interface language). It omits tie-breaking or coverage caveats, but adds real context beyond the 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?

Two sentences, zero filler, with the ranking behavior and index scale front-loaded before the routing sentence. 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?

A read-only listing tool with zero required parameters, documented defaults, three enums and an output schema that carries the return shape. Nothing needed for correct invocation is missing, and the locale caveat covers the one behavior the schema underplays.

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%, with enums and defaults documented for order, region, locale and limit, which sets the baseline at 3. The description restates the order semantics but adds no syntax or edge-case detail beyond what the schema already provides for any parameter.

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 (rank) and resource (countries by food price index), defines the index scale (world average = 100), and specifies the scope (region or worldwide). The 'use it when someone asks where food or groceries are cheapest' framing also implicitly separates it from sibling tools like compare_food_prices and get_country_food_prices, which answer different questions.

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 condition: use when a user asks where food/groceries are cheapest or most expensive. That is clear context for invocation, but it never names the alternative siblings (compare_food_prices, get_country_food_prices) or states when those should be preferred, so there is no explicit exclusion.

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, openWorldHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the exact fields returned per story, the 300-character summary cap, publisher credit/linking, and the explicit 'Never returns full article text' constraint, which shapes agent expectations about completeness of results.

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 tightly packed sentences: scope and provenance first, return shape second, filter axes last. Every clause carries information and nothing is repeated 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?

An output schema exists, so return values need not be fully specified, yet the description still summarizes them. Scope, source, filtering, and the no-full-text limitation are all covered, leaving nothing an agent needs in order to call this 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 80%, so the schema already documents each filter (including a detailed locale explanation) and the 1-20 limit bounds. The description restates the filter axes (headline words, category, country, language) without adding format or syntax detail, 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 (Search) and resource (recent news about campervans, motorhomes and road travel), names the data source (OpenVan.camp from public news sources), and enumerates the filter dimensions. No sibling tool in the list covers news, so the agent can distinguish it immediately.

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 description establishes the content domain clearly, which implies when it is useful, but it never states when to use it versus other tools nor any exclusions or prerequisites. With no sibling overlap this is minor, yet the guideline burden 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.