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

With no annotations provided, the description carries the full burden of behavioral disclosure but only specifies input format expectations (2-char vs 3-char). It fails to mention error handling (e.g., invalid codes), data freshness, or what constitutes a successful match.

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?

Perfectly concise at 9 words. Every element earns its place: the verb 'Look up', the resource 'airline', and the critical format specifications '(2-char)' and '(3-char)'. No waste, front-loaded action.

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?

Adequate for a single-parameter lookup tool with an output schema (which handles return value documentation). However, with zero schema coverage and no annotations, the description should ideally address validation behavior or error states for invalid codes.

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?

Excellent compensation for 0% schema description coverage. The description crucially clarifies that the 'code' parameter accepts either IATA (2-character) or ICAO (3-character) formats, providing essential semantic meaning entirely absent from 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 ('Look up') and resource ('airline') with specific identifier types (IATA/ICAO codes). It implicitly distinguishes from sibling 'airlines_search' by specifying code-based lookup versus likely text-based search, though it doesn't explicitly name the alternative.

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 usage context (when you have an IATA or ICAO code) but provides no explicit when-to-use guidance, no exclusions, and doesn't mention the sibling 'airlines_search' as an alternative for name-based searches.

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

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

With no annotations provided, the description carries the full burden. It discloses the 20-result limit ('Returns up to 20 results'), which is valuable behavioral context not found in structured fields. However, it lacks details on matching behavior (exact vs. fuzzy), rate limits, or authentication requirements.

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 optimally concise with two sentences: the first establishes the operation, the second states the result limit. No redundancy or filler text is present; every word serves a purpose.

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?

Despite the presence of an output schema (reducing the need for return value documentation), the description is incomplete due to zero schema coverage on three input parameters. It fails to document the majority of the tool's inputs, creating significant gaps for an agent attempting to construct valid calls.

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

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

Schema description coverage is 0%, requiring the description to compensate. While 'by name' implies the 'query' parameter's purpose, the description completely omits explanation of 'country' (filtering scope) and 'active_only' (status filtering), leaving two of three parameters undocumented.

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 verb (Search), resource (airlines), and method (by name). However, it does not explicitly differentiate from the sibling tool 'airlines_lookup', leaving ambiguity about when to use search versus lookup.

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?

No guidance is provided on when to use this tool versus alternatives like 'airlines_lookup', nor are prerequisites or exclusion criteria mentioned. The agent must infer usage context solely from the tool name.

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

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

With no annotations provided, the description carries the full burden. It discloses return value characteristics ('full details including runways'), indicating rich data retrieval. However, it omits mention of error behavior for invalid codes, rate limits, or authentication requirements.

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. First sentence covers purpose and input semantics; second covers output characteristics. Information density is optimal with 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?

Appropriate for a single-parameter lookup tool where an output schema exists. The description adds value by highlighting runway data in the returns, suggesting comprehensive airport records. Could be improved by noting error states for invalid codes.

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 has 0% description coverage for the 'code' parameter. The description effectively compensates by specifying expected formats (IATA 3-char, ICAO 4-char) and validation types, though it doesn't explicitly map these constraints to the parameter name.

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?

Clearly states the tool looks up airports by specific code types (IATA/ICAO). Distinguishes from airline-related siblings implicitly by specifying 'airport' and from 'airports_search' via the code-based lookup mechanism, though it doesn't explicitly name sibling 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?

Provides excellent input format guidance (3-char IATA vs 4-char ICAO) within the description. However, lacks explicit guidance on when to use this versus 'airports_search' or 'airports_near' for different lookup scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully notes that results are 'sorted by distance,' which is valuable behavioral context, but fails to mention other critical traits like whether small airports are excluded by default, rate limits, or the read-only nature of the operation.

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 extremely concise with two efficient sentences and zero redundancy. However, given the lack of schema descriptions and annotations, this brevity results in underspecification rather than clarity, preventing a perfect score.

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 tool with five parameters and zero schema descriptions, the description is insufficiently complete. It fails to explain the boolean 'include_small' parameter, default values for radius_km and limit, or the output format (despite an output schema existing that could have been referenced descriptively).

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?

Given 0% schema description coverage, the description inadequately compensates for undocumented parameters. While 'geographic point' implies the purpose of latitude and longitude, and 'distance' hints at radius_km, it completely omits semantics for 'include_small' (what defines 'small'?) and 'limit' (max results?), leaving three of five parameters effectively undocumented.

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 'Find[s] airports near a geographic point' with a specific verb and resource, and the phrase 'near a geographic point' effectively distinguishes it from sibling tools like airports_lookup and airports_search. However, it misses a perfect score by not explicitly contrasting with these siblings.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like airports_search or airports_lookup. While 'geographic point' implies coordinate-based usage, there is no 'when to use/when not to use' instruction or mention of prerequisites like requiring latitude/longitude values.

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

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

No annotations are provided, so the description carries the full burden. It successfully discloses the result limit ('up to 20 results') and sorting behavior ('sorted by size'), but lacks information on error handling, empty result behavior, or rate limiting.

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 zero waste. The first sentence establishes the core purpose and the second provides critical behavioral constraints (pagination/sorting). Perfectly front-loaded and appropriately sized.

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?

Adequate for a search tool with an output schema (which handles return value documentation), but incomplete regarding input parameters. Given the zero schema coverage, the description should have mentioned the filtering capabilities of 'country' and 'type_filter' parameters.

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 0% schema description coverage, the description must compensate for all three parameters. It only implicitly covers 'query' via 'name or city', leaving 'country' and 'type_filter' completely undocumented with no hints about expected formats or valid values.

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?

Clearly states the verb (search), resource (airports), and method (by name or city). The 'name or city' qualifier effectively distinguishes this from sibling 'airports_lookup' which likely expects exact codes/identifiers.

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?

No explicit guidance on when to use this versus 'airports_lookup' or 'airports_near'. While the distinction is implied by the search method described, the agent must infer when to prefer search over lookup.

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

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

No annotations provided, so description carries full burden. It discloses behavioral traits by specifying the tool returns 'row counts' and checks 'loaded' status. However, it lacks safety profile disclosure (read-only nature, performance characteristics, or auth requirements) that would be necessary given the absence of 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?

Single sentence, front-loaded with action verb 'Check'. Zero redundant words. Specific parenthetical enumeration of datasets adds precision without verbosity. 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?

For a zero-parameter diagnostic tool with an output schema present, the description is complete. It specifies exactly which datasets are inspected (aligning with sibling tool domains) and what metrics are returned (row counts), making it sufficient for agent selection.

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?

Input schema has 0 parameters. Per rubric, 0 params = baseline 4. Description appropriately makes no mention of parameters since none exist.

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?

Excellent clarity. Uses specific verb 'Check' with explicit resource 'static datasets' and enumerates the exact datasets monitored (airports, airlines, visas). Clearly distinguishes this meta/diagnostic tool from operational siblings like airlines_lookup or visa_check.

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?

No explicit when-to-use or when-not-to-use guidance provided. However, the diagnostic nature (checking loaded status and row counts) implies usage for data health verification before querying, but lacks explicit guidance like 'use before querying datasets to verify availability'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description omits safety details (e.g., idempotency), rate limits, or data freshness. The scope 'all countries' is stated, but pagination behavior or response size expectations are not addressed.

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 consists of a single, efficient sentence with no redundant information. The '[fcdo]' prefix serves as a namespace identifier without cluttering the semantic content, and every word directly contributes to understanding the tool's 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 that an output schema exists (covering return values) and the input schema is empty, the description adequately covers the tool's purpose for its low complexity. However, lacking annotations, it could have benefited from a brief note confirming this is a safe, non-destructive read 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?

The input schema contains zero parameters, establishing a baseline score of 4. The description appropriately requires no parameter explanation, as the tool is a simple, unfiltered list operation.

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 verb ('List') and resource ('countries with UK FCDO travel advice'), making the tool's function immediately apparent. However, it does not explicitly differentiate from its sibling 'fcdo_travel_advice' (which presumably retrieves detailed advice for specific countries), leaving the relationship between the tools implied rather than stated.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention the sibling 'fcdo_travel_advice' as a follow-up for retrieving specific country details. There are no stated prerequisites or exclusion criteria.

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

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

With no annotations provided, the description carries full burden. It successfully discloses content categories covered (safety, entry requirements, health, warnings), giving agents insight into return data structure. However, it lacks operational details like read-only nature, update frequency of FCDO data, or whether the advice is official/legal guidance.

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 efficient sentences with zero waste. Front-loaded with the core action '[fcdo] Get UK FCDO travel advice', followed immediately by value-add content categories. Every word earns its place.

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

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

