vt_search_attractions

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.