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

Annotations already establish the read-only, non-destructive, non-open-world safety profile, so the description's added value is its disclosure of provenance and limitations: a range 'drawn from what AirTreks customers have actually paid,' 'not a live quote,' and 'will not reflect today's availability or seasonality.' That is meaningful behavioral context beyond the structured 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?

Front-loads the core capability, then the usage trigger, then the caveat about being a historical range rather than a live quote. Sentences are purposeful, though the description runs a bit long and the final clause restates the earlier 'range from past bookings' point.

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 usefully describes the return: a 'per-person range in USD with how much history sits behind it,' and explains the historical-data caveat and absence of date/passenger requirements. For a 2-parameter read-only tool this is largely complete, with only minor detail left implicit.

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 both parameters in detail (cabin enum and defaults, cities ordering, '000' overland marker, min/max items). The description only restates the gist ('give it the cities,' no dates or passenger details) and adds no syntax or format detail beyond the schema. 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?

States a specific verb and resource: 'Get a price range for a multi-city or round-the-world trip,' scoping it to a defined trip type rather than generic travel pricing. It does not explicitly name or contrast the sibling quote tools (fare_quote, itinerary_quote), so it falls short of full sibling differentiation.

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?

Gives a clear triggering condition: 'Use it when someone asks what a trip will cost and you don't have exact dates yet,' and reinforces it with 'needs no dates and no passenger details.' It does not explicitly name the alternative tools or say when NOT to use it beyond the live-quote contrast, so it stops short of a 5.

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