booking_flights_autocomplete

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

No annotations are provided, so the description carries the full burden. It states the tool 'Returns' suggestions, implying a read-only, non-destructive operation. However, it does not disclose rate limits, error behavior, or any specific output structure. For a simple autocomplete tool, this is adequate but lacks richer detail such as potential limits or response format expectations.

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 extremely concise and effective: two short sentences. The first establishes the tool's domain ('Booking.com flight autocomplete'), and the second provides the functional purpose. No redundant or filler content exists, and the key information is front-loaded.

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?

The tool has four parameters and no output schema, so the description must provide context beyond the input schema. It explains that results are airport/city suggestions for flight search, but does not describe the shape of the returned suggestions (e.g., fields like ID, name, code, type), any default limits, or error conditions. Given the absence of an output schema, this is a notable gap, but for a simple autocomplete endpoint it is not severe.

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 provides descriptions for all four parameters (query, type, origin, origin_type), achieving 100% coverage. The description only mentions 'query string,' adding no new information beyond the schema's 'City or airport name/code to search.' The origin parameter's proximity biasing is explained in the schema, so the description adds no extra semantic value. 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 clearly states the tool's purpose: 'Booking.com flight autocomplete. Returns Booking.com flight-search location suggestions (airports/cities) for a query string.' It uses a specific verb ('Returns') and resource ('Booking.com flight-search location suggestions'), distinguishing it from sibling tools like booking_flights_search (actual flight search) and booking_attractions_search. The scope is unambiguous.

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 context for use: it is for retrieving flight-search location suggestions based on a query string. This implies it should be used for autocomplete-style input. However, it does not explicitly mention alternatives (e.g., booking_flights_search for actual flight search) or exclusions, so it falls short of a perfect score.

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