inspect_coverage

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

No annotations are provided, so the description carries the full burden. 'Resolve a station' implies it maps/resolves identifiers, and 'reports documented temporal coverage' describes output, but it does not mention whether this is a read-only operation, any rate limits, or what happens with unresolvable stations. No schema values (defaults like metric and data_type) are explained in behavioral terms.

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 a single concise sentence with no wasted words. It front-loads the core action and purpose. However, it is slightly under-specified—conciseness here borders on sparse rather than optimally economical given the amount of missing behavioral detail.

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?

While an output schema exists (mitigating the need to describe return values), the tool has 3 parameters with 0% schema coverage, no annotations, and a purpose that is central to workflow sequencing ('before querying'). The description should clarify what 'temporal coverage' reporting entails, how metric and data_type influence it, and what distinguishes this from discover_datasets/describe_dataset. It leaves significant gaps.

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%, and the description mentions the station parameter implicitly (resolving a station) but provides no semantics for 'metric' (default water-level) or 'data_type' (default operational). The description does not explain what these parameters mean or how they affect the coverage report. With zero schema coverage and no param description, compensation is absent.

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 states a specific action ('Resolve a station and report documented temporal coverage before querying'). This clearly indicates the tool resolves a station identifier and reports its temporal coverage. It distinguishes reasonably from siblings like describe_dataset and discover_datasets, though it doesn't explicitly name alternatives.

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 phrase 'before querying' implies it should be used as a prerequisite to data queries, but this is subtle and not explicit. It does not state when to use this vs alternatives like describe_dataset or discover_datasets, nor does it specify exclusions or prerequisites beyond the implied sequencing.

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