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 useful behavioral context: look-alike letter normalization, region-code inference, and a privacy boundary stating it never identifies the owner or vehicle location.

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 short, front-loaded, and covers the main behavior in the first sentence. The final sentence, "Use it to check a specific plate number," is somewhat redundant with the opening sentence.

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 full schema coverage, an output schema, and complete annotations, the description adds the necessary remaining context: validation scope, normalization, region inference, type filtering, and privacy limits. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description reinforces the type parameter's purpose and mentions normalization, but adds little beyond the schema's own parameter descriptions.

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

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

The description uses a specific verb and resource: validate a plate number against a country format and identify the region code. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as get_license_plate_country or get_license_plate_image.

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 a clear use case: "Use it to check a specific plate number," and explains that the type parameter checks against a specific plate type's format. It does not explicitly name when not to use it or which sibling tool to choose instead.

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

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

Annotations already convey read-only, idempotent, open-world behavior, so the bar is lower. The description adds real value beyond them by disclosing that answers carry a confidence level and source and instructing the agent to propagate them rather than asserting rules as certain — a meaningful epistemic caveat not encoded anywhere in structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the scope, then a distinct instruction about confidence/source. Dense but every clause earns its place by naming a returned dimension. The first sentence is long and list-heavy, but not wasteful.

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 an output schema exists, the description needn't explain return shape, and annotations cover the safety profile. It fills the remaining gaps — the domains checked and the uncertainty/attribution requirement. The only missing element is disambiguation from sibling country/vehicle-rule 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 100%, so the schema already documents passport, destination, locale, plate, and weight in detail. The description adds only indirect hints — 'passport and destination' framing and the mention of 'temporary vehicle import,' which gestures at plate/weight — but never names or explains any parameter. 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 and resource (entry rules for one passport/destination) and enumerates exactly what is returned: entry mode, allowed stay length, day-counting method, visa-run reset behavior, and temporary vehicle import. It does not distinguish itself from close siblings such as get_route_visa_rules, get_customs_rules, or get_vehicle_import_rules, which is the only thing keeping it from 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?

Usage is implied by 'entry rules for one passport and destination' but there is no explicit when-to-use or when-not-use guidance, and no routing to alternatives. With siblings like get_route_visa_rules and get_vehicle_import_rules in the same family, an agent could easily pick the wrong one; the description gives no help there.

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 safety and idempotency are covered. The description adds genuine value beyond that by explaining the index semantics (world average = 100, higher = more expensive), which is interpretation an agent needs and cannot get from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences: the first establishes purpose and scale, the second establishes the usage trigger. Nothing is redundant and the most important framing (the index scale) is front-loaded.

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

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

With an output schema present, annotations covering the safety profile, and full schema documentation, the description only needs to add interpretation and routing. It handles the index semantics and a usage trigger well, though it stops short of distinguishing this tool from its food-related 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 coverage is 100%, with both 'from'/'to' ISO codes and the 'locale' enum fully documented (including the fallback behavior when locale is omitted). The description adds no parameter-level detail beyond the schema, so the 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 (compare) and resource (food price index) and explains the scale so the agent knows what the number means. It does not differentiate itself from food-related siblings like get_country_food_prices, rank_food_prices, or the analogous compare_fuel_prices, leaving the agent to infer the distinction from the name alone.

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

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

Gives an explicit trigger: 'when someone asks where food is cheaper between two countries.' This clearly sets context but names no alternatives or exclusions, so the agent must independently figure out when to prefer get_country_food_prices or rank_food_prices instead.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is settled. The description contributes beyond that by disclosing the return ordering (sorted cheapest-first), which meaningfully changes how an agent presents 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 short sentences with zero filler: capability and scope first, return shape second, usage trigger third. Every sentence carries information an agent needs.

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

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

An output schema exists, so return values need no explanation, and the annotations cover safety semantics. What remains uncovered is edge behavior with unrecognized or unsupported country codes; a brief note on that would close the gap.

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_codes bounds, the fuel_type enum with its diesel default, and the locale enum are already fully documented in structured fields. The description only restates the count range and single-fuel-type scoping, adding no new syntax or edge-case meaning.

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

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

States a specific verb and resource (compare fuel prices) and scopes it precisely: one fuel type across 2-10 countries. This implicitly separates it from get_fuel_prices (single country) and find_cheapest_fuel, though neither sibling is named 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?

Gives an explicit trigger condition: use when someone asks which of two or more named countries has cheaper or more expensive fuel. It does not state when NOT to use it (e.g., a single country query should go to get_fuel_prices), so an agent must infer the exclusion from the 2-10 country constraint.

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 safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real behavioral context beyond them: 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 should relay. It does not mention latency or rate limits, so 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?

