Weather — NOAA Conditions, Forecasts & History for AI Agents

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, but the description adds important context beyond them: it is a live NOAA proxy, nothing is stored, no API key is required, it returns the latest NWS gridpoint forecast, and an unknown location key or NOAA outage yields a source-unavailable error.

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 front-loaded with what the tool returns and how it differs from siblings, followed by concise behavioral and error notes. The density is appropriate for the amount of useful information, and no sentence is redundant.

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 compensates by naming the returned forecast fields: temperature, wind speed and direction, short and detailed forecast text, and day/night periods. It also covers source freshness and failure behavior, leaving nothing critical for an agent to infer before calling it.

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?

There is only one parameter and schema description coverage is 100%, so the schema already documents the location key, accepted values, and default. The description does not add additional syntax or selection guidance beyond the schema, which is acceptable at the baseline for fully covered parameters.

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 verb and resource: a NOAA forecast for an agricultural region, covering the next several day/night periods with named fields. It clearly distinguishes itself from get_weather and get_weather_history, so an agent can select it without opening sibling schemas.

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?

It explicitly says to use this tool for the outlook ahead, then names the alternatives get_weather for current observed conditions and get_weather_history for recent past weather. This is exactly the when-to-use versus when-not-to-use guidance an agent needs.

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 annotations (which already cover read-only, idempotent, open-world safety), the description discloses that this is a live proxy with no stored state, that values reflect the station's latest observation, that no API key is needed, and that an unknown location key or NOAA outage produces a source-unavailable error. That failure-mode and freshness information is exactly what annotations cannot convey.

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 compact clauses with zero filler: what it returns, when to use it, the alternatives, then the operational caveats. The core purpose and routing rule are front-loaded before the error behavior.

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 returned measurements and their source. Combined with the disclosed error conditions and freshness semantics, an agent has everything needed to call this correctly and interpret a failure.

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% and the single parameter already carries its default and accepted location keys, so the schema does the heavy lifting. The description adds only indirect semantics — that an unknown location key yields an error — without format or key guidance of its own, matching the baseline for high coverage.

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?

Names a specific verb and resource ('Current observed weather conditions for an agricultural region') and enumerates the returned fields — temperature, humidity, wind, sky conditions — with the data source (nearest NOAA NWS station). It also explicitly distinguishes itself from get_forecast and get_weather_history, so an agent can route correctly without opening any schema.

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?

States the selection rule directly: 'Use for right-now conditions; use get_forecast instead for the outlook ahead, and get_weather_history for what the past days actually delivered.' Both alternatives are named with the condition that selects them, leaving nothing to inference.

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?

Annotations already declare readOnly/idempotent/openWorld, but the description adds real operational context beyond them: a live proxy to NOAA with nothing stored and no API key. It also discloses two edge-case behaviors an agent cannot infer — precipitation is null (never silently zero) when a station reported no values, and days with no observations are omitted entirely.

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?

What it returns is front-loaded, then routing, then operational caveats — a logical order with no filler. Every clause carries information: units, null semantics, omission rule, default range.

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?

No output schema exists, but the description fully specifies the return shape (per-day high/low, precipitation, observation count) plus the null and omission edge cases. Nothing needed to call it correctly or interpret results 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% and both parameters are documented there, so the schema carries the load. The description restates the `days` span (1–30, default 7) but adds no syntax, format, or selection guidance for `location` beyond what the schema already lists; 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?

States a specific verb and resource — 'Recent past weather for an agricultural region, summarized by day from NOAA station observations' — and enumerates the returned fields (daily high/low °F, precipitation inches, observation count). It explicitly disambiguates from get_weather and get_forecast, so an agent can select it without opening schemas.

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?

'Use for what weather actually occurred over the past days; use get_weather instead for current conditions and get_forecast for the outlook' gives an explicit when-to-use plus named alternatives with the condition that selects each.

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