openvan-travel

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

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral context beyond those hints: it discloses that results carry confidence and source and tells the agent not to overstate rule certainty. This is meaningful and aligns with the open-world assumption.

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 compact, front-loaded with the core scope, and every clause earns its place by adding a meaningful rule category or output-handling instruction. No filler or repetition of schema information.

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

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

For a read-only lookup tool with no output schema, the description covers the essential output characteristics (confidence, source) and the rule scope. It does not describe pagination or error behavior, but annotations cover safety and the schema covers all parameters, so little critical information is missing.

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

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

Schema description coverage is 100%, so the description does not need to compensate for undocumented parameters. It adds some context by mentioning 'temporary vehicle import', which ties to the optional plate and weight parameters, but does not add further input-parameter detail. 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?

The description names a specific verb-plus-resource ('Entry rules for one passport and destination') and enumerates the exact rule dimensions returned: entry mode, stay length, day counting, visa-run reset, and vehicle import. It is clear on its own but does not explicitly differentiate itself from sibling tools like get_route_visa_rules or get_vehicle_import_rules.

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 scope 'one passport and destination' implies when to use this tool versus a route-oriented sibling, but no explicit alternatives or when-not-to-use guidance is provided. The instruction to pass on confidence and source is a useful usage note for response handling, but it does not address sibling selection.

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 non-destructive behavior, so the description does not need to repeat safety. It usefully adds that prices are 'current' and the output is sorted, but it does not disclose edge behavior such as handling invalid/missing country codes, price staleness, or exact response 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?

The description is one concise, front-loaded sentence that states the action, scope, and return ordering. There is no redundant wording or repetition of schema details.

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 two-parameter, read-only tool, the combination of the description, full schema coverage, and annotations provides enough to invoke it correctly: fuel type, country codes, count bounds, and expected sorted output. It lacks explicit output field names, but no output schema exists and 'sorted table cheapest-first' gives a reasonable expectation.

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

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

Schema description coverage is 100%, with fuel_type fully enumerated and defaulted and country_codes constrained to 2-10 ISO alpha-2 codes. The description reinforces the country-count and single-fuel-type scope but adds little semantic detail beyond what the schema already provides.

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 action ('Compare'), the resource ('current prices for one fuel type'), and the scope ('across 2-10 countries'). It also specifies the return behavior ('sorted table cheapest-first'), which distinguishes it from likely siblings like get_fuel_prices or find_cheapest_fuel.

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

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

The description implies the use case: comparing a single fuel type across a bounded set of countries and getting a sorted result. However, it does not explicitly say when to use this tool instead of siblings such as find_cheapest_fuel or get_fuel_prices, nor does it mention exclusions or conditions.

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 indicate a safe read-only operation (readOnlyHint=true, idempotentHint=true). The description adds interpretive context about the index scale (world average = 100, higher = more expensive), which is useful beyond annotations. However, it doesn't disclose the exact return format or any edge-case behavior, so a moderate score 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?

The description is one concise sentence that front-loads the action and immediately provides the interpretation scale. Every phrase is purposeful, achieving high clarity with minimal words.

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

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

There is no output schema, so the description should explain what the tool returns. It explains how to interpret the index but does not explicitly state whether the output is a single number, both indices, or a difference. For a simple comparison tool, this ambiguity leaves a gap, so completeness is moderate.

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

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

The input schema provides full descriptions for both parameters (from and to as ISO alpha-2 codes), so the description doesn't need to add much. The description mentions 'between two countries' which loosely maps to the parameters but adds no additional semantic detail beyond the schema. With 100% schema coverage, 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 clearly states the tool compares food price index between two countries, using a specific verb and resource. It also explains the index scale and meaning, distinguishing it from sibling tools like compare_fuel_prices. This is a specific and clear purpose.

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

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

The description implies the tool is for comparing food prices between countries, but it does not provide explicit 'when to use' guidance or exclusions relative to alternatives such as compare_fuel_prices. While the context is apparent from the description, there's no explicit alternative naming or conditions, so it falls at the implied usage level.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the safety profile is covered without needing description. The description adds that results are ranked countries filtered by region/fuel type, but does not mention output shape, ordering guarantees, or edge cases such as fewer results than limit. This is adequate but not rich.

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

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