Three tight sentences with zero padding: capability and output first, the partial-data caveat second, the routing constraint last. No restatement of the title and nothing that could be cut without losing 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-value structure need not be explained, and annotations carry the safety profile; the description supplies output granularity and the partial-result caveat. Slightly incomplete in not indicating that a country waypoint resolves to its capital (left to the schema) or roughly how partial results appear, but nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so waypoint limits, the locale behavior, and the vehicle_class enum/default are fully documented in structured fields. The description mostly restates the 2-10 place-name bound already in the schema and adds no meaning for vehicle_class or locale. 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+resource ('Estimate toll cost for a road trip'), the input shape (2-10 place names), and the output form (EUR range with per-country breakdown). It also names the sibling it is not — plan_road_trip — so the agent can distinguish the two without opening schemas.

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

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

Explicit routing: '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 when and the when-not with a named alternative are present.

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 the safety profile is covered. The description adds ranking-order behavior and route-planning relevance, but does not discuss data freshness, coverage limits, or response format.

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 front-loaded with the ranking behavior and remains fairly short. The final sentence repeats the cheapest/most-expensive examples and region/worldwide scope already implied earlier, adding some 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 full schema coverage, an output schema, and safety annotations, the description provides enough context to call the tool correctly. It does not need to explain return values, though mentioning locale usage could have made it fully self-contained.

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 five parameters are already documented in the input schema. The description reinforces the order and region behavior but adds little beyond the schema for limit, locale, or fuel_type.

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 clearly states the specific action: ranking countries by fuel price within a region or worldwide, with optional ordering. It does not explicitly distinguish itself from siblings like compare_fuel_prices or get_fuel_prices, so it stops 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?

It gives concrete usage contexts such as «where is fuel cheapest» and «where is fuel the most expensive», including the order parameter needed for the latter. It does not state when not to use it or name alternative tools, so it lacks 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?

Annotations already declare read-only, idempotent, open-world, non-destructive, so the description doesn't need to restate safety. It adds valuable provenance and quality caveats beyond the annotations — data comes from OSM, the operator site is 'checked by hand' and booking links exist only 'where confirmed', and timetable availability varies. It does not mention result caps or ordering, which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and scope, then the bounding-box convention, then narrowing and use cases — a logical progression. The attribute list sentence is long but each item conveys what a caller can expect, though it could be trimmed slightly.

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

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

With an output schema present, the description need not explain return values, and it still summarizes the fields available. For a read-only spatial search, what remains unstated is only result limits/density behavior in a large bbox, a small but real gap for an open-world query tool.

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

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

Schema coverage is 100%, so the schema already documents bbox ordering, query matching, country_code, cars_only default, and locale. The description mostly repeats the bbox longitude-first convention with the same kind of geographic example already in the schema, adding only the hint that query targets ports or operators. 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?

Names a specific verb and resource ('Ferry and river crossing lines in a bounding box from OpenStreetMap') and enumerates the returned attributes, so the agent knows exactly what it gets. It also distinguishes itself from the sibling get_ferry_schedule by positioning itself as the discovery step that supplies that tool's id.

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

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

Gives concrete usage scenarios ('which ferries go to an island or across a sea, strait or river') and an explicit follow-on routing ('to get the id for get_ferry_schedule'). It also names narrowing strategies (query for port/operator, country_code), leaving little 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 genuinely new behavior: the upstream source, the 48-hour freshness window, the hard 10°×10° size cap, and the ranking/unit of returned values. It doesn't say what happens when the bbox exceeds 10° (error vs. rejection), which is the one operational gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what the tool returns before the usage and format guidance. Every clause carries information — source, window, limit, ordering, units, usage, format, example — with no filler.

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

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

With rich annotations, an output schema and full schema description coverage, the description needs only to frame the data and the input format, which it does. The only omission is failure behavior when the bounding box exceeds the 10° cap, which matters for an open-world remote query.

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 would be 3, but the description goes further by calling out the ordering hazard explicitly ("longitude first") and supplying a second real-world example (Portugal) alongside the schema's Antalya example. That targets the single most common failure mode for bbox strings; the `locale` parameter is left to the schema.

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

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

Names a specific verb and resource (satellite fire detections), plus the source (NASA FIRMS VIIRS), the temporal window (last 48 hours), the spatial scope (bounding box up to 10°×10°), the sort order (strongest first) and the unit (MW). No sibling tool in the list deals with fires, so the agent can identify this 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?

"Use it for wildfires right now near a place or in a country" gives a clear positive trigger with the recency constraint built in. It doesn't name an alternative or state exclusions, but no sibling covers fire detections, so the missing exclusion is low-risk.

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 does add genuinely useful methodology context (ERA5 2021–2025, median of 35 archive days, date ±3 days over five years) and the 'climate not forecast' caveat that a naive agent would otherwise miss. It stops short of describing response shape or any limits, but the data-provenance caveat is the main behavioral risk here and is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the 'climate, not a forecast' distinction, then usage routing. The opening sentence is very dense with a long clause list of returned quantities, but each element is informative and no sentence is filler.

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

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

