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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered outside the description. The description adds value by listing the response fields, but it does not disclose error behavior, rate limits, or any other operational traits beyond what the annotations and schema already convey.

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

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

The description is a single well-formed sentence that front-loads the core action and resource, then efficiently lists the key response contents. There is no repetition, filler, or redundant restating of the schema.

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

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

For a single-resource read tool with rich schema descriptions and openWorldHint, the description is reasonably complete: it names the resource, the lookup key, and the main return categories. It could mention what happens when the attraction id is invalid or unknown, but the annotations and schema make this 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 the parameter descriptions are already detailed, especially for view and campaign_value. The tool description adds no parameter-specific meaning, so the baseline of 3 is appropriate because the schema carries the full load.

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 action (get details) and a specific resource (one Viator attraction by id), and it lists representative fields returned. This clearly separates it from sibling tools like vt_search_attractions, which would be used to find attractions rather than fetch one by id.

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

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

The phrase 'by id' implies the tool should be used when the agent already knows an attraction_id, which is a useful contextual signal. However, it does not explicitly mention alternatives such as vt_search_attractions for locating an id, nor does it state 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context by warning that prices are in the supplier's currency and pointing to the currency field for conversion — a non-obvious gotcha that affects how an agent should interpret results.

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

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

Two sentences with no filler: the first front-loads the verb, resource, and result contents, and the second isolates the currency caveat as a NOTE. 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 no-output-schema tool, the description covers the main return categories and flags the currency gotcha, which is essential for correct interpretation. The view parameter is fully documented in the schema. It does not describe pagination or exact response nesting, but that is a minor gap given the openWorldHint and the detailed 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%, so product_code and view are already well documented in the input schema. The description does not add parameter-level meaning; its currency note refers to the response, not the inputs. Baseline 3 applies because the schema carries the semantic load.

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

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

The description uses a specific verb and resource: 'Get the availability schedule and pricing for a Viator product.' It enumerates the exact content returned — seasons, days of week, start times, unavailable dates, and per-age-band pricing — which clearly distinguishes it from sibling tools like vt_get_product or 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?

The purpose statement makes it obvious when to use this tool: whenever availability schedule and pricing for a Viator product are needed. The NOTE about supplier currency also redirects agents to vt_get_exchange_rates for conversion. It does not explicitly state exclusions such as 'use vt_get_product for product details,' 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 and openWorldHint. The description adds that this is cached reference data, which is a meaningful behavioral disclosure beyond the annotations, and implies the rates may not be real-time.

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

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

Two sentences, front-loaded with the core action and immediately followed by the use case and caching behavior. No filler.

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

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

For a simple read-only tool with full schema parameter descriptions, the description covers purpose, use case, and data currency behavior. It does not describe the response format, but the absence of an output schema and low complexity make this 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 the view parameter is already described in detail. The description adds only high-level context ('currencies Viator supports') and does not add parameter-level details, 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?

States a specific verb, resource, and scope: get exchange rates between currencies Viator supports. It also references vt_get_availability_schedule as the upstream consumer, making its role clear among sibling 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?

Gives a clear context: use it when converting supplier-currency prices returned by vt_get_availability_schedule. It does not explicitly name alternatives or when-not-to-use conditions, but the absence of a sibling exchange-rate tool makes the guidance sufficient.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and completeness profile. The description adds useful behavioral context beyond those annotations: the data is cached, and the call accepts up to 500 references. It does not discuss invalid-reference behavior, but this is minor for a read-only lookup 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?

The description is three short, information-dense sentences with no filler. The core purpose is front-loaded, followed by the batch limit and the caching caveat. 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 tool with only two parameters, one required, and a read-only/open-world annotation profile, the description plus schema is complete. It covers what the tool resolves, what it returns, the input constraint, and the caching behavior. No output schema exists, but the description's 'names, addresses, and coordinates' plus the extensively documented `view` parameter are sufficient.

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 schema already documents both `location_refs` and `view` in detail, including the maxItems cap and the compact/full distinction. The description adds a little semantic color — examples of reference types and the output fields — but it does not need to carry the parameter-documentation burden.

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

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