Two short sentences, with the core capability front-loaded and a use case in the second sentence. Every word earns its place; no filler or repetition of schema details.

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

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

For a simple three-optional-parameter tool with full schema descriptions and safe annotations, the definition is nearly complete. The description indicates the result will be a set of cheapest countries, which is the key missing output information given there is no output schema. A slight gap is not specifying whether prices accompany the country results, but this is minor.

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 default values and enums, so the description does not need to restate parameter semantics. The description mentions fuel type and region but adds no meaning beyond the schema; limit is not referred to at all. 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?

The description uses a specific verb+resource: find the cheapest countries for a fuel type in a region. It is clearly not a generic price lookup, and 'countries' distinguishes it from siblings like get_fuel_prices. However, it never explicitly names or contrasts sibling tools, so it stops short of full differentiation.

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

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

'Useful for route planning' gives an explicit context where this tool should be selected. It also clarifies the optional worldwide scope. It does not explicitly say when to choose get_fuel_prices or compare_fuel_prices instead, so it lacks an exclusion statement.

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, and non-destructive hints. The description adds useful behavioral context: live rates, 150+ currencies, and daily updates, which informs the agent about data coverage and freshness. It does not contradict any 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?

The description is a single, compact sentence that front-loads the core action and includes key constraints (150+ currencies, daily updates). No wasted words; every element adds value.

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

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

For a simple currency conversion tool with a well-documented schema and strong annotations, the description is adequately complete. It does not specify the exact return format, but given no output schema and the straightforward nature of the operation, this is a minor gap. Overall, the tool is well-specified.

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

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

The input schema provides 100% coverage for all three parameters with descriptions (from, to, amount). The description itself does not add additional parameter-level meaning beyond what the schema already conveys, so a baseline of 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?

The description clearly states the action 'Convert an amount between two currencies' with scope (live rates, 150+ currencies). This distinguishes it from sibling tools, which focus on fuel prices, events, and weather, none of which handle currency conversion.

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

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

The description implies when to use the tool (when currency conversion is needed) and provides context about live rates and daily updates. It does not explicitly list exclusions or alternatives, but since no sibling tool offers similar functionality, the usage context is clear and unambiguous.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds little beyond purpose; it does not disclose return format, error handling, or locale behavior, but this is partially mitigated by the strong 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, front-loaded sentence conveys purpose and key parameter with zero unnecessary words. It is a model of concision.

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

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

For a simple read-only tool with good annotations and a clear purpose, the description is mostly complete. However, it does not mention the optional locale parameter, and without an output schema, the phrase 'full details' is vague about return structure. These are minor gaps for such a straightforward operation.

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 50% (only slug is described). The description reinforces slug as the lookup key but adds no new meaning for either parameter. The locale parameter is completely undocumented in both schema and description, leaving a significant semantic gap.

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

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

The description uses a specific verb 'Get' with a clear resource ('full details for a single vanlife event') and scope ('by its slug'), distinguishing it from sibling tools like list_events. It unambiguously identifies what the tool does.

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

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

The description clearly implies the use case: when you need full details for one specific event identified by slug. It does not explicitly mention alternatives or exclusions, but the context of sibling tools and the 'single' wording provide clear usage context.

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 establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond that: the data is current retail pricing, it supports the same keys as the /api/fuel/prices endpoint, and the response shape changes between detailed single-country and summary list modes.

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 focused sentences with no filler. The core purpose and scope are front-loaded, followed by price-key coverage and parameter behavior. Every sentence earns its place.

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

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

For a simple one-parameter read-only tool with no output schema, the description covers the resource, price-key families, country scoping, and the two response modes. It could add unit/currency details, but the description is sufficient for an agent to invoke the tool correctly.

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

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

The schema already documents country_code fully with 100% coverage. The description adds extra semantic value by explaining the behavioral difference between providing country_code ('get one country in detail') and omitting it ('summary list'), which the schema alone does not convey.

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 identifies the resource ('Current retail fuel prices') and its scope ('all API-supported countries'), and it enumerates specific price keys. It also distinguishes this from sibling comparison/cheapest tools by framing it as the general retail price retrieval endpoint.

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

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

