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

Annotations already declare readOnly, openWorld, and idempotent hints, so the safety profile is covered. The description adds valuable context beyond annotations: US-centric coverage (NWS Aviation Weather Center), that it reads only the domestic SIGMET feed, the rejection behavior for AIRMET requests, and that empty results are normal. These details help an agent interpret behavior without contradicting the annotations.

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?

Four sentences, ~60 words, front-loaded with the core action and scope. It efficiently packs the return fields, coverage limitation, rejection behavior, and result normalization into a compact, readable description with no fluff or repetition.

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?

The tool has three optional params, a nested bbox object, and an explicit output schema (present). The description covers the return fields, geographic scope, feed limitations, and edge cases (empty results). Given the output schema exists to detail return structure, nothing an agent needs 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?

Schema description coverage is 100%, with each parameter documented in the schema, including detailed enum semantics (e.g., why MTN OBSCN and LLWS are rejected, what advisory_type 'airmet' does). The description only lists the filter options without adding new meaning. Baseline 3 is appropriate because the schema carries the semantic load.

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 opens with a specific verb and resource: 'Get active domestic SIGMETs for a region.' It clearly states the scope (domestic SIGMETs) and enumerates returned fields (hazard type, severity, altitude range, valid period, polygon coordinates, raw text). This distinguishes it from the sibling tools (e.g., METAR, TAF, PIREPs, stations) by focusing exclusively on advisories.

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 description provides explicit when-not guidance: it cannot return an AIRMET and rejects such requests. It also clarifies that empty results are normal during fair weather, which sets expectations. It mentions 'Filter by advisory_type, hazard, or bbox' but does not name alternative tools for AIRMETs; however, the sibling list contains no AIRMET tool, so the exclusion is contextual enough. Lacks a direct 'use this when you need SIGMETs' statement but that is strongly implied.

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