Appropriate for a single-parameter lookup tool with an output schema (which handles return value documentation). Covers the domain (FCDO), scope (country-specific), and content types. Only gap is parameter format specification, which is noted in parameter semantics.

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

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

Schema coverage is 0% with no parameter descriptions. The description mentions 'for a specific country' but fails to specify expected format (ISO 3166-1 alpha-2 code, full country name, etc.) or case sensitivity. With zero schema coverage, the description must compensate for this gap but doesn't.

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?

Clear verb-resource pair ('Get UK FCDO travel advice') and distinguishes from sibling fcdo_list_countries by targeting a specific country. However, it doesn't explicitly clarify this advice is specifically intended for UK citizens/travelers, which would strengthen differentiation from general country info tools like restcountries_country_info.

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?

No explicit when-to-use guidance or alternative suggestions. The description mentions 'entry requirements' which overlaps functionally with visa_check and visa_summary siblings, but provides no guidance on choosing between them. No mention of prerequisite steps (e.g., using fcdo_list_countries to validate country availability).

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

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers almost none. It does not clarify what constitutes a 'direct connection' (routes? lines? schedules?), whether the operation is read-only, or what the return structure contains.

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 efficient sentence. The '[ferryhopper]' prefix adds noise but minimal overhead. It is appropriately front-loaded with the action verb.

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

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

For a single-parameter lookup tool with complete schema coverage and no output schema, the description is minimally adequate. However, it lacks domain context explaining that 'connections' represent reachable destination ports from the queried location.

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 has 100% description coverage for its single parameter ('portLocation'), establishing a baseline of 3. The description adds no parameter-specific context, but given the schema completeness, no compensation is required.

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 retrieves 'direct connections between ports' with a specific verb ('Get') and resource. However, it fails to distinguish from sibling tool 'ferryhopper_search_trips'—leaving ambiguity about whether this returns route metadata versus searchable trip options.

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?

No guidance is provided on when to use this tool versus 'ferryhopper_search_trips' or 'ferryhopper_get_ports'. There is no mention of prerequisites (e.g., whether the port must exist) or when to prefer direct connections over trip searches.

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

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

No annotations are provided, so the description carries full disclosure burden. It mentions 'global' scope (useful) but fails to clarify pagination behavior, rate limits, what specific 'details' are returned, or whether the data is cached. For a data-retrieval tool with no output schema, this lacks necessary behavioral 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?

The description is efficiently structured with the namespace prefix followed by the action. It is appropriately brief for a simple catalog tool, though the extreme brevity leaves room for additional context about output format without becoming verbose.

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 lack of output schema and annotations, the description should compensate by explaining what port 'details' include (IDs, names, locations) and noting this is a prerequisite for other ferryhopper tools. It meets minimum viability but leaves significant gaps for an integration 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?

With zero parameters, the baseline score applies. The description appropriately indicates this is a parameterless list operation requiring no filters, which aligns with the empty input schema. No additional parameter guidance is needed or possible.

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 verb ('Get') and resource ('list of global ports and their details'), distinguishing it from sibling ferryhopper tools like 'ferryhopper_search_trips' and 'ferryhopper_get_direct_connections_for_ports' by being the catalog/listing operation. The '[ferryhopper]' prefix helps namespace it among airline/airport siblings.

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

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

While the description implies this is a lookup tool (necessary for obtaining port identifiers to use with 'ferryhopper_search_trips'), it lacks explicit guidance on when to call this versus the connection-specific tool or how it relates to the trip search workflow. Usage must be inferred from sibling tool names.

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

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

No annotations are provided, so the description carries full disclosure burden. While 'Get a list' implies a read-only search operation, the description fails to specify what data is returned (prices, schedules, operators, availability), whether pagination is supported, or any rate limiting concerns.

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

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

Single sentence, appropriately front-loaded with the action verb 'Get'. Minor grammatical error ('list available' instead of 'list of available') prevents a perfect score, but overall efficient with minimal 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?

Given three simple parameters with complete schema coverage and no nested objects, the input requirements are adequately addressed. However, lacking both annotations and an output schema, the description should ideally characterize the return structure (e.g., trip options with times/prices) to be fully complete.

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

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

Schema coverage is 100% with detailed descriptions for each parameter (ISO date format, human-readable location names). The description mentions 'between two ports' and 'specific date' which reinforces the schema semantics but adds no additional guidance on parameter interactions or validation rules 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 tool retrieves ferry trips (specific resource) between two ports on a specific date, distinguishing it from flight search siblings (kiwi_search-flight, skiplagged_sk_flights_search) and other ferryhopper tools like get_ports or get_direct_connections_for_ports. The '[ferryhopper]' prefix aids identification but slightly dilutes the sentence structure.

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?

No explicit guidance on when to use this versus alternatives. It does not clarify when to use this date-specific search versus 'ferryhopper_get_direct_connections_for_ports' (which finds general routes without dates) or whether users should validate ports first using 'ferryhopper_get_ports'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to explain what happens to the feedback after submission (e.g., creates a ticket, sends email, stored in database), whether the operation is idempotent, or if there are rate limits. The description only states the intent, not the mechanism or side effects.

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 appropriately brief at one sentence. However, the '[kiwi]' prefix at the beginning appears to be categorization metadata leaking into the description field rather than essential descriptive content, slightly reducing the structural quality.

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 (single string parameter, no output schema), the description is minimally adequate. However, for a feedback submission tool with no annotations, it should ideally disclose what confirmation or response the user can expect, or whether the feedback is anonymous.

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 100% schema description coverage, the input parameter 'text' is fully documented in the schema itself, including guidance on including logs and error messages. The tool description does not mention parameters, which is acceptable given the schema completeness. Baseline score 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 (send feedback) and target (dev of the Kiwi MCP server), effectively distinguishing it from the numerous travel-related sibling tools (airlines, hotels, tours, etc.). However, the '[kiwi]' prefix appears to be metadata leakage rather than descriptive content, and it doesn't specify what types of feedback are appropriate (bugs vs. feature requests).

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 no guidance on when to use this tool versus alternatives, or under what circumstances (e.g., encountering bugs, errors, or feature requests). While there are no direct sibling alternatives for feedback submission, the description fails to indicate appropriate triggers for invocation.

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

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

No annotations provided, so description carries full burden. It discloses that the tool performs location resolution ('Search for matching locations to resolve airport codes') and searches date ranges. However, it omits safety profile (read-only vs destructive), rate limits, error behaviors, or authentication requirements.

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?

Severely bloated with extensive output formatting instructions (markdown table specifications, column ordering, fun facts) that belong in system prompts rather than tool descriptions. While front-loaded with purpose, the majority of text distracts from tool selection and invocation logic.

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?

Despite lacking an output schema, the description comprehensively documents the return data structure through detailed display instructions (mentioning fields like durationInSeconds, totalDurationInSeconds, deep links). Missing only error handling and edge case behaviors for full completeness.

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%, establishing a baseline of 3. The description mentions accepting city names or airport codes, but this merely restates the schema descriptions for flyFrom/flyTo ('It could be a city or an airport name or code'), adding no new semantic value.

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?

Clearly states the tool 'searches for available flights between two locations' using the Kiwi API. However, it does not distinguish from sibling flight search tools like 'skiplagged_sk_flights_search', leaving ambiguity about which flight provider to use.

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

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

Provides explicit when-to-use guidance: 'Call this tool whenever a user wants to search for flights, regardless of whether they provided exact airport codes or just city names.' Lacks exclusions or explicit comparison to alternative flight search siblings.

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

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

No annotations provided, so description carries full burden. Discloses critical functional constraints (round-trip only, multi-source searching) and prerequisites. Lacks explicit safety classification (read-only status) or rate limit disclosure, though 'search' implies low risk.

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 clearly demarcated sections ([navifare] purpose, IMPORTANT workflow, LIMITATIONS). No filler text. Imperative instructions are direct and actionable. Front-loaded with purpose before constraints.

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 complex nested input schema and no output schema, description adequately covers critical usage patterns, prerequisite chain, and functional limitations. Does not describe return value format, though tool name implies price comparison results.

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 has 100% description coverage, establishing baseline 3. Description adds workflow context mentioning 'flightData' returned from prerequisite tool, helping explain the complex nested trip structure, but does not elaborate individual parameter semantics beyond 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?

Opens with specific verb 'Search' and clear resource 'multiple booking sources to find better prices for a specific flight'. Distinguishes from general flight search siblings (like kiwi_search-flight) by emphasizing price comparison for a specific already-identified flight.

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

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

