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

Annotations (readOnlyHint=true, openWorldHint=true) already establish the safety profile; the description goes well beyond this. It discloses ordering ('most-recent-first'), the exact semantics of empty results vs. empty pages ('An empty page with a non-zero totalCount only means start ran past the end'), the local-filter behavior of category, and a real-world caveat ('Closures and road conditions change daily — re-check before departure'). No contradiction with annotations — the read-only, open-world hints align perfectly with the described behavior.

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 main purpose is front-loaded in the first sentence with the key use-case poised as a question. The three sentences each earn their place: purpose+recency priority, usage routing, and output semantics. Dense but not bloated for a 6-parameter tool with non-trivial pagination and filtering semantics. Slightly compresses the category-local-filter detail into the schema, which keeps the main description lean.

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?

An output schema exists, so no obligation to explain return values. The description covers purpose, input routing (park vs. state, service-wide fallback), result interpretation (empty = good news vs. empty page = pagination overrun), recency ordering, and a freshness warning. For a tool with this complexity — 6 params, pagination, local filtering, cross-tool dependency — nothing an agent needs to call it correctly is missing.

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% (all 6 params described in schema with enums and defaults), so baseline is 3. The description adds real value beyond schema: it ranks category values ('Danger' and 'Park Closure' are the high-priority ones), explains that category filtering is applied locally vs. API-native, explains the meaning of totalCount under local filtering, and provides the nps_find_parks cross-reference for parkCode. This meaningful interpretation pushes it above baseline.

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?

Specific verb ('get alerts') + resource (NPS alerts) + explicit scope ('for a park or a whole state') with the alert types enumerated (closures, hazards, caution notices, information). The sibling set (campgrounds, events, parks, activities) contains no alert tool, so the domain is auto-differentiated, and the description reinforces this by naming the exact resource. No ambiguity in what this tool does.

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?

Provides clear when-to-use context: 'Get park codes from nps_find_parks, or pass a stateCode for a statewide sweep' names the concrete alternative for obtaining input. It also tells the agent how to interpret outcomes ('an empty result with totalCount 0 means... good news, not an error'), which guides decision-making. It doesn't explicitly state when NOT to use this tool versus an alternative, but sibling domains are separated so cleanly by topic that explicit exclusions would be redundant.

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