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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the list of returned fields, which is helpful behavioral context, but it does not disclose any additional behavior such as rate limits, error handling, or response format beyond what annotations already imply. With annotations covering the safety profile, this is adequate but not enriched.

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

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

A single, tightly written sentence that front-loads the core purpose and lists the key return fields without redundancy. Every word earns its place; there is no fluff or unnecessary detail.

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

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

For a simple getter with one required parameter and read-only annotations, the description is complete. It lists the return fields, the schema documents all parameters, and the openWorldHint annotation covers unexpected fields. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% — all three parameters (attraction_id, view, campaign_value) have descriptions in the schema. The tool description itself does not add any parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Get' and the resource 'details for one Viator attraction by id', and enumerates the specific fields returned (name, destination, opening hours, review summary, mapped product codes, and the attraction URL). It distinguishes itself from sibling search tools by emphasizing 'by id', making it unmistakably a single-resource getter.

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

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

The phrase 'by id' strongly implies the tool is used when the attraction id is already known, as opposed to search tools like vt_search_attractions. However, it does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to infer the appropriate use case.

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

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

Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds non-obvious behavioral context by warning that prices are in the supplier's currency and pointing to the currency field and conversion tool, which an agent would not infer from annotations alone. No contradiction exists.

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

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

The description is a single information-dense sentence with a short, targeted note for the currency caveat. It front-loads the resource and avoids repeating schema details, so 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 read-only lookup with two well-documented parameters, the description conveys the key return dimensions, the currency caveat, and the conversion path. Since there is no output schema, this level of detail is sufficient for an agent to know what to expect and how to handle prices.

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

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

Schema description coverage is 100%: both product_code and view already have detailed descriptions. The description restates some response-level concepts like per-age-band pricing but adds no new parameter-level meaning beyond what the schema provides, so the 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 uses a specific verb ('Get') and a specific resource ('availability schedule and pricing for a Viator product'), then names the concrete data dimensions returned: seasons, days of week, start times, unavailable dates, and per-age-band pricing. This clearly distinguishes the tool from sibling search/product/tag tools without requiring the agent to inspect schemas.

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

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

The intended use is reasonably implied by the phrase 'availability schedule and pricing for a Viator product,' but there is no explicit when-to-use guidance or named alternative. The only cross-tool note directs the agent to vt_get_exchange_rates for currency conversion, which is useful but does not help choose this tool over siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value with 'Reference data — cached', which discloses that rates are cached reference data rather than live quotes, informing expectations about freshness. This is a useful behavioral addition beyond the structured annotations.

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

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

Two short, telegraphic sentences front-load the purpose, then add the integration hint and caching note. There is no filler; every clause either clarifies scope or gives behavioral context.

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

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

With only three well-documented parameters, read-only/open-world annotations, and no output schema, the description covers the essential 'why' (price conversion after availability schedule) and 'what to expect' (cached reference data). The only minor gap is the absence of a note about default behavior when source/target arrays are omitted, but the schema's clarity keeps this from being a substantial shortfall.

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

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

Schema description coverage is 100%: the view parameter has a detailed response-shape explanation, and source_currencies/target_currencies both provide enum lists and examples. The description itself adds no parameter-level detail, but the schema fully documents the parameters, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get exchange rates between currencies Viator supports'. It also ties the purpose to a concrete downstream use case ('needed to convert supplier-currency prices from vt_get_availability_schedule'), which distinguishes it clearly from every sibling tool, all of which are about products, attractions, destinations, or health.

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 tells the agent when this tool is needed: after vt_get_availability_schedule, to convert supplier-currency prices. While it doesn't list alternatives or when-not-to-use conditions, no sibling appears to offer exchange rates, so the provided context is a clear and sufficient directive.

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

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

Annotations already declare readOnlyHint and openWorldHint, lowering the burden on the description. The description adds useful behavioral context: a 500-reference batch ceiling and the fact that reference data is cached. This helps an agent anticipate limits and stability without contradicting annotations.

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

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

The description is a single, well-structured sentence with no filler. The primary verb and resource are front-loaded, examples are compact, and the batch limit and caching note each earn their place in under the same clause.

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 two-parameter read-only lookup tool, the description covers inputs, outputs, and key constraints. The view parameter semantics are fully handled by the schema, and the output categories are stated in the description. It is nearly complete, missing only minor details like error or empty-result 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?

