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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description's job is context — and it delivers by disclosing the full inventory of metadata fields returned, plus an example payload, which lets an agent judge whether the call is worth making. It doesn't discuss failure behavior for unknown dataset_ids or response size, keeping it short of a 5.

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 highest-value information (what variables/fields you get), followed by a compact concrete example. The content list is dense but every item is informative; the only flaw is the missing verb that would make the opening sentence grammatical.

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 return structure needn't be explained, and the description nonetheless summarizes the payload's contents; annotations cover the safety profile and the single parameter is fully documented in schema. Nothing an agent needs in order to call this 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?

With 100% schema description coverage and a single required dataset_id that already carries examples ('nbm_conus', 'mrms_reflectivity_conus') and a pointer to list_datasets, the schema does the work. The description repeats the example value but adds no new semantics such as identifier stability or lookup behavior, so baseline 3 applies.

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 enumerates precisely what metadata is returned (variables with standard names/units/display units/categories/bands, horizon, step, cadence, freshness, cost class, plus an example_query), which is specific and distinguishable from the sibling query_dataset. It loses a point because it is written as a noun-phrase fragment with no leading verb ('Returns…'/'Describes…'), leaving the exact action slightly 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?

Usage is only implied: by naming 'example_query for query_dataset' it hints at the describe-then-query workflow, and the example call shows the shape of a correct invocation. There is no explicit statement of when to call this instead of list_datasets or query_dataset, and no exclusions or prerequisites are given in the description itself.

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