An output schema exists, so return values need no explanation; the description covers provenance, the climate-vs-forecast caveat, the date/omit-date decision, the city-vs-coordinates decision, and the sibling boundary. Nothing an agent needs to select or 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% and the schema already documents lat/lng vs city, the MM-DD / YYYY-MM-DD pattern with year-ignored, and the locale fallback. The description mostly reiterates this (omit date → month overview, city vs point), adding little syntax the schema does not already carry. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific resource (typical weather / climate normals) with explicit scope: city or any lat/lng point, on a given day of the year, from a named archive. It explicitly names the sibling it is not (get_city_travel_weather) and marks the boundary ('Climate, not a forecast'), so an agent can route between the two without opening either schema.

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

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

Gives explicit when-to-use ('dates beyond the coming week', 'when is the best time to go'), explicit when-not ('for today and this week use get_city_travel_weather'), plus concrete example queries. It also states the omit-date behavior, so the parameter-level decision is guided too.

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 what the payload actually contains (ranking within country, best stretch, worst day, per-score breakdown, ready-made advice), which is useful behavioral context. It does not, however, say what happens when a city name is ambiguous or unresolvable, which matters for an openWorld lookup.

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 routing and scope sentences are excellent and front-loaded, but the opening sentence is a long run-on enumeration of output fields that largely duplicates the output schema. Trimming that list to a summary would sharpen the definition without losing 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 and full annotations present, the description need not explain return values, yet it still covers purpose, sibling routing and time scope. The only real gap is failure/ambiguity behavior for an open-world place lookup, which 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%, including the city examples, the locale guidance and the country_code disambiguation case, so the description adds little parameter meaning. The phrase 'one city or town' and the example place names merely echo the schema, warranting the 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 first sentence states a specific verb-and-resource combination (weather suitability in one city for campervan travel and sleeping) and quantifies the output as a 0-100 score. It is immediately distinguishable from get_country_travel_weather, which is named explicitly later.

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 direct 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 timing ('today, tomorrow or this week'), covering both when-to-use and which-alternative-not-to-use.

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 non-obvious behavior – the index is normalized to a world average of 100 and the response carries a yearly history rather than a single point value. It stops short of describing pagination or history span, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, and the scale anchor is front-loaded before the usage cue. Nothing here repeats the name or title verbatim.

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; the description supplies the interpretive key (100 = world average) that makes the numbers meaningful. Coverage of the locale parameter's purpose is left entirely to the schema, a minor gap for a 2-parameter tool.

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

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

Schema coverage is 100%, and the description adds nothing about country_code (ISO alpha-2) or the locale parameter's effect on language and units. With the schema doing all the parameter work, 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+resource ('Food price index for one country') and adds the scale (world average = 100) plus the fact that yearly history is included. The 'one country' framing implicitly separates it from compare_food_prices/rank_food_prices, but neither sibling is named outright.

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 how expensive food, groceries or living is in a country.' That is clear context, but it names no alternatives or exclusions even though compare_food_prices and rank_food_prices exist and would be the natural competitors for multi-country questions.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive behavior, so the description is free to add value elsewhere — and it does, disclosing the response's breadth and time semantics ('weather now and this week', 'holidays in the next 30 days', 'with passport'). It does not state data freshness beyond those windows, upstream sources, or rate limits, which keeps it short of 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?

Two sentences, front-loaded with the payoff ('Everything to know ... in one call') before the coverage list and the routing rule. The coverage enumeration is long but each item is a real capability, not filler; a bulleted or grouped phrasing would read slightly faster.

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 shape, and the annotations carry the safety profile, so the remaining job — telling an agent what topics the brief aggregates and when to prefer it — is done. The one gap is that it never warns the caller how broad the payload may be relative to a narrow sibling 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 a bump by tying the optional `passport` parameter to a concrete effect ('adds the entry rule and how long the person and the vehicle may stay'). Locale and country_code semantics remain entirely schema-side.

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

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

Opens with a specific verb+resource+scope: everything to know before driving into one country by campervan or car, in one call. The enumerated coverage (entry rule, weather, fuel, tolls, holidays, hazards, plugs, customs, food prices) makes it unmistakable against the many single-topic siblings such as get_visa_rules 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?

Explicitly states the triggering intents (asking what to know about a country, the nuances, a guide, preparing a trip) and an explicit exclusion routing to 'the single-topic tools for one narrow question.' Alternatives are named as a class with the condition that selects them.

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 safety is covered; the description adds real behavioral value by enumerating the specific metrics and the geographic scope (country-level aggregation, best/worst cities for the coming week). It stops short of noting rate limits, data freshness, or that results are forecast-based rather than historical, but the additions are substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core concept (0-100 suitability score) is front-loaded, followed by the returned metrics and then routing/trigger guidance. The metric enumeration is long but each item earns its place by telling the agent what questions the tool answers; minor tightening would raise this to a 5.

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

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

