search_explore

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 does disclose some important behaviors: currency is inferred from the origin's country, Viajante does not convert currency, the calling agent may convert, and unnamed baggage_buffer defaults to 0. However, it does not disclose other behavioral traits such as whether the tool mutates anything (it appears read-only), rate limits, or what happens with invalid inputs. The description adds some value beyond the schema but leaves significant behavioral gaps.

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 very concise, with only a few sentences. It front-loads the core purpose ('Destinations from one origin, then a priced shortlist') and then provides key behavioral notes. Every sentence earns its place, though the structure could be improved by grouping related notes (e.g., currency handling) and perhaps adding a brief note about the output. It is appropriately sized for a tool with many parameters, but the brevity comes at the cost of parameter semantics.

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 complexity (37 parameters, no output schema, no annotations), the description is incomplete. It does not explain the return format, how the 'priced shortlist' is structured, or how the many filtering parameters interact. The description covers only a few behavioral notes (currency, baggage_buffer) and leaves the agent to guess about the rest. For a tool this complex, the description should provide more context about the output and key parameter behaviors.

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%, so the description must compensate for the 37 parameters. It only mentions currency, origin, and baggage_buffer. The vast majority of parameters (top, via, bags, days, sort, cabin, month, proxy, start, adults, nearby, country, airlines, alliance, carry_on, children, max_stops, price_cap, exclude_via, max_layover, min_layover, depart_after, max_duration, no_overnight, arrive_before, depart_window, infants_on_lap, exclude_regions, infants_in_seat, exclude_airlines, exclude_airports, exclude_alliance, include_airports, require_overnight) are not explained in the description. The description adds minimal meaning beyond the schema, and with 0% coverage, this is a significant gap.

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 'Destinations from one origin, then a priced shortlist' states a specific verb (search/explore) and resource (destinations from an origin), and the 'priced shortlist' hints at the output. It distinguishes itself from siblings like search_flights (which likely searches specific flights) and search_dates (which likely searches date options), though it doesn't explicitly name them. The phrase is concise and informative, but could be clearer about the exact scope (e.g., exploring destinations vs. specific itineraries).

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: use this when you want to explore destinations from a given origin, as opposed to searching specific flights or dates. However, it does not explicitly state when to use this tool versus alternatives like search_trip, search_flex, or search_dates. The 'If unknown, ask' instruction for currency provides some guidance on prerequisites, but there is no explicit when/when-not or alternative routing. This is adequate but not explicit.

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