The description gives clear parameter-level usage guidance: pass country_code for single-country detail, omit it for a summary list. However, it does not explicitly say when to choose this tool over siblings like compare_fuel_prices or find_cheapest_fuel, so the tool-selection guidance is only implied.

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 non-destructive behavior, so the description only needs to add context beyond those. It usefully discloses the batching limits and the extra 'tightest leg' output, which are not visible in annotations or schema. It does not define what 'tightest leg' means, but the safety profile is already covered.

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 that states the core behavior first and packs the key constraints and extra output into the remainder. There is no filler, redundancy, or unnecessary detail.

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

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

With no output schema, the description's high-level return summary is valuable, but it leaves 'tightest leg' undefined and does not mention the vehicle-weight aspect hinted at by the schema. The agent can still invoke the tool correctly using the schema, but the description alone does not give a complete picture.

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 this dimension is at baseline. The description reinforces the passports limit but does not add new meaning beyond the schema, and it does not mention the optional weight parameter, which 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?

The description states that the tool returns visa rules for every country on a route in one call, accepts up to 10 passports, and adds the tightest leg. This clearly identifies the resource and distinguishes it from siblings like check_visa_rules, which appears single-check focused.

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 through 'for every country of a route in one call' and 'up to 10 passports at once', suggesting this is for multi-country and multi-passport route queries. However, it does not explicitly name when to use check_visa_rules instead, nor does it state any exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint:false, so the safety profile is covered. The description adds minor context by specifying 'details' and 'one country,' but it does not disclose significant behavioral traits beyond the annotations. No contradiction exists.

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

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

The description is a single, front-loaded sentence with no redundant or filler content. It efficiently communicates the tool's action, resource, and scope.

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

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

Given the tool's simplicity (one required parameter, strong annotations, no output schema), the description is adequate but leaves 'details' undefined. It could be more complete by hinting at what data fields are returned, especially since the title only says 'Get Food Price Index.'

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

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

The schema fully describes 'country_code' with an ISO 3166-1 alpha-2 definition, giving 100% coverage. The description only restates the single-country scope and adds no new parameter-specific meaning, so the baseline of 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?

The description uses a clear verb ('Get') and specific resource ('VanBasket food price index details') with an explicit scope ('for one country'). This effectively distinguishes it from the sibling tool 'compare_vanbasket', which likely handles multiple countries or comparisons.

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 'for one country' implies the tool is for single-country lookups, but it does not explicitly mention when to use it over alternatives like 'compare_vanbasket' or provide any exclusion criteria. Usage context is only implied, not directly stated.

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

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

The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by detailing what the score contains (e.g., solar yield, condensation risk) and that it provides a 7-day forecast, which goes 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?

The description is a single, information-dense sentence that front-loads the key output metric (0-100 score) and lists the important sub-scores and the 7-day forecast. No redundant words or restatements.

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

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

Given the tool has one required parameter, no output schema, and robust annotations, the description covers the essential aspects: what the score is, what factors are considered, and the forecast component. It is complete for an agent to decide to invoke and understand the outcome.

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

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

The input schema provides a full description for the single parameter country_code (ISO code, maxLength 2). The description reiterates 'for a country' but adds no extra meaning beyond the schema. With 100% schema coverage, a baseline of 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?

The description clearly states the tool's function: getting a VanSky weather suitability score for a country, with a specific scale (0-100) and enumerated components (van_score, sleep_score, etc.). This distinguishes it from sibling tools, none of which are weather-related.

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

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

The description provides clear context: it is for accessing a weather suitability score for vanlife in a specified country. It does not explicitly mention when not to use it or alternatives, but given no weather-related siblings exist and the tool is straightforward, this is sufficient.

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?

The description adds meaningful open-world behavior beyond the annotations: for a country with no reliable rule, the tool 'returns nothing rather than a guess.' This enriches the readOnlyHint and openWorldHint without contradicting them.

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 with no filler: the first defines the tool's scope and content, the second covers the empty-result edge case. Both sentences earn their place.

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

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