With an output schema present and rich annotations, the description needn't document return structure — and it doesn't. It covers scope, sibling routing, and example use cases, leaving only minor gaps (forecast horizon semantics beyond '7-day', data source/freshness) that are not essential to correct invocation.

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% — country_code is documented as ISO 3166-1 alpha-2 and locale as the display language — so the schema does the heavy lifting. The description only implies country-level input via 'Country-level' and adds no format or enumeration detail beyond the schema, warranting the 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?

States a specific resource (country-level travel weather) and what the tool returns: a 0-100 travel/sleep score, solar yield, driving conditions, awning safety, condensation risk, 7-day forecast, and best/worst 3 cities. It explicitly contrasts with the sibling get_city_travel_weather, so an agent can distinguish the two without opening either schema.

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

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

Names the alternative (get_city_travel_weather for a named city) and enumerates concrete triggering questions: what the weather is like in a country, where it is warmer/colder/sunnier, which cities are best/worst this week, whether it is too cold or rainy to sleep in a van. When-to-use and when-not-to-use are both explicit.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by mentioning live rates, 150+ currencies, and daily updates. It does not disclose rate source, timestamp precision, rounding, fees, or caching 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?

The definition is short and front-loads the main purpose in the first sentence. The second sentence partially repeats the first by restating exchange-rate and amount-conversion usage, but the overall structure is efficient.

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

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

This is a simple read-only conversion tool with an output schema, full parameter description coverage, and annotations covering safety and external-data behavior. The description is sufficient for correct invocation, with only minor gaps around rate provenance and freshness details.

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 from, to, amount, and locale in detail. The description reinforces the core conversion semantics but adds little beyond the schema, and it does not mention the locale parameter or its UI-language effect.

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: convert an amount between two currencies using live rates. It also states coverage (150+ currencies) and freshness (daily updates). It does not explicitly differentiate from siblings, though none of the listed siblings appear to be direct currency-conversion alternatives.

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 says to use it for exchange rates and converting an amount between currencies, which gives a clear implied usage context. However, it does not give explicit when-not conditions, prerequisites, or alternatives, so the guidance remains minimal.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses that every rule carries a verbatim official quote and source link, and warns that a country without data returns an error which must not be reported as 'nothing is restricted' — a genuine failure-mode trap an agent would otherwise fall into. It does not cover rule freshness or caching, so 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?

Purpose is front-loaded in the first clause, the error caution is second, and the use case closes it. The final sentence partly restates the topic list already given in sentence one, which is mild redundancy but keeps the text scannable.

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 full parameter documentation, the description carries only the burden of scope and failure semantics, which it does well. It leaves locale/language behavior to the schema, which is acceptable given the parameter description covers it explicitly.

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

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

Schema coverage is 100%, so the schema already explains country_code, from, and locale in detail (including the 'no customs inside the EU' nuance). The description only lightly gestures at the optional origin country ('optionally from a given country') and adds nothing on locale, so it earns the baseline rather than more.

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 exact scope: food bans, cash declaration, alcohol/tobacco limits, goods value, fuel canister. This is clearly distinguishable from siblings like get_vehicle_import_rules or check_visa_rules 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?

The closing sentence gives clear usage framing ('what you may bring in by car: alcohol, tobacco, cash, meat and other food, goods limits') and the error warning sets an expectation for missing-data cases. It stops short of naming an alternative sibling or a when-not-to-use condition, so it doesn't reach the top band.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds domain scope ('vanlife event') and detail level ('full details'), but does not add extra behavioral context such as error handling for invalid slugs.

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 wasted words. It efficiently communicates the core operation.

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 output schema exists and annotations are rich, so the description need not explain return values or safety. It is mostly complete for this simple lookup, though it could better distinguish from list_events.

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 slug and locale are fully documented in the schema. The description mentions slug but adds no meaning beyond the schema for locale or slug format.

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: retrieving full details for a single vanlife event by slug. It is clear and specific, though it does not explicitly distinguish this tool from the sibling list_events.

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 'single ... event by its slug' implies usage when a slug is known and detail is needed, but it gives no explicit when/when-not guidance or mention of list_events as an alternative.

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds the genuinely non-obvious parts: data provenance from open GTFS feeds, that times are local, and the critical failure semantic that 'available: false means no open timetable is matched, not that the ferry does not run.' That caveat directly prevents a wrong inference an agent would otherwise make from the payload.

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 identity and return contents, then the important 'available: false' caveat, then usage. The opening sentence is a long clause chain that takes effort to parse, but no clause is filler.

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

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

