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 states that the tool returns flight options with prices, carriers, stops, and a direct booking link, and that prices are quoted per person. It implies a read-only search operation through the verb 'Search' but does not explicitly confirm the absence of side effects, rate limits, or authentication needs. The disclosed return format and per-person pricing are useful behavioral details beyond what the schema offers.

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, zero filler. The primary purpose and scope are front-loaded, followed by output details and the alternative routing. Every clause earns its place, and the structure is immediately scannable for an agent.

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 description covers the tool's purpose, scope, output contents, per-person pricing, and the group-threshold alternative. Given the high schema coverage and lack of an output schema, it is largely complete. Minor gaps remain: it does not specify the currency for prices or what happens when no flights are found, but these are secondary for a search tool.

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 schema already documents every parameter (origin, destination, departureDate, returnDate, passengers) with clear descriptions including IATA format and the group limit. The description adds no new parameter-level meaning; it only restates the group cutoff already present in the passengers schema. This matches the baseline of 3 for high schema coverage.

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 clear verb-resource pair ('Search live, bookable fares') and immediately scopes it to 'a party of 9 travellers or fewer' and 'ordinary tickets sold through public inventory'. It explicitly distinguishes itself from the sibling request_group_quote by naming the alternative and the condition that triggers it, so an agent can select it correctly without opening the schema.

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 explicit when-to-use guidance: 'for a party of 9 travellers or fewer' and the negative case 'For 10 or more travellers this tool is the wrong one' plus the direct alternative 'use request_group_quote instead'. No ambiguity remains about when to pick this tool over its sibling.

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