status.live campgrounds

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

Goes well beyond the readOnly/openWorld annotations: it discloses per-source freshness (Forest Service refreshed every 6 hours), that California State Parks supplies no status, that 'not listed' means unknown rather than closed, and licensing/attribution constraints. That is exactly the kind of trust-calibration context annotations can't carry.

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 core purpose and result fields, then the caveats; every sentence (including the licensing note) carries real information. Slightly dense for a single paragraph, but no 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 work of describing return values (distance, open today, booking link). Combined with the freshness and licensing caveats, an agent has everything needed to call and interpret the result correctly.

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 0%, so the description carries the burden. It clarifies lat/long as a point and links the output to open-today status, but never explains limit, max_km (the search radius), or the open_today_only filter — the three parameters most likely to be mis-set.

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 ('campgrounds nearest a latitude/longitude') and names the three source datasets, so the agent knows exactly what it retrieves. It distinguishes itself from campgrounds_search only implicitly, via the geo-radius framing, rather than naming the sibling outright.

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 'nearest a point' framing implies when to reach for it (a location-based lookup), but there is no explicit when-to-use/when-not or reference to campgrounds_search or campgrounds_get_status as alternatives. Usage must be inferred from the sibling names.

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

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

Beyond the readOnly/openWorld annotations, it discloses provenance per agency (NPS published schedule, Forest Service status refreshed every 6 hours, CA State Parks GIS with no opening status), the semantics of "not listed" (unknown, not closed), and licensing/attribution obligations with a link. That is exactly the extra context annotations cannot carry, including a real caveat about data reliability.

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 return contents, then the source caveats, then licensing — a sensible ordering with dense, low-waste sentences. The trailing attribution URL is necessary but makes the entry longer than ideal for a single-parameter lookup.

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?

There is no output schema, and the description compensates by enumerating the fields returned (status, season, booking method, fees, rules, official page, forecast). Combined with the per-agency freshness caveats and the unknown-vs-closed distinction, an agent has what it needs to call and interpret the result.

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?

Only one parameter and schema coverage is 100%, so the schema already documents "Campground id or name." The description largely restates that, adding just the example id format ("upper-pines"), which is a marginal gain over the schema.

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?

"One campground:" plus an enumeration of the returned facts (open today, season, booking method, fees, rules, page, forecast) is a specific verb-and-resource statement. It implicitly separates itself from the plural search/find siblings by the singular framing, but never names them, so the differentiation is inferred rather than explicit.

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 singular "One campground" framing and the id-example imply this is the detail lookup you call once you already know which campground you want, contrasting with the list-style siblings. However, no explicit when-to-use, when-not, or "use X instead for Y" routing is stated.

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

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.