The description opens with a specific verb, 'Resolve,' and clearly identifies the resource ('Viator location references') and the output ('names, addresses, and coordinates'). It gives concrete examples ('LOC-...', meeting points, pickup points) that distinguish it from sibling search tools like vt_search_products or 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 clearly indicates when to use the tool: when an agent has Viator location reference IDs from product details. It also states the batch limit of 500 references per call. It does not explicitly name alternatives or exclusions, but the context is specific enough that an agent can infer this is the dedicated reference-resolution tool.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the agent knows this is a non-mutating call. The description adds useful context by listing what data is returned, but it does not disclose additional behavioral traits such as payload size, rate limits, or error semantics. This is acceptable given the annotations but not rich behavioral disclosure.

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 that front-loads the action and resource, then lists the included data fields. There is no filler, repetition, or vague language; every word contributes 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 lookup with three well-documented parameters and no output schema, the description sets adequate expectations by enumerating key fields returned. The lack of an output schema is partially compensated by this enumeration, and response shape variability is covered in the view parameter schema. It is complete enough for an agent to call correctly.

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

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

Schema description coverage is 100%, with all three parameters (product_code, view, campaign_value) documented in detail. The tool description reinforces that product_code is the lookup key but adds no new parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific verb ('Get'), a specific resource ('one Viator product by product code'), and enumerates the returned data fields (description, inclusions/exclusions, itinerary, product options, cancellation policy, booking URL, review summary). This makes it clearly distinguishable from sibling tools like vt_search_products and vt_get_attraction without needing 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 phrase 'by product code' clearly signals that callers should already have the identifier, providing clear context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it (e.g., for search or attraction lookups), so it stops short of full routing guidance.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds meaningful behavioral detail beyond these: resolution mirrors real tool behavior, exactly one authenticated request is made, and it reports credential source, acceptance, round-trip time, and categorized failure hints. It also explicitly states it never returns the credential.

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 dense but every sentence serves a purpose: mechanism, reported outputs, usage trigger, and safety guarantee. It is front-loaded with the core behavior and does not waste words on restating the title.

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

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

For a zero-parameter diagnostic tool with no output schema, the description fully explains what will happen, what is reported, how to interpret the plain-English hint, and the safety boundary. No critical operational 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?

The tool has zero parameters and 100% schema coverage, so the description has no parameter burden. The baseline of 4 applies because there is nothing to add; the description correctly avoids inventing parameter details.

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 specific actions: resolves credentials, makes one authenticated request to api.viator.com, and reports specific diagnostics. It is clearly distinguishable from sibling tools like vt_search_products or vt_get_product, which are data-retrieval tools, whereas this is a healthcheck/diagnostic 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 call it: 'when a real tool fails and you want to know which hop broke.' It also implies a non-use by noting it never returns the credential itself, but it does not enumerate exclusions or alternative tools. Context is clear, though exclusions are minimal.

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

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

The description adds real behavioral context beyond the readOnlyHint/openWorldHint annotations: this is cached reference data, the response covers every destination, and the listed output fields convey broad payload content. It doesn't mention pagination or response envelope, but annotations already cover the safety profile, so this is solid.

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 short sentences, each earning its place: scope and output fields, downstream usage, and cache semantics. It contains no fluff, no repetition of schema docs, and front-loads the most important information.

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

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

With no output schema, the description reasonably covers the return content by naming the fields it lists. It also explains the cached nature and downstream integration. However, it never mentions pagination, response size expectations, or how to distinguish this from vt_get_locations, so it is not 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 description coverage is 100%: both view and campaign_value are fully documented with enum behavior and URL effects. The description adds no parameter-level detail, but the schema carries the full burden. Baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'List every Viator destination (cities, regions, countries)' and enumerates the returned data (ids, parent hierarchy, IATA codes, time zones, coordinates). This clearly distinguishes the tool from search/get siblings without requiring schema inspection.

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

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

It explicitly tells the agent how to use the tool downstream: 'Use the destinationId with vt_search_products / vt_search_attractions.' The 'Reference data — cached' label also clarifies appropriate context. It does not explicitly say when not to use it or name alternatives like vt_get_locations, so it misses the top 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?

Annotations already declare readOnlyHint and openWorldHint. The description adds value beyond those by stating 'Reference data — cached,' which tells the agent the data may be cached and refreshed, and by describing the returned hierarchy. No contradiction with annotations 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 two short sentences plus a fragment, with no filler. It front-loads the primary action and resource, then gives a usage note, then the caching trait. 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 read-only list tool with one optional parameter and no output schema, the description covers purpose, return structure, usage relationship to a sibling, and caching behavior. The parameter semantics are fully covered by the input schema, so nothing needed by an agent to select and invoke this tool is missing.

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

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

Schema description coverage is 100%, and the only parameter, 'view', has a detailed schema description explaining compact versus full response shapes. The tool description does not need to repeat that. However, it also does not add any parameter-level insight beyond the schema, 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 opens with a specific verb and resource: 'List all Viator product tags.' It further specifies the output shape (tag id → names in every locale, parent-tag hierarchy) and names a sibling, vt_search_products, showing where these tags are consumed. This clearly distinguishes the tool from the product, attraction, and destination tools in the sibling list.

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

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