Schema coverage is 100%, so the schema fully documents both parameters. The description adds helpful examples of valid references and the output shape, but it does not substantially extend what the schema already states. 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 states a specific verb ('Resolve'), a clear resource ('Viator location references'), and the expected output ('names, addresses, and coordinates'). The examples ('LOC-...', meeting points, pickup points) make the tool's role unmistakable and distinguish it from product search or attraction search 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 phrase 'from product details' and the concrete examples make the intended use case clear: when you have Viator location reference IDs and need human-readable details. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough for an agent to choose this tool confidently.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds value by listing exactly what fields the tool returns (description, inclusions/exclusions, itinerary, etc.), which is behaviorally useful. It does not mention error cases or edge behavior, but with annotations covering the safety profile, this is a minor gap.

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

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

A single, information-dense sentence that front-loads the core purpose and enumerates the return content. There is zero waste; 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 simple get-by-code tool with thorough schema documentation and read-only/open-world annotations, the description covers the key return fields. It does not describe output structure (no output schema), but the field list gives the agent enough to know what to expect. No critical usage detail is missing.

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

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

Schema coverage is 100%: all three parameters (product_code, view, campaign_value) have detailed descriptions, including the view enum's explanation of compact vs. full. The description itself adds no parameter information beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb ('Get'), a precise resource ('one Viator product'), and the key identifier ('by product code'), and enumerates the returned content (description, inclusions/exclusions, itinerary, options, cancellation policy, booking URL, review summary). This clearly differentiates it from sibling search/list tools like vt_search_products or vt_get_attraction.

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 strongly implies usage context: you need a product code to fetch details, which is distinct from search tools that find products. It does not explicitly name alternatives or state when not to use it, but the wording 'Get full details for one Viator product by product code' gives clear context without exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description goes well beyond these by explaining exactly how the credential is resolved, that exactly one authenticated request is made, what metrics are reported, and that the credential itself is never returned. This gives an agent a clear model of the tool's runtime 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 is three sentences with no filler: the first explains the mechanism, the second enumerates the reported outputs, and the third covers safety and usage. It is front-loaded, specific, and every sentence adds operational value.

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

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

For a zero-parameter, read-only diagnostic tool with no output schema, the description fully covers what an agent needs: behavior, return contents, safety (never returns credential), and when to call it. The sibling context and annotations cover the remaining operational constraints.

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, so the schema provides nothing to document and the baseline is 4. The description does not need to explain parameters; it instead explains what the no-input call returns, which is the relevant semantic content for this tool.

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 diagnostic verb ('healthcheck', 'resolves the credential ... makes one authenticated request') and clearly distinguishes this from the data-fetching sibling tools like vt_search_products and vt_get_product. It identifies the target resource (api.viator.com) and the exact outputs reported, leaving no ambiguity about what the tool does.

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

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

The description gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' This clearly positions it as a diagnostic fallback relative to the sibling tools. It does not name specific alternatives or state when not to use it, but the usage context is unambiguous.

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

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

Annotations already declare readOnlyHint and openWorldHint; the description adds that the data is cached reference data and that the list is comprehensive ('every ... destination'), helping the agent judge freshness and scope. It does not mention pagination or response volume, but for a read-only cached list the added context is a meaningful improvement over annotations alone.

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

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

Three short sentences, each earning its place: purpose and returned fields, downstream usage, and cached-reference status. No filler, no restatement of schema fields, and no 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?

For a tool with no required parameters, no output schema, and full schema coverage, the description conveys what fields are returned, how to consume the output (destinationId), and that the data is cached. The only notable omission is volume/pagination guidance, which is minor for a cached reference-data listing.

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

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

Schema coverage is 100%, and the schema already explains view's compact/full behavior and campaign_value's URL-appending effect. The description itself adds no parameter-level detail beyond the downstream destinationId usage, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('List'), a precise resource ('every Viator destination'), and enumerates the returned fields (ids, parent hierarchy, IATA codes, time zones, coordinates). It also states the downstream use of destinationId, but it does not explicitly differentiate from the similar-sounding sibling vt_get_locations, so differentiation is implicit rather than explicit.

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

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

It gives clear usage context: this is cached reference data whose destinationId is meant to be consumed by vt_search_products / vt_search_attractions. It does not state when not to use it or compare it against a lookup alternative, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context beyond annotations by noting that the data is cached, that it returns every locale, and that it includes a parent-tag hierarchy. No contradictions with annotations.

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

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