For a simple one-parameter, read-only lookup with no output schema, the description lists the returned rule categories and states the no-rule behavior. Combined with the input schema and annotations, an agent has enough context to invoke it correctly.

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

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

The schema already documents the country parameter with format examples at 100% coverage. The description only restates 'one country' and adds no new parameter-level detail, so it remains at the baseline.

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

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

The description identifies the resource precisely: temporary admission/import rules for a foreign-plated vehicle in one country, and lists the key rule categories (allowed days, per-entry/per-window, carnet, green card). This clearly distinguishes it from sibling visa, fuel, and event 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?

The domain and scope ('foreign-plated vehicle in one country') make the intended use clear and separate it from the visa-rule siblings. However, it does not explicitly name an alternative tool or say when not to use this one.

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 description doesn't need to repeat those. It adds context about event categories and filter dimensions, but does not disclose additional safety concerns or edge cases. It is consistent with annotations, so no contradiction.

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 concise sentences, front-loaded with the core purpose and followed by filter options. No wasted words, all content relevant.

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 a simple list operation with a rich schema and safety annotations. The description conveys the scope and filter options; it could mention default limit/locale or that it returns only upcoming by default, but the schema covers these. Overall it is adequate for agent selection and 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 covers 5/6 parameters with descriptions (83%). The description restates the main filter fields (status, type, country, search) but adds no new syntax or constraints beyond the schema. 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 action ('List') and resource ('vanlife events'), with concrete categories (expos, festivals, meetups, forums, road trips). This clearly distinguishes from sibling tool 'get_event' which retrieves a single event.

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

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

Implies usage via filtering options, but does not explicitly contrast with alternatives like 'get_event' for single-event retrieval or 'search_stories' for other content. No exclusions or when-not-to-use guidance is provided.

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, and non-destructive behavior. The description adds the time-sensitive 'today' aspect, which is useful, but does not disclose other behavioral traits such as rate limits or how the score is computed. No contradiction with 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?

The description is a single, front-loaded sentence that efficiently conveys the action, target, and time context with zero 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 simple one-parameter, read-only tool with no output schema, the description adequately covers purpose, input, and implied output (list of countries). A minor gap is the lack of explanation about what the suitability score is, but this is not essential for the tool's usage.

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

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

The input schema already fully documents the 'limit' parameter with a default, range, and description. The description's 'top N' aligns with the parameter but adds no new semantic detail 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 clearly states the action ('List'), the resource ('top N countries'), and the criterion ('highest VanSky van-travel suitability score today'). This distinguishes the tool from siblings focused on fuel prices, weather, or 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 description gives context ('today') but does not explicitly mention when to use this tool versus alternatives like get_vansky_weather or compare_fuel_prices. Usage is implied rather than explicitly guided.

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 readOnly and idempotent hints, so the description adds useful context about the aggregated nature and language coverage. It does not elaborate on result ordering or pagination, but the schema provides limit constraints. The added source count and language range provide meaningful behavioral context beyond the annotation.

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

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

A single, front-loaded sentence conveys the verb, resource, and key attributes. Every word adds value; there is no fluff or repetition.

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

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

For a simple search tool with no output schema, the description is fairly complete. It communicates the data scope (languages, sources) and filter options. It does not specify what happens with no search query or how results are sorted, but these are not critical given the tool's simplicity and the schema's defaults.

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

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

The description lists four filter fields (query, category, country, locale) but adds little beyond the schema's own descriptions. Since schema coverage is 60% and the remaining params (limit, locale) have self-describing enums/defaults, the description's redundancy does not substantially deepen understanding. It omits mention of the limit parameter, but the schema covers it well.

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 tool's action ('Search') and resource ('aggregated vanlife news stories'), with specific scope ('7 languages, 400+ sources'). This unambiguously distinguishes it from sibling tools like get_fuel_prices or list_events, which target different domains.

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

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

The description implies the use case: finding vanlife news by various filters. While it does not explicitly mention when not to use it or name alternatives, the context of sibling tools makes it clear this is the news-search tool. The lack of exclusions is acceptable given its focused scope.

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