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

Annotations already cover readOnly, idempotent, and closed-world, so safety is not the description's burden. The description still adds real behavioral context the annotations cannot: results are drawn from a curated internal list rather than a live search, they are sorted nearest-first, and hotel_slug causes travel time to be included. That ordering and sourcing disclosure is what an agent needs to interpret the output.

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?

It is front-loaded with the core purpose and stays to one sentence, but that sentence is a long run-on that packs returned fields, area enums, and cross-tool IDs into a single clause chain. Some material (the field list, the area enum repetition) duplicates the schema and could be cut.

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 an output schema, full parameter coverage, and clear annotations, the description only needs to supply the framing: curated source, nearest-first ordering, and the pick_id link into plan_seattle_trip. It delivers all three, leaving only the default limit unmentioned in prose, which is minor given the schema carries it.

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 meal, near (with the same six areas and default), limit, and hotel_slug. The description restates the same area names and repeats the hotel_slug behavior ('with hotel_slug about how long it takes to get there') that the schema already states, adding no format or edge-case detail. Baseline 3 is warranted.

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 states a specific verb and resource ('Places to eat in Seattle') and constrains the source ('from the trip planner's own list'), which separates it from open-ended siblings like find_things_to_do and find_events_near. It also specifies ordering ('nearest first') and the meal/proximity axes, so an agent can tell what it returns 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?

Usage is implied through the meal and 'near' framing and through the cross-reference to plan_seattle_trip's picks, which tells the agent this is a discovery step feeding a larger itinerary. However, it never states when NOT to use it or names a competing sibling (e.g. find_things_to_do) for non-food options, so the guidance stops at implication.

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