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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds valuable non-obvious behavior: pagination is by page number (not offset), and the feed is sparse/inconsistent with empty results being normal. This beyond-annotation context helps an agent set expectations and handle responses correctly.

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 compact yet dense with information, front-loading the purpose and example before technical caveats. Each sentence serves a distinct purpose: what it does, what it returns, cross-reference to park codes, pagination behavior, and data quality warning. No wasted words.

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?

Given an output schema exists, the description need not explain return values. It covers all critical call-time concerns: how to specify parks/states, date range usage, pagination method, empty-result semantics, and cross-tool references. For a tool with 7 optional parameters and a mutual-exclusivity constraint, this is complete for correct 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 coverage is 100% with each parameter documented, so the baseline is 3. The description adds extra meaning beyond the schema: it clarifies the mutual exclusivity of parkCode and stateCode ('Provide parkCode or stateCode') and explains pagination semantics ('paginates by page number, not offset'). This directly aids correct invocation.

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 clearly states it finds scheduled events at a park within a date range, specifying event types (ranger programs, festivals, tours, interpretive events) and the exact answer it provides ('what's happening at Yellowstone this weekend?'). It distinguishes itself from sibling tools like alerts and campgrounds by the data it returns (title, dates, location, category, fee, registration links).

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?

It provides clear context for when to use the tool (e.g., 'what's happening at this park this weekend?') and explicitly instructs to get park codes from nps_find_parks. It also notes the events feed is sparser than alerts or campgrounds, implying alternative tools for those use cases, but does not explicitly say 'use nps_get_alerts for alerts' – leaving the differentiation slightly implicit.

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