With an output schema present, return shape need not be explained, yet the description still tells the agent what categories of data appear and how to read the false-availability case. For a read-only, two-parameter lookup with full schema coverage, nothing needed for a correct call 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 already carries detailed guidance (enum values, 'set it on every call', fallback behavior), so the schema does the heavy lifting. The description only reinforces that the id comes from find_ferries, which the schema's own id description also states — no net new parameter meaning.

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

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

States a specific verb and resource ('One ferry line by id from find_ferries') and immediately enumerates what the response contains: endpoints with country, operator site, booking link, and a GTFS-derived timetable digest. It explicitly positions itself relative to the sibling find_ferries, so an agent can tell discovery from detail without opening either schema.

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

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

The final sentence gives explicit use cases ('when the next ferry leaves, how often it runs and how long the crossing takes') and the opening phrase routes the agent through find_ferries to obtain the id first. It stops short of an explicit exclusion (e.g. 'do not use for route planning between arbitrary points'), so it is clear context rather than a full when/when-not map.

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, openWorldHint=true, so the safety profile is fully covered. The description adds useful behavioral context about the detail-vs-summary shaping of results, but says nothing about freshness of prices, rate limits, or coverage gaps for unsupported countries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the resource and coverage, then the mode switch. The third sentence largely restates sentence one in colloquial terms; it aids synonym matching but is redundant on strict reading.

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 and the safety profile is fully annotation-covered, so the description only needs to convey scope and the filter/no-filter behavior, which it does. Minor gap: no mention of price staleness or unsupported 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 coverage is 100%, including a detailed locale description and country_code semantics, so the schema carries the parameter burden. The description only restates the country_code conditional (detail vs list) and ignores locale entirely, adding little beyond what the schema already says.

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 specific verb+resource and enumerates the fuel types (gasoline, diesel, LPG, CNG, E85, kerosene), plus distinguishes the two modes (single country detail vs all-country summary). It never names or contrasts with sibling tools like compare_fuel_prices or find_cheapest_fuel, so an agent must infer the boundary itself.

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 conditional: pass country_code for one country in detail, omit it for a summary list, and names colloquial synonyms (petrol, autogas/propane) that help query matching. However it offers no guidance against the closely related siblings compare_fuel_prices and find_cheapest_fuel, which is exactly where mis-selection risk is highest.

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

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

Goes well beyond the readOnly/idempotent annotations: it warns that a country without data returns an error and must never be reported as 'no holidays', notes the 400-day cap, and flags that school holidays are often regional while traffic days are France-only. These are exactly the failure modes an agent would otherwise mishandle.

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 scope, then the critical error caveat. The final sentence duplicates ground covered by the first and could be merged, but there is no padding beyond that.

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

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

Output schema exists, so return values needn't be described. Combined with annotations and full param coverage, the description supplies the remaining essentials: data-coverage failure semantics, the date-window limit, and the geographic restriction on traffic days.

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 country_code, from, to, kind and locale in detail. The description adds only the 400-day bound (already in the schema) and a passing mention of ISO 3166-2 region codes, 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 set — public holidays, school holidays and official peak traffic days (Bison Futé) — scoped to one country over a period of up to 400 days. The scope and content are unambiguous and distinguish it from sibling tools like list_events or get_country_travel_brief.

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 closing sentence 'Use it for public holidays, days off, school holidays and peak traffic days' gives an intended-use list, but it largely restates the purpose line and names no alternative tool or exclusion condition relative to the ~29 siblings. Usage is implied rather than routed.

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 and openness profile is fully covered. The description adds only that region codes are grouped by region and that examples are included — useful but modest behavior/return-shape 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: the first front-loads the three content buckets (format, types, region codes), the second states the use case. It is dense but every clause adds scope information; nothing is redundant 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, so return values need not be explained, and the required country param is schema-documented. The description covers scope and examples adequately; the only gap is minor (no mention of how locale affects the card output, which lives in the schema anyway).

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 the country ISO code and the locale enum are fully documented in the schema. The description implies the country input via 'a country's license plate' but adds no syntax or format detail beyond what the schema already provides, 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 names concrete resource facets: plate appearance (standard, size, format), plate types with examples, and region codes grouped by region. It is clearly a lookup tool, distinguishable from check_license_plate and list_license_plate_countries by its 'explain what a code means' framing, though it never names those siblings 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 final sentence gives an explicit use case: 'Use it for what a plate region code means (77, 777, AA…) and a country's plate format.' That is a clear context statement, but there are no exclusions or named alternatives (e.g. when to prefer check_license_plate for validation instead).

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real context beyond them: the response includes an inline PNG plus SVG/PNG links, and the number must conform to the country's standard format. It doesn't say what happens when the number is malformed or the country is unsupported, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action and output format. The final sentence ('Use it to draw or show a picture of a plate') largely restates the opening, so not every sentence earns its place.

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

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

