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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description's additional disclosure of ranking behavior ('by soonest opening, or by drive time from a city') is genuinely useful context. It adds behavioral meaning about ordering and scope beyond what the annotations provide, though it does not describe edge cases like empty results or how confirming availability works.

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 three sentences, front-loads the core purpose and scope, and every sentence earns its place: definition, example usages, and sibling routing. There is no filler or redundancy.

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?

For a read-only, optional-parameter discovery tool, the description gives the essential selection context, example invocations, ranking semantics, and explicit alternatives for named parks. The schema handles the remaining parameter details, and annotations cover the safety profile, so nothing critical is missing for correct selection and invocation.

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 90%, so the schema carries most parameter documentation. The description supplements it by tying ranking intent to parameters such as near_city and start_date, and the example queries imply how region/weekend/near_city should be populated. This adds meaning beyond raw parameter definitions.

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 specifies a precise verb and resource: find parks that have an opening for a stay, ranked by soonest opening or drive time. It clearly scopes the tool to cases where the user has not named a park, which immediately distinguishes it from the named-park siblings without needing to inspect their schemas.

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 an explicit trigger condition ('when the user has not named a park'), concrete example queries ('where can I camp this weekend', 'anything near Vancouver with space'), and explicitly routes named-park requests to parksopen_search_campsites or parksopen_park_availability_calendar. This leaves no ambiguity about when to choose this tool.

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