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

Goes well beyond the readOnlyHint annotations: it explains per-source status semantics (NPS follows park schedule, Forest Service refreshed every 6 hours, CA State Parks GIS has no status), defines "not listed" as unknown rather than closed, and flags CA attribution and commercial-use permission requirements. Only the result-shape details and pagination behavior are left unexplained.

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 the searchable dimensions and the get_status handoff, which is the right ordering. The licensing sentence is long and run-on but is genuinely actionable information for a public-data source rather than filler.

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 no output schema, the description does the necessary work of stating what comes back: ids, today's open status, and a booking link. Combined with read-only annotations and the source-specific caveats, an agent has enough to call it correctly; only result limits/paging are unaddressed.

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 33%: only query is documented in the schema, and the description does expand it with useful accepted forms and examples ("Yosemite", "Shasta-Trinity", "CO"). But limit (default 25, max 100) and open_today_only get no explanation in either place, so coverage is not fully compensated.

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 (find) and resource (campgrounds) and enumerates the query dimensions: name, id, park/forest, or state, with examples. It also names the downstream sibling campgrounds_get_status. It never mentions campgrounds_find_near, so the split between text search and proximity search is left implicit.

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?

Implicit routing guidance is present: "Returns ids for campgrounds_get_status" tells the agent this is the lookup step before a status call. However, there is no explicit when-to-use versus campgrounds_find_near, and no statement about what to do if the query returns nothing.

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