Output schema and annotations carry return values and safety, and the description covers the drawing scope, exclusions and output links. It leaves open the failure behavior for invalid formats and doesn't clarify when region should be supplied, minor gaps for a two-required-parameter render 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 description coverage is 100%, so the baseline is 3. The description reinforces that the number must match the country's standard format, which adds mild validation semantics, but it says nothing about the optional region parameter or the locale fallback behavior 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 and resource: 'Draw an illustrative image of a country's standard civilian license plate', and names the output artifacts (inline PNG plus SVG/PNG links). It also scopes out official, police, military and diplomatic plates. It does not name the sibling check_license_plate or list_license_plate_countries to sharpen the distinction, so it falls 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?

'Use it to draw or show a picture of a plate' gives a clear trigger, and 'Official, police, military and diplomatic plates are not drawn' provides an explicit when-not-to-use boundary. No alternative sibling is named for the excluded cases, so the routing guidance is incomplete.

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 this as a read-only, idempotent, open-world, non-destructive lookup, so the safety profile is covered. The description adds useful context about source attribution and Europe-only CEE17 campsite connectors, but it does not discuss invalid country codes, missing data, or other edge 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?

Two sentences, front-loaded with returned data and followed by direct usage guidance. There is 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?

The tool has rich annotations, an output schema, and fully documented parameters; the description supplies the remaining purpose and usage context. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so country_code and locale are already fully documented in the schema. The description reinforces the one-country scope but adds no parameter syntax, format, or locale behavior 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?

The description names a specific resource and scope: plug types, mains voltage/frequency for one country, the source value, and European CEE17 campsite connectors. It clearly distinguishes this lookup from unrelated sibling tools such as visa, fuel, or weather tools.

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 says to use this tool for socket/plug types, adapters, mains voltage, and campsite hook-ups, giving clear positive guidance. It does not state when not to use it or name alternatives, but no direct sibling overlap exists.

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 fully covered. The description contributes one extra behavioral fact — that the result includes 'the tightest leg of the route' alongside per-country rules — but says nothing about rate limits, error behavior for unsupported passports, or partial-route coverage, so it is helpful but thin 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 sentence with zero waste that front-loads what is returned and what makes it special (route-wide coverage, batched passports, tightest leg). Nothing is repeated from the schema and no filler is present.

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 tool is read-only with a full output schema and completely described parameters, so the description only has to establish purpose and scale — which it does. The remaining gaps are the unstated country cap (12 in schema vs 10 passports stated) and the absence of routing guidance versus check_visa_rules, both minor given the rich schema and annotations.

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 locale parameter carries unusually rich guidance (set on every call, affects answer language and units, fallback behavior), so the structured data already does the heavy lifting. The description adds only the passports cap ('up to 10'), which matches the schema, and says nothing about the weight or locale parameters, making this a baseline-plus score rather than a value-add.

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 precisely (visa rules per country along a route) and adds real scope detail: multi-country in one call and up to 10 passports. It implicitly separates itself from check_visa_rules by emphasizing the batch/route case, but never names that sibling, so the differentiation is inferred 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?

Usage is only implied: 'one call' and 'for up to 10 passports' signal the multi-passport, multi-country scenario. There is no explicit when-to-use / when-not-to-use statement, no prerequisite (e.g. passports required to get a meaningful answer), and no pointer to check_visa_rules for a single country.

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 fully covered structurally. The description adds data-provenance context ('each with verification date and source'), which is mildly useful, but says nothing about freshness lag, coverage gaps, or response shape. With annotations carrying most of the 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?

Two sentences, front-loaded with what the tool returns and followed by when to use it. The first sentence is dense but every clause maps to actual returned content, so there is little 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?

For a complex reference tool, the description adequately enumerates the returned data categories (rates by class, vignette durations, concession sections, bridges/tunnels, provenance), and an output schema exists to cover structure. It leaves minor gaps around freshness and coverage but is complete enough to invoke confidently.

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%, with the locale parameter extensively documented in the schema itself. The description adds no parameter-level detail (e.g. that country_code gates all returned reference data), so it sits at the baseline where the schema does the work.

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 ('Toll reference for one country') and enumerates its contents – payment system, per-km rates by vehicle class, vignette prices, concession sections, bridges/tunnels – so the agent knows exactly what it returns. It implicitly contrasts with route-based siblings like estimate_route_tolls by emphasizing single-country reference data, but never names that 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?

The second sentence gives clear usage context: toll roads, motorway fees, vignette need and cost, scoped to one country. That is enough to route correctly in most cases, but there are no explicit exclusions and no sibling named (e.g. estimate_route_tolls for multi-country route totals), 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond them by naming the upstream sources (FCDO, GDACS), the alert-level vocabulary and the temporal framing ('now', 'Not a forecast'). It says nothing about freshness/latency or coverage gaps, which for a live-hazard tool would be the differentiating 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?