Two sentences with no filler. The core action and response shape are front-loaded, followed by the primary usage guidance and a short cached-data note. Every clause adds value.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description covers the action, response contents, relationship to sibling tools, and data freshness. Nothing essential for an agent to select and invoke it correctly is missing.

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

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

Schema description coverage is 100% and the single optional parameter `view` has its own detailed description explaining compact vs full response shapes. The tool description does not add parameter-level detail, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'List all Viator product tags', and details the exact response shape: tag id → names in every locale, plus parent-tag hierarchy. This clearly distinguishes it from sibling search tools like vt_search_products and vt_list_destinations.

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 the intended use case: 'Use tag ids to filter vt_search_products.' It also signals that this is reference data and cached, which informs when to call it. It does not explicitly list when not to use it or alternative tools, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and openness profile is covered. The description adds only the product-code detail, not behavioral traits such as pagination behavior or result limits, but with annotations present the bar is lower.

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

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

Two sentences: the first front-loads the tool's purpose and payload, the second provides the essential prerequisite. No filler or repetition of schema 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?

All required invocation details are present: the required destination_id is explained, the response includes product codes, and paging/sort parameters are self-documenting in the schema. Since there is no output schema, a bit more return-shape detail would make it fully complete, but the current description is sufficient for a straightforward listing call.

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

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

The schema covers all six parameters with descriptions, including defaults, ranges, and the source of destination_id, so the description doesn't need to add much. It reinforces destination_id's origin but adds no new parameter-level meaning beyond the schema.

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

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

The description names a specific verb ('List') and resource ('attractions in a Viator destination'), with examples of what counts as an attraction and a distinctive detail: product codes mapped to each attraction. This clearly differentiates it from sibling tools like vt_get_attraction or vt_search_products.

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

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

It gives a direct prerequisite: 'Use vt_list_destinations to find destination ids.' It doesn't explicitly state when not to use the tool or compare against alternatives like vt_search_freetext, but the context for using it 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read and external-data profile is covered. The description adds that results span three entity types and frames the call as the 'fastest' lookup, but says nothing about pagination per type, result shape, or auth/campaign behavior beyond what annotations provide.

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, with the scope statement front-loaded ahead of the usage hint. The example query is compact and useful.

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

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

For a read-only search tool with a fully documented 15-parameter schema and no output schema, the description covers the essential what and when. It could note that results are paginated per entity type, but the schema and count's 'per type' wording largely carry that, leaving only a minor gap.

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

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

Schema description coverage is 100% and every one of the 15 parameters is documented in the schema, so the schema carries the semantics. The description only illustrates the search_term with an example and adds nothing about sort, view, date, price, or type filters — the baseline 3 for full coverage applies.

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

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

States a specific verb (search), the resource span (products, attractions, destinations), and the modality (free-text) with a concrete example query. The clause 'when you don't have a destination id yet' implicitly distinguishes it from the destination-scoped siblings like vt_search_products and vt_search_attractions.

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

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

Gives clear when-to-use context: use this as the fastest entry point before a destination id is known. It stops short of naming the alternative tools (vt_search_products, vt_search_attractions) or stating explicit exclusions, so it is strong but not fully routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return shape ("product summaries with pricing and booking URLs"), which is useful context beyond the annotations, but says nothing about pagination semantics, rate limits, or auth. With annotations doing the heavy lifting, this is adequate but not rich.

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

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

Three tight sentences: what it searches and how, what it returns, and which tools supply the id inputs. Purpose and return value are front-loaded and nothing is wasted.

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

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

With no output schema, the description usefully discloses that results are product summaries with pricing and booking URLs. All 18 parameters are documented in the schema, and the two id-source tools are named. The only gap is pagination behavior for the start/count pair, which is minor given the schema documents both.

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% across all 18 parameters, including enums for sort/order/view/currency, so the schema fully documents syntax and constraints. The description only restates the filter categories at a high level (destination, tags, price, dates, rating, duration) and adds no semantics the schema lacks. Baseline 3 applies.

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

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

States a specific verb (search) and resource (Viator tours, activities, experiences) and enumerates the filter dimensions (destination, tags, price, dates, rating, duration). The phrase "structured filters" plus the two named helper tools distinguishes it from the sibling vt_search_freetext without requiring the schema to be opened.

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 routes the agent to vt_list_destinations and vt_list_product_tags for required id values, which is genuine prerequisite guidance. However, it never states when to prefer this structured search over vt_search_freetext, nor any conditions under which this tool is the wrong choice. Usage is implied by the filter list rather than stated.

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