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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the NBM source, that p50/p90/p10 should be reported together rather than singly, and a genuine limitation (NBM has no tornado, hail or damaging-wind probabilities). It stops short of noting any latency, rate-limit, or update-cadence behavior, so not 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 purpose, then interpretation rules, then the aspect catalog, then examples – a sensible order with no filler sentences. The aspect enumeration is dense and pushes the block long, but each clause carries information an agent needs to select the right aspect.

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-format explanation is unnecessary, and the description still covers everything else: when to reach for it, how to read the percentiles, what each aspect yields, and where the data falls short. Nothing needed to invoke 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%, but the description goes well past the field names: every value of the required `aspect` enum is explained in terms of what it actually returns (PoP/QPF, snow-level and >1/2/4in probabilities, CWASP semantics, LIFR/IFR/MVFR, stddev). It also supplies worked call examples that clarify the location-vs-lat/lon choice.

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+resource (probabilistic NBM forecast distribution) and immediately scopes it to percentile ranges, exceedance probabilities and ensemble spread. It explicitly distinguishes itself from the deterministic sibling by saying a deterministic forecast value cannot answer these questions, and it carves out the severe-hazard case to get_outlooks.

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?

Gives explicit triggering conditions ('any question about odds, ranges, potential or confidence') with quoted user phrasings, and names the alternative for one sub-case ('use get_outlooks hazard=severe for SPC's'). When-to-use, when-not, and alternatives are all present.

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