Three front-loaded sentences with no filler; the data contents come first, then the temporal caveat, then the use case. The opening fragment ('Situation now in one country:') is slightly telegraphic rather than a clean sentence.

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 detail is unnecessary; the description covers sources, hazard types, alert semantics, time scope and the question it answers. It is complete enough for a two-parameter read tool, with only the missing sibling routing as a gap.

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 parameters are already documented, and the description only implies the single-country scope of country_code. The locale parameter, which materially affects the answer language and units, is not touched on in the description, but the schema carries that burden adequately.

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 ('Situation now in one country') and enumerates exactly what is returned: the UK FCDO travel advice level plus GDACS disaster types with green/orange/red alert levels. The explicit 'Not a forecast' clause distinguishes it from forecast-oriented siblings such as get_country_travel_weather and get_city_climate.

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 whether it is safe to go to a country now, about travel warnings or natural disasters.' It does not, however, name the near neighbours (get_country_travel_brief, get_active_fires) or state when those should be preferred instead.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is lower, and the description still adds a genuinely useful behavior: a country without a supportable rule returns nothing rather than a guess. It also names the returned data points, which is context beyond the safety hints.

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 scope and the return contents, and the no-guess fallback behavior closes it. Every clause carries information.

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

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

With an output schema present the description needn't enumerate return structure, and it still sketches the returned facts and the empty-result case. Only the relationship to neighboring customs/visa tools is left 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% and both parameters (country formats, locale enum) are fully documented in the schema, so the baseline of 3 applies. The description adds no parameter-specific meaning such as accepted country identifier forms or locale behavior.

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 and scope: temporary admission rules for a foreign-plated vehicle in one country, and enumerates the facts returned (allowed days, per entry or per window, carnet, green card). This is clearly distinguishable from siblings like get_customs_rules or check_visa_rules 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?

The one-country scoping and the field list imply when this tool is the right one, but no sibling is named and there is no explicit when-not guidance (e.g. difference from get_customs_rules). Usage is inferred rather than directed.

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

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

Annotations already cover read-only, idempotent and open-world behavior, so the description doesn't need to restate safety. Instead it discloses the ranking semantics (0-100 score vs raw temperature), that results are today's/coming-days conditions rather than a later-month forecast, and that sort=warmest puts deserts first — behavior an agent could not infer from the 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 core action and ranking order before the conditions. It is a single dense run-on paragraph with several nested parentheticals, which costs a little readability, but every clause carries a real decision rule 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?

Output schema exists, so return values needn't be explained, and annotations cover safety. What remains — when to call, how the ranking differs from raw temperature, and the temporal scope — is all present, leaving nothing an agent needs missing.

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

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

Schema coverage is 100% and enums are documented, so the baseline is 3. The description still adds decision rules the schema only partially carries, notably the disambiguation between sort=warmest and the default score and the '«in November» say so' caveat for period.

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 specific verb and resource: 'List the N countries where the weather is best for travelling by campervan, highest 0-100 travel score first.' It also names the ranking source (OpenVan.camp), which separates it from the per-country/per-city siblings like get_country_travel_weather or get_city_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 an explicit trigger ('when no country is named and someone asks where to go'), an explicit alternative routing rule ('with sort=warmest only when they literally ask where it is warmest'), and the counter-case ('warm and pleasant' → default score). It also states a scope limit for future months, which tells the agent when not to use it as intended.

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 the safety profile is covered by structured data. The description adds domain examples (Caravan Salon) but no behavioral context such as the default status filter, pagination/limit behavior, or that results reflect a live open-world dataset. Adequate but thin given annotations carry most of the load.

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 tight sentences with no waste, and the resource scope is front-loaded before the filter list. 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?

An output schema exists and the input schema is well documented, so the description needn't explain return values. The main residual gap is the absence of a pointer to get_event and the default-status behavior, which would help an agent call it correctly on the first try.

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

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

Schema description coverage is 83%, so the schema already documents type, status, country, search and even the locale default behavior. The description merely restates the filter names without adding syntax, format, or interaction detail, 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?