Provides explicit prerequisite workflow: 'MUST call format_flight_pricecheck_request FIRST' and 'Do NOT call this tool directly'. Clear exclusions stated: 'Only round-trip flights are supported' with explicit mention that one-way and open-jaw are NOT supported.

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

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

No annotations provided, so description carries full burden. It discloses critical limitations explicitly (round-trip only, one-way/open-jaw NOT supported) and describes return behavior (formatted data OR request for missing info). However, lacks mention of whether this is a safe read-only operation or has side effects.

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?

Excellent structure with [navifare] prefix, clear function statement, specific extraction details, return behavior, and explicit LIMITATIONS section. Every sentence serves a purpose; no filler. Front-loaded with primary action (parse/format) before 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?

Despite missing output schema and annotations, description compensates by explaining return values (formatted data or missing info request) and operational constraints. For a single-parameter parsing tool, coverage is adequate, though output schema would clarify the 'formatted flight data' structure 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?

Input schema has 100% description coverage with detailed example, establishing baseline 3. Description adds minor semantic context by emphasizing 'transcribed image content' capability alongside natural language, implying OCR/extraction use cases beyond simple text input. No additional parameter constraints or formats specified beyond 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?

Description clearly states the tool parses and formats flight details from natural language or transcribed image content, extracting specific fields (airlines, flight numbers, dates, airports, prices). It explicitly distinguishes itself from the sibling 'flight_pricecheck' tool by stating it returns data 'ready for flight_pricecheck', establishing the workflow relationship.

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

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

Provides clear context for when to use (parsing unstructured text/image content vs structured search) and explicitly names the downstream sibling tool ('flight_pricecheck') that consumes its output. Mentions it requests missing information when incomplete. Could be strengthened by contrasting with general flight search tools like kiwi_search-flight.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it lists what data is returned (dates, times, pricing), it fails to indicate if this is a safe read-only operation, whether it requires specific permissions, rate limits, or error handling behavior (e.g., what happens if the ID is invalid).

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, efficient sentence with no redundant words. The '[peek]' prefix appears to be a provider tag, and the remainder immediately conveys the action and return value without 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?

Given the lack of output schema, the description partially compensates by listing the types of data returned (dates, times, pricing), but does not describe the response structure or format. With complete input schema coverage but no annotations, the description meets minimum viability but lacks operational context.

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

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

With 100% schema description coverage, the schema fully documents all four parameters (id, quantity, startDate, endDate). The description implies the 'id' and date parameters by referencing 'specific experience' and 'dates', but adds no syntax or semantic details beyond the schema, warranting the baseline score of 3.

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

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

The description clearly states the tool 'Get[s] availability information for a specific experience' with specific outputs (dates, times, pricing). However, it does not explicitly differentiate from sibling 'peek_experience_details', which likely retrieves general metadata rather than availability.

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 no guidance on when to use this tool versus alternatives like 'peek_experience_details' or 'peek_search_experiences'. It does not mention prerequisites (e.g., needing an experience ID from search results) or exclusion criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but offers almost none. It does not confirm the operation is read-only (though 'Get' implies it), describe rate limits, caching behavior, or—critically—what 'detailed information' includes (description, photos, pricing, location) given the absence of an 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?

The description is appropriately brief and front-loaded with the verb. The '[peek]' prefix appears to be metadata or branding leakage that adds no semantic value, but the single sentence efficiently conveys the core operation without 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?

