vt_list_destinations

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.