NOAA Climate Data

get_climate_normals

Get 30-year climate normal values for a NOAA weather station.

Climate normals are averages computed over the most recent 30-year period
(currently 1991-2020). They represent typical conditions for a location
and are useful for comparing current conditions to historical baselines.

Args:
    station_id: NOAA station identifier (e.g. 'GHCND:USW00094728').
                Use find_stations to look up station IDs.
    data_types: Comma-separated normal data type IDs to filter. Common types:
                DLY-TMAX-NORMAL (avg daily max temp), DLY-TMIN-NORMAL (avg daily min temp),
                DLY-TAVG-NORMAL (avg daily temp), DLY-PRCP-PCTALL-GE001HI (precip probability),
                MTD-PRCP-NORMAL (monthly precip), ANN-TMAX-NORMAL (annual max temp).
                If omitted, all available normals are returned.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`data_types`	No
`station_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the transparency burden. It discloses that normals are based on the 1991-2020 period and notes default behavior when data_types is omitted. However, it does not mention potential limitations, units, or response characteristics, leaving some behavioral aspects undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a brief overview followed by an Args section. Every sentence adds value, including the definition, usage context, and parameter guidance, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two parameters and an output schema present, the description provides sufficient context: what the tool returns, how to specify parameters, and how to find station IDs. No further details are needed for effective invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no property descriptions (0% coverage), so the description fully compensates. It specifies station_id format with an example, explains data_types as comma-separated IDs, lists common type examples, and states the default behavior when omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Get 30-year climate normal values for a NOAA weather station,' using a specific verb and resource. It differentiates from siblings by emphasizing 'normal values' and the 30-year period, which is distinct from find_stations and get_climate_data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when climate normals are useful ('useful for comparing current conditions to historical baselines') and directs users to use find_stations to look up station IDs. It lacks explicit exclusion of get_climate_data, but the context makes the appropriate use case clear.

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

All NOAA Climate Data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct role: station discovery, historical data retrieval, and normals retrieval. The descriptions clearly differentiate the two data retrieval tools by their outputs and parameters. No overlap would cause misselection.

Naming Consistency5/5

All three tools follow a consistent verb_noun pattern with snake_case. The verbs find and get are both appropriate for retrieval actions and follow a clear convention.

Tool Count5/5

With only 3 tools, the server is tightly focused on its purpose. Each tool is necessary and the count is within the natural range for a small domain-specific server.

Completeness4/5

The core workflow of finding stations and retrieving climate data or normals is covered. Minor gaps include no tool for listing available datasets or data types, but the provided examples make the surface workable.

Resources

Need Help?