For a single-parameter lookup tool, the description is minimally viable. However, given the lack of an output schema and the domain-specific term 'experience' (referring to Peek's tour/activity inventory), the description should ideally sketch what details are returned to help the agent assess utility.

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%, establishing a baseline of 3. The description mentions 'by ID', reinforcing the parameter's purpose, but adds no further semantics regarding ID format, where to obtain valid IDs, or validation rules beyond what the schema already states.

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 'Get[s] detailed information about a specific experience by ID', providing a specific verb, resource, and scope (by ID). It implicitly distinguishes from sibling 'peek_search_experiences' (search vs. lookup by ID), though it could more explicitly differentiate from 'peek_experience_availability'.

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 no guidance on when to use this tool versus alternatives like 'peek_search_experiences' (which should be used first to obtain an ID) or 'peek_experience_availability' (for scheduling data). There are no prerequisites or workflow hints.

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

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

No annotations are provided, yet the description fails to disclose behavioral traits such as whether results are cached, pagination limits, rate limiting, or what data structure is returned (strings vs objects). For a zero-parameter tool, this metadata is essential since the schema conveys no information.

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 appropriately brief for a simple list operation. However, the '[peek]' prefix is semantically wasteful—it appears to be metadata or branding that belongs in the title field (which is null) rather than the functional description.

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?

While the tool is simple (no input params), the lack of output schema means the description should indicate the return format (e.g., array of tag names/IDs). Given no annotations and no output schema, the description is adequate but minimal—missing context on what constitutes a 'category tag' in this domain.

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?

Input schema has zero parameters. According to evaluation rules, zero parameters establishes a baseline score of 4. The description doesn't need to compensate for missing schema documentation since there are no parameters to document.

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 ('List') and resource ('category tags'), and the tool name 'peek_list_tags' combined with sibling tools (peek_search_experiences, etc.) clarifies this relates to Peek activity categories. However, it doesn't explicitly state these are experience/activity category tags versus other taxonomies.

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?

No guidance provided on when to use this versus the other peek_* tools like peek_search_experiences. Doesn't indicate if this is a prerequisite step for category discovery before searching, or merely a reference utility.

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

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

With no annotations provided, the description carries the full burden and successfully discloses the critical behavioral trait that it returns a URI/reference (embeddable widget) rather than raw activity data or rendered HTML. However, it omits cache behavior, auth requirements, or error handling for invalid IDs.

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

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

Single sentence, front-loaded with the action verb. Every clause adds value. Minor deduction for the '[peek]' prefix which serves as branding/context but slightly disrupts the flow without adding functional meaning.

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 lack of output schema, the description appropriately compensates by specifying the return value type ('embeddable widget URI'). For a single-parameter tool with high schema coverage, the description provides sufficient context for 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 coverage is 100%, so the baseline is met. The description reinforces that the IDs represent 'activity tiles' but does not add syntax details (like comma-separation) beyond what the schema already provides. It confirms the logical input is a list.

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 ('Render') with clear resource ('activity tiles') and explicitly distinguishes from sibling peek tools by stating the unique output format ('embeddable widget URI'). The '[peek]' prefix also signals the platform context.

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?

While the description implies this is for embedding/visual display purposes via 'embeddable widget URI', it lacks explicit when-to-use guidance contrasting it with siblings like peek_experience_details or peek_search_experiences. No alternatives or exclusions are named.

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

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

No annotations are provided, so the description carries the full burden. It partially compensates by disclosing what the return payload contains ('categories, tags, and regions with IDs'), which is valuable given the lack of an output schema. However, it fails to disclose safety characteristics (read-only vs. destructive), rate limits, or pagination behavior expected for a search tool with 7 optional parameters.

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 appropriately brief at two sentences. The critical information (search action and return structure) is front-loaded, though the '[peek]' vendor prefix in the first sentence is structural noise that doesn't aid the LLM. No redundant or wasted sentences beyond that prefix.

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 7 parameters with 100% schema coverage, the description doesn't need to elaborate on inputs. With no output schema, it adequately compensates by describing the return values (categories, tags, regions with IDs). However, for a complex search tool with no annotations, it should disclose the read-only/safe nature of the operation and any pagination logic, which are absent.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description references 'comprehensive filtering options,' which collectively acknowledges the parameter purpose, but adds no specific semantic detail about individual parameters (e.g., date formats, coordinate precision) 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 core action ('Search for travel experiences') and resource type. The '[peek]' prefix is noise, but the first sentence establishes the verb and object clearly. It partially distinguishes from siblings like peek_search_regions by noting it returns IDs for 'further filtering,' implying this is a discovery tool, though it could more explicitly contrast with peek_experience_details.

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 further filtering' implies this is an initial discovery step before using other tools (like peek_experience_details), providing implicit workflow guidance. However, it lacks explicit 'when to use' guidance, prerequisites, or named alternatives. It does not clarify why one should use this versus peek_list_tags or peek_search_regions directly.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to indicate whether results are paginated, what fields are returned (IDs, coordinates, names?), rate limits, or authentication requirements. The '[peek]' tag hints at the service provider but provides no operational 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?

Extremely concise at six words with no filler. However, given the lack of annotations and output schema, this brevity may constitute under-specification rather than efficient communication. The '[peek]' prefix at the start is useful categorization.

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?

Inadequate for a search tool with no output schema. The description should explain what data is returned (region IDs needed for downstream 'peek_experience_*' calls?) and how results relate to the broader Peek tool ecosystem. Without annotations or output schema, the description must compensate more.

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 100% schema description coverage, the schema adequately documents both parameters. The description adds minimal semantic value beyond the schema, merely restating that the tool searches by name. Baseline score applies since schema descriptions are complete.

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 verb (search) and resource (regions) with the '[peek]' prefix distinguishing it from non-Peek siblings. However, it lacks specificity about what constitutes a 'region' in the Peek context (e.g., geographic areas vs. administrative boundaries) which would help differentiate it from 'peek_search_experiences'.

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?

No guidance provided on when to use this tool versus alternatives like 'peek_search_experiences' or 'airports_search'. Given the sibling ecosystem, explicit guidance on whether regions are prerequisites for experience searches would be valuable.

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

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

No annotations are provided, so the description carries full burden. It mentions the external API (REST Countries) but discloses no behavioral traits such as rate limits, caching behavior, what happens when a country is not found, or what specific data fields are returned (though an output schema exists).

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

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

The single sentence is appropriately concise and front-loaded with the essential purpose. However, given the complete lack of parameter documentation in the schema, the description is inappropriately brief—conciseness becomes under-specification when critical usage details are omitted.

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?

Inadequate for the tool's complexity. With 3 parameters, 0% schema coverage, no annotations, and a non-obvious query syntax (REST Countries API supports multiple search modes), the description should explain parameters and search behavior. It provides only the minimal purpose statement.

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 0% schema description coverage, the description completely fails to compensate. It does not explain the required 'query' parameter (expected format: full name, ISO code?), the 'fields' parameter (filtering syntax?), or valid values for 'search_by' (only 'name' or others?). This is a critical gap for tool invocation.

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

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

States the basic action (look up) and resource (country information) and identifies the data source (REST Countries), which provides some specificity. However, it fails to distinguish what type of country information this provides (demographics, geography, flags) versus sibling tools like fcdo_travel_advice or tourradar country lists.

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

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

Provides no guidance on when to use this tool versus alternatives like fcdo_list_countries for travel advice or tourradar for tour destinations. No mention of prerequisites, search syntax requirements, or exclusion criteria.

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

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

With no annotations provided, the description carries the full burden. It partially compensates by disclosing return values ('prices, companies, and car details') since no output schema exists, but fails to mention behavioral traits like pagination behavior, caching, rate limits, or error conditions.

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, efficient sentence that front-loads the provider identifier [skiplagged] and immediately states the core function. Zero wasted words or redundant phrases.

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 9 parameters with complete schema coverage and no output schema, the description adequately compensates by describing the expected return data structure. It appropriately focuses on the search contract, though it could mention the pagination support (limit/offset) 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 description coverage is 100%, so parameters are well-documented in the schema itself. The description acknowledges the key parameter groups (locations/dates) but does not add semantic relationships (e.g., that dropoffLocation defaults to pickup) or usage constraints beyond the schema definitions.

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 (Search), resource (rental cars), and scope (between pickup/dropoff locations/dates). It distinguishes itself from sibling tools like skiplagged_sk_flights_search and skiplagged_sk_hotels_search by explicitly specifying 'rental cars' and the Skiplagged provider prefix.

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?

While the description implies usage through the car rental domain specification, it lacks explicit guidance on when to use this versus other transportation options (flights, ferries) or prerequisites like requiring valid dates. No alternative tools or exclusion criteria are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it fails to explain what data is returned (destination list format, price inclusion), rate limits, caching behavior, or the significance of the 'skiplagged' provider (hidden-city ticketing implications).

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 two-sentence structure is appropriately front-loaded with the core function. The '[skiplagged]' prefix is slightly noisy but acceptable for provider identification in a multi-tool environment. No significant waste, though it could be more information-dense given the complexity.

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 search tool with 9 parameters and no output schema or annotations, the description is inadequate. It fails to describe the return structure (what does 'destinations' mean—airports, cities, prices?), pagination, or how results are sorted/ranked.

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 100% schema description coverage, the baseline is 3. The description adds minimal value beyond the schema by implying the flexible-destination nature (explaining the absence of a 'to' parameter), but doesn't elaborate on date formats, passenger combinations, or the renderMode parameter's practical impact.

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 (find cheapest destinations), the resource (destinations from a departure city), and the distinctive scope (when flexible about where to go). This effectively differentiates it from sibling tools like skiplagged_sk_flights_search which likely require a specific destination.

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 flexible about where to go'), but lacks explicit guidance on when NOT to use it or named alternatives. It doesn't direct users to skiplagged_sk_flights_search for specific routes, leaving the distinction implied rather than 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?

No annotations provided, so description carries full burden. States 'Search' implying read-only, but fails to disclose return format (critical given no output_schema), rate limits, or authentication requirements. Minimal behavioral disclosure beyond operation type.

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 the [skiplagged] prefix aids namespacing. However, includes vague filler ('stuff') that wastes tokens without adding meaning. Reasonably compact but not maximally 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?

Adequate for a simple 3-parameter search tool: identifies the knowledge base (FAQ) and use case. However, lacks description of return values (articles, snippets, URLs?) which is notable given the absence of an output schema.

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

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

Schema description coverage is 100% (query, top_k, renderMode all documented). Description mentions 'search query' implicitly but adds no syntax details, examples, or semantic clarifications beyond what the schema already provides. Baseline 3 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?

Clear verb ('Search') and resource ('FAQ') with specific scope ('about Skiplagged - company... products, and policies'). Effectively distinguishes from flight/hotel booking siblings (skiplagged_sk_flights_search, skiplagged_sk_hotels_search). Minor deduction for vague filler word 'stuff'.

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 identifies context ('Useful for customer support and general inquiries'), providing clear when-to-use guidance. Lacks explicit when-not-to-use or named alternatives, but use-case context is specific enough for 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?

No annotations provided, so description carries full burden. Discloses return format ('date → cheapest-price entries') and scope limitation, but lacks details on search radius (how many days 'around'?), rate limits, caching behavior, or currency/tax inclusion that would help an agent understand operational constraints.

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. Front-loaded with vendor prefix. First sentence establishes function and output format; second sentence clarifies intent and boundaries. Every word earns its place.

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

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

Given rich schema (100% coverage) and conceptual explanation of return values ('date → cheapest-price entries'), the description adequately covers the tool's purpose. Minor gap: doesn't specify the temporal range of the 'around' search or output formatting 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?

With 100% schema coverage, baseline is 3. Description adds value by contextualizing departureDate as 'chosen departure' (center of flexible range) rather than exact flight date, and implying one-way focus that clarifies the optional nature of returnDate in 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?

Specific verb ('Generate') and resource ('flexible calendar') clearly stated. Distinguishes from siblings by specifying 'one-way fares' vs return calendar, and explicitly contrasting with 'exact itinerary selection' to differentiate from skiplagged_sk_flights_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?

Provides explicit when-to-use guidance ('flexible-date price discovery') and when-not-to-use ('not exact itinerary selection'). Would be perfect if it named the specific alternative tool (skiplagged_sk_flights_search) rather than just the category.

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

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

With no annotations provided, the description must carry the full burden. It successfully discloses the return structure (depart date, return date, price tuples) and the core logic (preserving trip length while varying dates). However, it lacks operational details such as search radius ('nearby' is undefined), rate limits, 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?

Two dense sentences with zero waste. First sentence establishes the function and constraints; second sentence describes the return format and intended use. Every clause provides essential information for tool selection.

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 lack of output schema, the description adequately compensates by detailing the return tuple structure. With 100% schema coverage and clear explanation of the flex algorithm, it covers the essential domain context. Minor gap: does not specify the temporal range of 'nearby' dates.

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?

While the schema has 100% description coverage (baseline 3), the description adds valuable semantic context about the relationship between departureDate and returnDate—that they define a fixed duration that is maintained across alternative date pairs. This explains the 'flex' logic beyond what the schema fields convey individually.

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 specific verbs ('Generate') and clearly identifies the resource ('flexible round-trip price calendar'). It distinguishes itself from sibling tools by emphasizing 'fixed-length stay' and preserving 'original trip length,' implying the difference from skiplagged_sk_flex_departure_calendar and exact search 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?

Explicitly states the intended use case ('price discovery') and the non-intended use ('not exact itinerary selection'), providing clear behavioral guidance. However, it does not explicitly name which sibling tool (e.g., skiplagged_sk_flights_search) to use for actual itinerary 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?

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to indicate whether this tool performs booking or just search, what the return format is (critical given no output schema exists), rate limits, or that Skiplagged specializes in hidden-city ticketing (despite the includeHiddenCity parameter). It only mentions 'filtering options' without explaining side effects or safety profiles.

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 efficient sentence that front-loads the core action. The bracketed '[skiplagged]' prefix is slightly redundant given the tool name, but the structure is otherwise tight with no wasted words. Every element contributes to understanding the tool's 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 high schema coverage, the description appropriately delegates parameter details to the schema. However, for a complex 27-parameter tool with no output schema and no annotations, the description lacks critical context about return values, pagination behavior (despite offset/limit parameters), or the unique 'hidden city' nature of Skiplagged results. It meets minimum viability but leaves significant gaps.

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 93% schema description coverage, the input schema already comprehensively documents the 27 parameters. The description provides a high-level categorization ('filtering options for passengers, fare class...') but adds no syntax details, format examples, or semantic clarifications beyond what the schema already provides, warranting the baseline score for high-coverage schemas.

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 verb (Search), the specific service (Skiplagged), and the resource (flights). The phrase 'between specific locations' effectively distinguishes it from the sibling tool 'skiplagged_sk_destinations_anywhere' (flexible destinations), though it doesn't explicitly differentiate from other flight search providers like kiwi_search-flight.

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 lists available filter categories (passengers, fare class, etc.) but provides no explicit guidance on when to use this tool versus alternatives such as the sibling calendar tools (skiplagged_sk_flex_departure_calendar) or the 'anywhere' destination search. No prerequisites or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden. It discloses data granularity ('room-level') and return data types, but omits operational details like rate limits, caching behavior, or failure modes that would help the agent predict tool 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?

Single sentence with zero waste. Every phrase earns its place: '[skiplagged]' identifies provider, 'room-level' specifies granularity, and 'specific hotel' clarifies scope. Front-loaded and appropriately sized.

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

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

No output schema exists, but the description compensates by listing return data categories (availability, pricing, amenities). With 100% input schema coverage, the description provides adequate context for an 8-parameter tool, though behavioral caveats would strengthen it further.

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 parameters are fully self-documenting. The description references key concepts (stay dates, specific hotel) that map to parameters but adds no technical syntax, validation rules, or semantic relationships 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?

Uses specific verb 'Fetch' with clear resource scope ('room-level availability, pricing, and amenities'). The phrase 'specific hotel' effectively distinguishes this from sibling search tools like 'skiplagged_sk_hotels_search' by implying a prior selection step.

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

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

Provides implied usage context through 'specific hotel' (suggesting a hotel ID from prior search is required), but lacks explicit workflow guidance, alternatives naming, or prerequisites compared to sibling tools.

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

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

With no annotations provided, the description carries the full burden. It discloses that results include 'ratings and pricing' (useful return value context) and indicates the external Skiplagged dependency. However, it omits pagination behavior, rate limits, caching policies, or real-time vs. cached data characteristics.

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

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

The description is a single, efficient sentence with zero waste. It front-loads the action verb ('Search'), identifies the resource ('hotels'), and specifies key constraints ('city', 'dates') immediately. The '[skiplagged]' prefix provides clear namespacing without clutter.

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 10 parameters, no output schema, and no annotations, the description meets minimum viability by stating core functionality and return data types (ratings/pricing). However, it should mention pagination capabilities (offset/limit) or sorting options to fully contextualize the search behavior for an agent.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'city' and 'check-in and check-out dates' aligning with required parameters, but adds no semantic clarity for advanced parameters like 'sort' (price/ranking/value/discount) or 'renderMode' 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 tool searches for hotels on Skiplagged by city with check-in/out dates, distinguishing it from sibling flight/car search tools. However, it doesn't explicitly differentiate from 'skiplagged_sk_hotel_details' (list vs. specific hotel lookup), which would strengthen selection clarity.

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 no guidance on when to use this tool versus alternatives like 'skiplagged_sk_hotel_details' or other hotel search tools (e.g., trivago). It states required inputs but lacks 'when-not-to-use' or prerequisite 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?

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to mention error handling (what if city not found?), ambiguity resolution (multi-airport cities like 'New York'), return format, or whether matching is fuzzy/exact.

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?

Extremely concise single sentence with no extraneous information. The '[skiplagged]' prefix is minimal metadata, and the functional description is front-loaded and 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?

For a simple 2-parameter lookup tool, the description covers the core contract but lacks important context given zero annotations and no output schema—specifically how ambiguous city names are handled and what the return structure looks like.

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%, documenting both 'input' (city name) and 'renderMode' (output format). The description adds no additional parameter context (e.g., expected city name format), but baseline 3 is appropriate since the schema fully documents the interface.

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 transformation (resolve city name → IATA code) with a specific verb and output format. However, it does not explicitly differentiate from the sibling tool 'skiplagged_sk_resolve_location', leaving ambiguity about which resolution tool to use.

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?

No guidance on when to use this tool versus alternatives like 'skiplagged_sk_resolve_location' or 'airports_lookup'. No mention of prerequisites (e.g., does the city need to be exact match?) or exclusion criteria.

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

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

With no annotations provided, the description carries the full disclosure burden. It successfully notes the 'nearest airport' selection behavior (returning one result, not a list) and describes the return values (IATA code and city information) compensating for the missing output schema. However, it omits details on search radius, error handling when no airport is nearby, or rate limiting.

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

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

Single sentence structure with zero wasted words. The information is front-loaded with the provider namespace '[skiplagged]' followed immediately by the verb and resource mapping. Every clause serves to clarify the transformation from input to output.

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 moderate complexity (3 simple parameters) and lack of output schema, the description adequately compensates by specifying the return format (IATA code and city information). It successfully communicates the core functionality, though it could be improved by noting the geographic search radius or error response behavior.

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?

Input schema has 100% description coverage ('latitude', 'longitude', 'Preferred render mode'), establishing a baseline of 3. The description mentions 'latitude and longitude' but does not augment the schema with additional semantic details such as valid coordinate ranges, decimal precision requirements, or examples. It meets but does not exceed the schema's semantic coverage.

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

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

Description provides specific verb ('Resolve'), clear input resource ('latitude and longitude'), and specific output ('IATA code of nearest airport and city information'). The '[skiplagged]' prefix distinguishes the provider, and the explicit lat/lng input clearly differentiates it from sibling tool 'skiplagged_sk_resolve_iata' which likely performs the inverse operation.

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 usage by specifying coordinate inputs, indicating it should be used when exact latitude/longitude are available. However, it lacks explicit guidance on when to use this versus siblings like 'airports_near' or 'skiplagged_sk_resolve_iata', and does not mention exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full disclosure burden. It adds valuable context about return values ('returns matching operators with their IDs'), but lacks operational details such as whether the search is case-sensitive, supports fuzzy matching, or has rate limiting considerations.

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 that each earn their place: (1) namespaced invocation context and when-to-use, (2) core function and return value, (3) downstream workflow guidance. Minor redundancy exists between sentences 1 and 2 regarding 'by name' searching, but overall efficiently structured.

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

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

For a single-parameter lookup tool without output schema, the description is sufficiently complete. It explains the input purpose, the matching behavior, and the intended use of the return value (ID for filtering), covering all necessary context for an agent to use this in a multi-step workflow.

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 100% schema description coverage (textSearch is well-documented with an example), the baseline is 3. The description references searching 'by their name' which aligns with the parameter, but adds no additional syntax, format constraints, or semantic details 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 specific purpose: finding a tour operator's ID by name for filtering tours. It distinguishes itself from sibling tools like 'tourradar_b2b-operator-details' by focusing specifically on the lookup-by-name use case rather than general operator information retrieval.

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

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

Provides explicit when-to-use guidance ('Use this when you need to find a tour operator's ID...') and workflow continuity ('Use the returned operator ID with tour search filters'). However, it could be strengthened by explicitly naming the specific tour search tool (e.g., tourradar_vertex-tour-search) that consumes these IDs.

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

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

With no annotations provided, the description carries the full disclosure burden. It successfully explains the fuzzy matching behavior for city names ('supports multiple name variants to handle different spellings'), which is critical for correct invocation. It lacks details on error handling or exact return structure, but the core behavioral trait (variant matching) is well documented.

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 consists of two highly efficient sentences with no redundancy. It front-loads the '[tourradar]' namespace tag and immediate usage guidance, followed by behavioral specifics and concrete examples. 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?

Given the tool's simplicity (2 parameters, 100% schema coverage, no nested objects), the description provides adequate context. It clarifies the output purpose (city IDs) despite lacking an output schema, though explicitly describing the return format would strengthen completeness further.

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%, establishing a baseline of 3. The description adds value beyond the schema by illustrating the specific technique for using the 'search' parameter (providing multiple spelling variants like 'Krakow', 'Kraków', 'Cracow'), which helps the agent understand the intended parameter usage pattern.

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 searches for cities to find IDs for use in tour search filters (start city, end city, cities to visit). It distinguishes itself from sibling tools like 'tourradar_vertex-tour-search' by explicitly stating its role as a lookup service for filter parameters rather than a tour discovery tool.

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

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

The description explicitly states when to use the tool ('when you need to find city IDs for tour search filters'), providing clear workflow context. However, it lacks explicit 'when not to use' guidance or named alternative tools for cases where users already have city IDs.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly identifies the operation as read-only by stating it 'Returns a list,' and specifies the payload contents (IDs and names). However, it lacks details on rate limits, caching behavior, authentication requirements, or error conditions that would fully inform an agent.

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 consists of two efficient sentences with zero waste. It is front-loaded with usage context ('Use this when...'), followed by behavioral specifics ('Returns a list...'). Every sentence earns its place by providing distinct 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?

Given the low complexity (zero parameters, simple list return) and absence of an output schema, the description adequately compensates by explaining what data is returned (continents with IDs and names) and its purpose (tour search filters). It is complete enough for a lookup utility, though it could benefit from mentioning data freshness or pagination.

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 contains zero parameters (empty object). According to the evaluation baseline, tools with zero parameters receive a baseline score of 4, as there are no parameter semantics to elaborate upon in the description.

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 explicitly states the tool 'Returns a list of all supported continents with their IDs and names,' providing a specific verb (returns/list) and resource (continents). It clearly distinguishes itself from sibling tools like tourradar_b2b-countries-list by specifying 'continent IDs for filtering tours by region' versus country or city lookups.

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 opening sentence '[tourradar] Use this when you need continent IDs for filtering tours by region' provides explicit when-to-use guidance. However, it lacks explicit when-not-to-use guidance or named alternatives (e.g., it doesn't mention to use countries-list for country-level filtering 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?

No annotations provided, so description carries full burden. It discloses return structure (IDs, names, ISO codes) and implies it's a read operation, but lacks details on data freshness, payload size, caching, or rate limits that would help an agent understand operational characteristics.

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

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

Two sentences with zero waste. First sentence provides usage guidance, second describes return values. Efficient structure with critical information front-loaded (including the [tourradar] namespace tag).

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

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

For a zero-parameter reference tool without output schema, the description adequately covers the return structure (IDs, names, ISO codes) and use cases. Minor gap regarding data volume or update frequency prevents 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?

Input schema has 0 parameters. With zero parameters, baseline score is 4 as no parameter semantic clarification is required or possible.

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?

Description clearly states the tool looks up 'country IDs for filtering tours or validating country names' and returns 'a complete list of all supported countries.' Specific verb+resource combination distinguishes it from sibling tools like cities-search, continents-list, and tour-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?

Explicitly states when to use ('when you need to look up country IDs for filtering tours or validating country names'), providing clear context for selection. Lacks explicit 'when not to use' or named alternative tools, preventing a perfect score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes the return value structure ('list of all supported currencies with their codes... names, and symbols'), but lacks safety indicators (read-only status, side effects, rate limits) that would help an agent understand operational constraints.

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 consists of exactly two high-value sentences: one for usage conditions and one for return value specification. The '[tourradar]' prefix serves as useful namespacing metadata. No redundancy or filler text 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?

Given the tool's simplicity (zero parameters, no output schema), the description provides sufficient context by detailing the return format (codes, names, symbols). For a static lookup endpoint, this coverage is adequate, though mention of B2B-specific constraints would elevate it to 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?

The input schema contains zero parameters. According to scoring rules, 0 parameters establishes a baseline score of 4. The description correctly does not invent parameters, maintaining alignment with the empty 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 tool 'check[s] supported currencies or get[s] currency details like symbols,' providing a specific verb + resource combination. It distinguishes from siblings like tourradar_b2b-countries-list and tourradar_b2b-languages-list by explicitly focusing on currency codes and symbols.

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 opens with explicit usage guidance: 'Use this when you need to check supported currencies...' providing clear when-to-use context. While it does not explicitly state when NOT to use it or name alternatives, no sibling tools provide currency lookup functionality, making this omission minor.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully compensates for the missing output schema by describing the return structure (IDs, codes, and names). However, it lacks other critical behavioral context such as rate limits, caching behavior, authentication requirements, or explicit confirmation that this is a read-only operation.

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 consists of two highly efficient sentences. The first establishes the use case context, and the second describes the return payload. There is no redundant text, and the '[tourradar]' prefix effectively namespaces the tool without cluttering the descriptive content.

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 low complexity (zero parameters, simple list return), the description is nearly complete. It explains the return values since no output schema exists and connects the tool to its ecosystem (tour search filters). It could be improved by explicitly naming the specific parameters in sibling tools that accept these language IDs.

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 contains zero parameters, establishing a baseline score of 4. The description correctly omits parameter discussion since none exist, requiring no additional semantic clarification beyond what the empty schema already communicates.

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 returns a list of supported languages with their IDs, codes, and names. It specifies the exact resource (languages) and action (returns/list), and distinguishes itself from siblings by clarifying its specific purpose: obtaining language IDs for filtering tours by guide language.

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 explicit when-to-use guidance ('Use this when you need language IDs for filtering tours by guide language') and context ('for use in tour search filters'). However, it does not explicitly name sibling tools (like tourradar_vertex-tour-search) that consume these IDs or describe when not to use this tool.

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

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

With no annotations provided, the description carries the full burden. It compensates partially by listing specific return fields (name, code, terms), but omits safety classification (read-only vs destructive), error handling (invalid operatorId), or rate limiting 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?

Two sentences with clear separation of usage context (first) and functional description (second). The '[tourradar]' tag at the start is unnecessary clutter given the tool name convention, but overall efficient without redundant phrasing.

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?

Adequate for a simple single-parameter lookup tool. Covers the essential contract: input (operatorId), output fields (name, code, terms), and trigger condition. Missing only the origin/source of valid operator IDs, which would complete the usage loop.

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 0% (operatorId lacks description). The text mentions 'based on operator ID' which maps to the parameter, but fails to fully compensate by explaining what constitutes a valid operator ID or where to obtain it (e.g., from search results). Just meets baseline expectations.

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 (tour operator) and specific data retrieved (name, code, terms & conditions). It implicitly distinguishes from siblings like 'tourradar_b2b-tour-details' (tours vs operators) and 'tourradar_algolia-operator-search' (lookup by ID vs search). The '[tourradar]' prefix is redundant noise.

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

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

Provides a clear trigger ('when the user wants information about a tour operator'), but fails to mention the critical sibling relationship with 'tourradar_algolia-operator-search'—users typically need to search/find operators before looking up details by ID. No 'when not to use' guidance 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes the return payload ('list of departures... including availability status, pricing, and booking information'), but fails to disclose operational traits like read-only safety, pagination limits, or error handling 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 description consists of two highly efficient sentences. The first is front-loaded with the trigger condition, and the second explains the return value. No redundancy or filler text exists; every word serves a distinct purpose.

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 absence of an output schema, the description adequately compensates by detailing what the tool returns (departures with availability, pricing, and booking info). Minor gap: it does not mention that tourId typically comes from companion search tools, but overall coverage is sufficient for a list/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 description coverage is 100%, so the schema fully documents all three parameters (tourId, dateRange, page). The description references 'specific tour' and 'date range' which align with parameters, but adds no additional semantic context (e.g., date format details, pagination behavior) beyond what the schema already provides. 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 clearly identifies the tool's purpose with specific verbs ('returns') and resources ('departures', 'availability status', 'pricing'). It distinguishes from siblings like tourradar_b2b-tour-details (general info) and tourradar_web-tour-booking (reservation) by focusing specifically on listing available departure dates within a range.

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 first sentence provides explicit when-to-use guidance ('when the user asks about available departure dates, pricing for specific dates, or needs to validate if a departure date is available'). However, it lacks explicit when-NOT-to-use guidance or mention of prerequisite steps (e.g., obtaining tourId from search tools).

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

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

With no annotations provided, the description must carry the full burden. It compensates partially by listing return fields (itinerary, pricing, images, booking links), but fails to disclose safety properties (read-only vs destructive), authentication requirements, or error conditions. 'Fetches' implies a read operation, but this isn't explicitly confirmed.

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 wasted words. The '[tourradar]' prefix serves as useful namespacing. The structure front-loads the usage trigger and follows with the technical capability. Slight deduction for the bracketed prefix being slightly informal.

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?

Adequate for a single-parameter tool with no output schema, as it describes the return payload contents. However, gaps remain: it doesn't explain the parameter's semantics despite zero schema documentation, and doesn't clarify relationships with the numerous sibling tourradar tools that also require tour IDs.

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 has 0% description coverage for the tourId parameter. The description mentions 'based on tour ID' which acknowledges the parameter's existence, but doesn't explain what a tour ID represents, where to obtain it (e.g., from vertex-tour-search), or the exclusiveMinimum constraint. Barely meets minimum viability for undocumented schemas.

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 it 'Fetches comprehensive tour details' with specific examples (itinerary, pricing, operator info), distinguishing it from general search tools. However, it doesn't explicitly differentiate from sibling tour-specific tools like tour-departures or tour-faq.

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 provides a clear 'Use this when...' trigger for detailed tour information, but lacks explicit guidance on when NOT to use it (e.g., for availability dates use tour-departures instead) and doesn't mention the prerequisite of obtaining a tourId from search tools first.

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

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

No annotations are provided, so the description carries the full burden. It successfully discloses pagination behavior ('paginated list') and content scope ('covering topics like inclusions, requirements, and policies'), but lacks information on rate limits, error handling, or data freshness.

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 consists of two efficient sentences with zero waste. It is front-loaded with usage context ('Use this when...') followed by return value description, making it easy for an agent to quickly assess relevance.

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 simple 2-parameter schema and lack of output schema, the description adequately covers the essential usage trigger and return format. However, it could improve by explicitly describing the required tourId parameter and pagination limits.

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 50% (page is documented, tourId is not). The description implies the tourId parameter through 'specific tour' but does not explicitly document its semantics, format, or how to obtain it. This meets baseline expectations for partial coverage without full compensation.

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 returns a 'paginated list of frequently asked questions and answers about a specific tour' (specific verb+resource). It distinguishes itself from sibling tools like tourradar_b2b-tour-details by explicitly scoping to FAQ content rather than general tour information.

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 opens with explicit when-to-use guidance: 'Use this when the user has questions about a tour that might be answered in the FAQ section.' However, it does not explicitly name alternatives (e.g., when to prefer tourradar_b2b-tour-details over this tool) or provide exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It discloses the data transformation aspect (preparing map data with day-by-day coordinates) but omits safety profiles (read-only vs destructive), output format details, or rate limiting 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?

Two sentences with zero waste. The first sentence front-loads the usage condition, while the second explains the technical behavior. Every word earns its place.

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

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

Given the single-parameter simplicity and lack of output schema, the description adequately covers the tool's specific niche (map visualization). However, with 0% schema coverage, it should ideally explain the tourId format or sourcing to be complete.

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

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

Schema description coverage is 0%, requiring the description to compensate. It references 'one or more tours' which aligns with the tourIds array parameter and minItems: 1 constraint, providing basic semantic context. However, it does not explain what tourIds represent or where to obtain them.

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 specific verbs ('Fetches', 'prepares') and clearly identifies the resource (tour map data with itinerary locations and coordinates). It effectively distinguishes from sibling tourradar_b2b-tour-details by emphasizing 'map', 'visual display', and 'coordinates'.

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 first sentence provides explicit when-to-use guidance ('when the user wants to see tour routes on a map or compare itineraries visually'). However, it does not explicitly name the alternative tool (tour-details) for non-visual data retrieval.

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

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

With no annotations provided, the description carries full burden. It adds valuable behavioral context by specifying the return structure is 'hierarchical' (groups containing individual types). However, it omits other behavioral traits like idempotency, potential data volume, or error conditions that would be expected for a read-only reference tool without annotation coverage.

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

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

Extremely efficient two-sentence structure: front-loaded with use case (when you need IDs for filtering) followed by return value specification (hierarchical list). No redundant words; every clause delivers essential disambiguating 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 zero-parameter lookup tool, the description adequately compensates for the missing output schema by describing the hierarchical return structure and included fields (IDs and names). A 5 would require either an output schema or richer detail about the data format/limits.

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

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

The tool has zero parameters, warranting the baseline score of 4. The description appropriately focuses on return value semantics rather than inventing parameter documentation where none exists.

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 explicitly states the tool returns 'tour type IDs for filtering tours by category' with concrete examples (adventure, cultural, wildlife), distinguishing it from sibling tour search tools (tourradar_vertex-tour-search) and other reference lists (cities, countries). The '[tourradar]' prefix identifies the domain.

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

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

Provides explicit 'Use this when...' guidance for obtaining filter IDs, establishing clear context for when an agent needs categorical taxonomy vs. specific tour details. Lacks explicit 'when not to use' or named alternatives, though the functional distinction from search tools is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It specifies the ISO format return type, which is valuable, but omits other behavioral traits like timezone handling (UTC vs local), idempotency, or whether the result is cached.

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 consists of three dense sentences with zero redundancy. It front-loads the usage context ('Use this when...') before detailing the return format and operational importance, ensuring every clause provides actionable information.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description adequately covers the essential context: return format (ISO), use case (date filter calculations), and namespace. A minor gap is the lack of timezone specification, but this is sufficient for agent 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?

The input schema contains zero parameters, establishing a baseline of 4. The description appropriately does not invent parameters, maintaining consistency with the empty 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 tool 'Returns the current date and time' and specifies the '[tourradar]' namespace, distinguishing it from sibling travel search tools like 'tourradar_vertex-tour-search' which perform searches rather than returning temporal reference data.

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 provides explicit temporal context for usage ('especially before setting departure date filters' and 'Essential for calculating valid date ranges'), clearly indicating when to invoke it relative to tour search operations, though it does not explicitly name alternative tools to avoid.

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

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

With no annotations, the description carries full burden and successfully discloses the AI-powered semantic matching behavior and the hard requirement for tourIds to scope results. Minor gap: doesn't mention pagination behavior or result limits, though pageToken implies it.

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?

Five sentences with zero waste: tool identity, key constraint, usage trigger, query mechanics, and fallback workflow. Information is perfectly 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?

Given the 5-parameter schema with 100% coverage and no output schema, the description adequately covers the search workflow and constraints. Minor deduction for not clarifying what the return structure looks like (e.g., review objects vs snippets).

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%, establishing baseline 3. The description adds practical usage context with concrete examples ('food', 'guide', 'accommodation') and explains the dependency relationship between query and tourIds that pure schema descriptions don't 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 opens with a specific verb+resource+mechanism ('Search tour reviews using AI-powered semantic search') and clearly distinguishes from sibling tour-search tools by focusing on 'reviews' rather than tour metadata.

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

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

Explicitly states when to use ('when the user asks about reviews, feedback, or experiences') and provides clear workflow guidance with named alternatives ('When you don't have tour IDs, use vertex-tour-search or vertex-tour-title-search first').

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

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

No annotations provided, so description carries full burden. Discloses Google Vertex AI implementation and performance implications ('make search faster'), plus response structure (tour ID, name, URL, operator). Missing explicit read-only declaration, rate limits, pagination behavior, or error handling details expected for a complex search tool.

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?

Appropriately structured with markdown tables and code blocks for a 17-parameter tool. Front-loaded with usage context. Minor redundancy between opening paragraph and 'Use vertex-tour-search when:' section, and typos ('PLESE', 'Before use') slightly detract from polish.

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?

Comprehensive coverage compensating for lack of output schema by manually documenting response fields (tour ID, operator info, description). Extensive examples cover simple text search, location filters, range filters, and display modes, fully contextualizing the complex filter combinations.

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 high (94%), establishing baseline 3. Description adds significant value through concrete JSON examples for complex nested filters (duration, price, age ranges), tabular organization of 17 parameters, and critical dependency notes (e.g., using 'b2b-cities-search' to obtain city IDs for filters).

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?

Explicitly defines the tool as 'AI-powered semantic search for tours using natural language queries' and distinguishes it from siblings by specifying use cases like 'when the user describes what they want in natural language' (contrasting with vertex-tour-title-search for exact titles and b2b-tour-details for specific IDs).

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

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

Provides clear 'when to use' criteria (natural language queries, semantic intent understanding) and explicitly mentions complementary tools like 'b2b-cities-search' for resolving city IDs. Lacks explicit 'when not to use' guidance contrasting with sibling tools like vertex-tour-title-search.

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

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

No annotations provided, so description carries full burden. Discloses AI-powered semantic nature (distinguishes from keyword search) and return format (list of IDs/titles). Implies read-only via 'Search' but doesn't explicitly state safety/destructive profile.

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 sentences with zero waste: purpose prefix, return value, usage condition, and alternative tool. Front-loaded with specific capability (AI semantic search). 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 single-parameter search tool, description is complete: explains return values (compensating for missing output schema), establishes workflow with sibling tool (b2b-tour-details), and covers the AI behavioral aspect. No gaps given low complexity.

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

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

Schema coverage is 100%, establishing baseline 3. Description adds value by implying 'AI-powered semantic search' allows natural language queries beyond exact title matches, adding semantic context not present in schema's 'Tour title or partial title' description.

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

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

Specific verb+resource: 'Search for tours by title using AI-powered semantic search.' Distinguishes from sibling tourradar_vertex-tour-search by specifying 'by title' and 'AI-powered semantic' method. Also clarifies return values (tour IDs and titles).

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

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

Explicit when-to-use: 'Use this when you need to look up a tour by name.' Explicit alternative named: 'When you know tour id, use b2b-tour-details tool' - creating clear workflow from search to details.

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

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

No annotations provided, so description carries full burden. Discloses data integrity requirements well ('Requires real contact details', 'Never fabricate or assume user data'). States it creates a booking request. However, fails to disclose operational side effects: whether this triggers payment processing, confirmation emails, availability holds, or what error states look like. For a mutation tool with no annotations, this is a moderate 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?

Exceptionally well-structured and front-loaded. Opens with activation condition, follows with core action, then requirements, prerequisite workflow, and data constraints. Four sentences with zero waste—every clause provides distinct value (when to use, what it does, required data, workflow step, validation rule).

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 9 required parameters and no output schema/annotations, the description adequately covers input prerequisites (departure date verification, contact collection) and data constraints. However, it completely omits what the tool returns or what happens after invocation (confirmation number? email sent? booking status?). For a complex booking operation, this is a significant gap in completeness.

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 80% (high), establishing baseline 3. The description adds workflow context beyond schema: 'phone optional' clarifies the optional parameter among required contact fields, and 'Never fabricate... always ask for missing information' provides validation constraints not captured in JSON schema. It mentions 'names' compensating slightly for firstName/lastName lacking schema descriptions, but doesn't add format details or semantics for agentInformation/extraInformation.

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 it 'Creates a booking request for a specific tour' with specific verb and resource. The prefix '[tourradar]' and the explicit distinction from search operations (via 'when the user explicitly wants to book') effectively differentiates it from sibling search tools like tourradar_vertex-tour-search. However, it could clarify whether this completes a purchase or merely submits an inquiry.

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

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

Provides explicit activation criteria: 'when the user explicitly wants to book a tour and has provided their contact details.' Includes critical prerequisite workflow: 'Always confirm the departure date by checking departures first' (implicitly referencing tourradar_b2b-tour-departures). Lacks explicit naming of alternative tools for searching vs booking, though the intent is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool sends an email with a PDF and emphasizes the critical constraint that email addresses must be user-provided (never assumed). However, it lacks disclosure of idempotency, rate limits, error handling for invalid emails, or whether this action registers the user for marketing.

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?

Well-structured with the trigger condition front-loaded ('Use this when...'). The content is efficient with minimal waste, though slightly redundant between the first sentence ('requests a tour brochure...be sent') and second ('Sends a tour brochure'). Overall, every sentence earns its place by providing distinct guidance on purpose, action, or constraints.

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 limited complexity (2 primitive parameters, no output schema), the description is appropriately complete. It covers the essential safety-critical constraint (email verification) that would otherwise be missing. A perfect score would require additional behavioral details like error handling or rate limiting, but the coverage is sufficient for safe 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 coverage is 100%, establishing a baseline of 3. The description adds valuable usage context beyond the schema by reinforcing the conversational workflow: 'ensure the user has provided their email address' and 'ask him before executing'. This contextualizes the raw parameter requirements into agent behavior guidance.

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 explicitly states the tool 'Sends a tour brochure (PDF file) to the specified email address' using a specific verb and resource. It clearly distinguishes from sibling tools like tourradar_web-tour-booking or tourradar_b2b-tour-details by focusing on brochure/PDF delivery via email rather than booking or retrieving tour metadata.

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

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

Provides explicit when-to-use ('when the user requests a tour brochure or PDF'), prerequisites ('ensure the user has provided their email address'), and prohibitions ('Never generate or assume email addresses'). It also includes actionable guidance on handling missing data ('If not provided, ask the user for 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?

With no annotations provided, the description carries the full burden and successfully discloses the core orchestration behavior ('Routes to the right tools automatically') and aggregation ('returns a combined answer'). It does not mention error handling if no tools match or latency implications of the routing layer.

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 followed by a high-value example. The first sentence establishes the natural language interface, the second explains the routing mechanism, and the example immediately clarifies the multi-tool capability without redundant exposition.

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 presence of an output schema and the tool's role as an orchestrator across dozens of siblings, the description adequately establishes it as the primary natural language entry point. It could be improved by enumerating the domains covered (flights, hotels, visas, etc.), but the example implies broad coverage.

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 has 0% description coverage (only title 'Query'). The description compensates effectively by specifying the parameter accepts 'natural language' and provides a concrete example showing the expected syntax and complexity level, though it omits constraints like length limits.

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 accepts natural language travel questions and automatically routes to appropriate backend tools, distinguishing it from the 40+ specific API siblings (e.g., kiwi_search-flight, visa_check) which require structured inputs.

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 example query ('Cheapest flights... and do I need a visa?') effectively demonstrates the intended use case for complex, multi-domain questions that would otherwise require multiple tool calls. However, it lacks explicit guidance on when to use specific single-purpose tools 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important coordinate interpretation context (target vs. user location) but fails to disclose safety profile (read-only vs. destructive), return format, pagination, or rate limiting that would help an agent understand operational constraints.

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?

Well-structured with clear front-loading of purpose followed by usage guidance. The embedded JSON block with date information is slightly bulky but functionally necessary for date parameter context. No redundant or wasted sentences beyond the [trivago] namespace tag.

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 tool with 12 parameters (including nested filter objects), no output schema, and zero annotations, the description provides adequate context by explaining the coordinate system and providing temporal reference data. It appropriately relies on the comprehensive schema for parameter details while clarifying the geospatial search semantics.

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

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

Schema has 100% coverage establishing a baseline of 3. The description adds value by including the 'Additional Information' block with current date (2026-03-30), which provides essential temporal context for the required arrival/departure date parameters. It also reinforces coordinate semantics though this overlaps somewhat with schema 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 clearly states the specific action (search for accommodations/hotels), method (using coordinates and radius), and platform (Trivago). It effectively distinguishes itself from sibling tool 'trivago_trivago-accommodation-search' by emphasizing the geospatial radius-based approach versus general 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?

Explicitly states when to use ('when you want to find accommodations near a specific location or street') and provides critical semantic guidance that coordinates refer to the search target/landmark, NOT the user's personal location. Lacks explicit mention of the sibling search tool as an alternative for non-coordinate searches.

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

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

No annotations are provided, so the description carries full disclosure burden. It adds temporal context via the 'knownInformation' block (current date 2026-03-30) relevant for date parameters, but lacks details on rate limits, pagination, caching behavior, or return value structure.

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 purpose and usage guidelines. The JSON metadata block, while slightly awkwardly formatted, provides essential temporal context for date validation. No sentences are wasted, though the '[trivago]' prefix is redundant with the tool name.

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

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

Given the complex schema (11 parameters, nested filter objects) and lack of output schema, the description adequately covers selection criteria but fails to describe what the tool returns (e.g., list of hotels, pricing, availability) or any result limits, leaving a significant gap for an agent invoking the 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?

With 100% schema description coverage, the baseline is 3. The description adds valuable semantic context by specifying the tool is for 'broader areas like cities, countries,' which helps interpret the 'id' and 'ns' location parameters beyond the schema's basic definitions.

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 'Search[es] for accommodations and hotels on Trivago' using a specific verb and resource. It distinguishes itself from the sibling 'trivago-accommodation-radius-search' by specifying it is for 'broader areas like cities, countries, etc.'

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 when to use ('broader areas like cities, countries') and names the exact alternative tool ('trivago-accommodation-radius-search') for specific locations, providing clear decision criteria.

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