The description gives a direct usage instruction: 'Use tag ids to filter vt_search_products.' It also labels the tool as reference data that is cached, indicating it is appropriate for lookups rather than real-time queries. It does not explicitly state when not to use it, but the context is clear enough for an agent to choose 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile, so the description does not need to restate that this is a read operation. It adds useful context about the returned content (product codes per attraction) but does not disclose details like pagination behavior or response-shape implications of the openWorldHint. The description does not contradict the annotations.

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

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

The description is two sentences with no filler. The first sentence front-loads the core operation and output content, and the second sentence gives a directly actionable prerequisite. 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?

For a read-only list tool with a rich input schema, the description covers what the tool returns, the required scoping concept (destination), and how to find destination ids. There is no output schema, but the description sufficiently indicates the key return value (attractions with product codes), and the schema handles parameter-level details.

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

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

Schema description coverage is 100%, so the input schema already explains all six parameters including destination_id, count, start, sort, view, and campaign_value. The description adds modest extra meaning by clarifying what counts as an attraction and pointing to vt_list_destinations as the source of destination ids, but it does not substantially go 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 and resource: it lists attractions (landmarks, museums, points of interest) in a Viator destination. It also mentions the key output component, product codes mapped to each attraction, which makes the tool's role unambiguous. This clearly separates it from product search or single-attraction retrieval tools.

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

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

The description provides clear usage context by explaining that this tool lists attractions within a destination and tells the agent to use vt_list_destinations to obtain destination ids. It does not explicitly state when to choose this tool over siblings like vt_search_products or vt_get_attraction, but the context makes the intended use fairly obvious.

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 little behavioral detail beyond confirming it searches multiple entity types and is fast, but it doesn't describe pagination defaults, result limits, or the fact that search semantics are free-text rather than exact-match. There is no contradiction with the annotations.

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

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

The description is two short sentences with no filler. It front-loads the core purpose, includes a helpful example, and immediately adds the routing condition ('when you don't have a destination id yet'). 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 tool's moderate complexity and the very rich input-schema descriptions that cover every parameter, the concise description is sufficient for an agent to select and invoke the tool. It does not describe return shape, but the schema's 'view' parameter already explains compact vs. full response behavior, so this is not a significant gap.

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

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

Schema description coverage is 100%, so the baseline applies: all 15 parameters have descriptive text, enums, defaults, and constraints in the schema. The tool description itself adds no parameter-level meaning, but because the schema is thorough, the description does not need to compensate. This is a standard case where the structured schema carries the parameter burden.

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

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

The description states a specific verb ('search'), a clear resource scope ('Viator products, attractions, and destinations'), and gives a concrete example query. It also distinguishes this tool from structured searches by emphasizing free-text and the 'don't have a destination id yet' use case, which separates it from sibling tools 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?

The description gives clear guidance: use this tool for free-text discovery when you lack a destination id. It implies that structured search tools are the alternative once an id is known, though it doesn't explicitly name those siblings or state when not to use this tool. The condition is clear enough for an agent to route correctly.

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, lowering the burden on the description. The description adds that results are product summaries containing pricing and booking URLs, which is helpful, but it does not disclose pagination behavior, filter combination semantics, or response size expectations beyond the schema.

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

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

Two dense sentences with no filler: the first covers purpose, filters, and return value; the second covers prerequisite ID lookup via sibling tools. Key information is front-loaded and 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 search tool with 18 optional parameters and no output schema, the description is reasonably complete: it states what is searched, which filter dimensions are supported, and what is returned. It could go further by mentioning pagination/result count behavior, but the schema's 'view' and 'count' descriptions already provide substantial detail.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by grouping the key filter dimensions (destination, tags, price, dates, rating, duration) and by explicitly directing the agent to sibling tools for valid destination and tag ids, which goes beyond the schema's field-level 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 states a specific verb ('Search') and clear resource ('Viator tours, activities and experiences') with structured filters, and notes the return type ('product summaries with pricing and booking URLs'). It does not explicitly name or contrast sibling tools like vt_search_freetext or vt_search_attractions, though 'structured filters' and 'tours, activities and experiences' partially imply differentiation.

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

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

The description gives useful procedural guidance: use vt_list_destinations to find destination ids and vt_list_product_tags for tag ids. However, it does not explicitly say when to choose this tool over alternatives such as vt_search_freetext or vt_search_attractions, so the usage context is implied rather than fully specified.

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