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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description needn't restate safety. It instead adds behavioral semantics beyond the annotations: the meaning of backcountry_is_entry_date (sells an entry date, not nights) and DayUse in camp_types (parking slots, shuttle seats, daily vehicle permits). Return fields are covered by the output schema, so no credit needed there.

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-loaded with purpose and return shape, then a usage pointer, then two tightly scoped field-semantics notes. Every sentence carries information; the only mild cost is that the two trailing flag explanations are somewhat abruptly attached without connective framing.

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 and full annotation/schema coverage, the description supplies what structured fields cannot: how returned flags change downstream tool calls. Pagination behavior beyond the documented limit default is not addressed, which is a minor gap for a paginated search.

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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains that a DayUse value in camp_types indicates day-use inventory requiring day_use_cells, and that backcountry_is_entry_date changes alert semantics. That is semantic context the enum list alone does not convey.

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 ('Find parks by name') plus scope ('across every supported provider') and enumerates what distinguishes coverage (Canadian provincial/federal plus US Recreation.gov, UseDirect, AspiraOne). This separates it cleanly from get_park (by id) and list_park_campgrounds (per park).

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 clear downstream routing ('Use the returned park id with the other tools') and explicitly names which tools consume which field semantics (create_alert's entry_dates, day_use_cells). It does not explicitly say when to prefer this over get_park or list_park_campgrounds, so it stops short of full when/when-not guidance.

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