Skip to main content
Glama

Noaa Ghcnd Daily

noaa_ghcnd_daily
Read-onlyIdempotent

Fetch daily weather station observations from NOAA GHCND by station ID and date range, with pagination for large result sets.

Instructions

Fetch a page of NOAA GHCND daily station observations.

The token is resolved from the credential reference this package declares (WORLD_REFERENCE_NOAA_TOKEN, env:// by default) — never accepted as a tool argument.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
end_dateYes
start_dateYes
station_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.4

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuinely non-derivable context: the API token is resolved from a declared credential reference (`WORLD_REFERENCE_NOAA_TOKEN`, `env://` by default) and is never a tool argument, which prevents an agent from trying to pass auth. It does not mention rate limits, error modes, or pagination termination.

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

Conciseness4/5

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

Two short paragraphs, purpose front-loaded, no filler. The credential sentence is somewhat verbose with its backticked env-var names but each sentence conveys needed information.

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

Completeness2/5

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

An output schema exists, so return values need not be explained, and auth is handled. But for a tool with three required string parameters at 0% schema coverage, the description should at minimum pin down station identifier and date formats; without that an agent can easily construct an invalid call.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters, so the description carries the full burden and adds almost nothing. It never states the expected station_id format (e.g. USC00306362) or the date format for start_date/end_date, and limit/offset are only obliquely implied by 'a page'.

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

Purpose4/5

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

States a specific verb and resource: fetch a page of NOAA GHCND daily station observations. It is clear what data comes back, but it offers no differentiation from the nearest sibling, open_meteo_weather_observation, so an agent choosing between weather-observation sources gets no help.

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

Usage Guidelines2/5

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

There is no statement of when to prefer this source over open_meteo_weather_observation or the other search tools, and no prerequisites or exclusions. The word 'page' hints at pagination but gives no guidance on how to size or walk pages.

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