Uses a specific verb ('List') and resource ('vanlife events') and enumerates the event categories (expos, festivals, meetups, forums, road trips), which concretely scopes the tool. It does not differentiate from the sibling get_event, which clearly retrieves a single event, so an agent must infer the list-vs-lookup split.

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 names the available filters, which implies usage, but there is no explicit when-to-use guidance and no mention of the alternative get_event for fetching a single event. Nothing says the default status is 'upcoming', so an agent could misread results as all-time.

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 covered. The description adds only the shape of the returned records, which the output schema already provides, and says nothing about completeness of the list, ordering, or size — the traits that would actually matter 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 line with zero filler; the useful content (what the list yields) is front-loaded. It reads as a caption rather than a sentence, which is the source of its slight clarity loss, not its length.

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 explain return values, and locale is fully documented in the schema, so nothing critical is missing. Still, for a discovery tool that gates the other license-plate siblings, it gives no hint of list size, pagination, or how to proceed after listing.

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 enum documents its own behavior (answer and card language, fallback to app language) more thoroughly than the description does. The description mentions no parameters at all, 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 fragment 'Countries whose license plates are available' conveys that this enumerates the supported country set and names the returned fields (code, region count, example plate). However, it never uses an explicit verb and never contrasts itself with the singular siblings get_license_plate_country / check_license_plate, so the agent must infer that this is the 'list all supported' variant.

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 when-to-use guidance, no exclusion, and no mention of the closely named alternatives (get_license_plate_country, check_license_plate, get_license_plate_image). The agent is left to deduce the discovery-then-detail workflow from the name 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 readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds what annotations cannot: the result is a link to a full roadbook the user can open, edit and share, and it discloses the conditional enrichment (holidays and visa deadlines only with a start_date, entry rules keyed to passports/residence/plates). No rate limits or failure modes are mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with front-loaded purpose, followed by a short routing instruction; nothing is filler and every clause names a distinct output. It is long, but the length buys real coverage for a 17-parameter tool, though the mid-sentence enumeration could be split for faster scanning.

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 full schema coverage, the description only needs to convey scope, enrichment conditions and the returned artifact — all of which it does. Nothing an agent needs to decide and invoke this tool correctly is missing.

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

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

Schema coverage is 100%, so every one of the 17 parameters is already documented in the schema, including defaults and enums. The description only restates the waypoint count constraint and that passports/residence/plates drive entry rules, adding little beyond the structured data — 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?

Opens with a specific verb+resource+constraint ('Plan a road trip by campervan or car between 2-10 places') and then enumerates concrete outputs: distance, driving time, day-by-day plan, budget, per-country entry rules, 90/180 stays, LEZ/ZTL rules, holidays, plugs, checklist, shareable link. This is unmistakably distinct from every single-purpose sibling such as check_visa_rules or estimate_route_tolls.

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 closing sentence 'Use this first when the user describes a trip from A to B' gives explicit routing guidance relative to the narrower sibling tools. It does not state when NOT to use it (e.g. a single-country visa question should go to check_visa_rules), 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that by defining the index baseline (world average = 100), which tells the agent how to interpret the ranking values. Return format is left to the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero filler: the ranking semantics and sort direction come first, followed by the usage trigger. Every sentence carries information the agent needs.

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

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

With an output schema present, annotations covering the safety profile, and full schema coverage of all parameters, the description needs only to establish purpose and usage, which it does. The minor gap is that it does not note the limit interplay with ranking (top-N cheapest), though that is largely inferable.

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 four parameters (limit, order, locale, region) are already documented in the schema. The description only restates the order behavior ('order=most_expensive'), adding no syntax or constraint detail 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?

The description gives a specific verb (rank), resource (countries by food price index), the scale semantics (world average = 100), and scope (region or worldwide). This clearly separates it from sibling tools like compare_food_prices and get_country_food_prices, which per their names retrieve or compare rather than rank.

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 triggering question explicitly: 'Use it when someone asks where food or groceries are cheapest or most expensive.' That is a clear use-case signal, though it does not name a specific alternative (e.g., compare_food_prices) or state when not to use it.

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

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

Annotations already cover the read-only, idempotent, non-destructive, open-world safety profile. The description adds real value beyond that by disclosing the exact return shape (headline, ≤300-char summary, date, category, countries, link) and the important constraint that full article text is never returned, along with source-attribution 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?

Front-loaded with purpose, then return shape, then filters; no filler sentences. The middle sentence is long but each clause (fields returned, no full text, attribution) carries distinct information, so it earns its space.

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 5-param, zero-required search tool with an output schema and full annotations, the description covers purpose, data provenance, return shape and filtering. Only explicit usage/exclusion guidance is missing, which keeps it from a 5.

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?

With 80% schema description coverage, the schema already documents the parameters well, including a detailed locale description. The description's line about filtering by words, category, country and language just restates the schema fields without adding syntax or behavioral nuance, so the baseline 3 applies.

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

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

The description states a specific verb (Search) and resource (recent news about campervans, motorhomes, road travel) plus the data source (OpenVan.camp from public news sources). It is clearly distinct from the sibling tools, which are all travel-data utilities rather than news search.

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 says what can be filtered by (words in headline, category, country, language), which implies how to use it, but there is no explicit when-to-use vs. when-not guidance or mention of alternatives. Since no sibling covers news, the omission is less costly, but the guidance remains only implied.

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