Skip to main content
Glama

noaa-climate-mcp-server

by io.github.cyanheads

Find NOAA Climate Locations

noaa_climate_find_locations
Read-only

Search for geographic locations by category (CITY, ST, CNTY, CNTRY, ZIP, CLIM_REG, etc.). Returns location IDs used in station search and data queries. Without locationCategoryId, returns all location types; noaa_climate_list_location_categories lists the valid values. Use locationCategoryId=ST to list US states (51 entries — small enough to retrieve completely). To find a location by name, pass nameContains alongside locationCategoryId — the CDO API has no name parameter, so this server enumerates the category and matches the substring itself. It works for any category under the size limit stated on nameContains, which is every category except ZIP; a datasetId or datacategoryId filter can bring a category back under that limit. For a category still too large, sort alphabetically with sortField=name and page through results. Location IDs: states as FIPS:37 (NC), cities as CITY:US530018 (Seattle), zip codes as ZIP:98101, countries as FIPS:US. Obtain location IDs here, then pass them to noaa_climate_find_stations or noaa_climate_fetch_data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (1–1000). Defaults to 25.
offsetNoZero-based index of the first result to return for pagination. Defaults to 0.
endDateNoFilter to locations with data on or before this ISO date (YYYY-MM-DD). Optional.
datasetIdNoFilter to locations covered by this dataset (e.g., "GHCND"). Optional.
sortFieldNoSort results by this field. Use name with sortOrder=asc to browse alphabetically when searching for a specific city or location name. Optional.
sortOrderNoSort direction. Optional; defaults to asc.
startDateNoFilter to locations with data on or after this ISO date (YYYY-MM-DD). Optional.
nameContainsNoCase-insensitive substring match on the location name. The CDO API has no name parameter, so this server applies the match itself, across the whole category rather than one page — which bounds it to a category holding at most 4000 locations. Requires locationCategoryId; adding datasetId or datacategoryId narrows a category that is otherwise too large. Example: locationCategoryId="CITY" with nameContains="seattle". Optional.
datacategoryIdNoFilter to locations with this data category (e.g., "TEMP"). Optional.
locationCategoryIdNoCategory filter. Use ST for states (51 entries), CNTY for counties, CITY for cities (large set — thousands of entries), CNTRY for countries, ZIP for zip codes, US_TERR for US territories, CLIM_REG for NOAA climate regions, CLIM_DIV for climate divisions, HYD_ACC/HYD_CAT/HYD_REG/HYD_SUB for hydrological categories. Call noaa_climate_list_location_categories when you do not know which category to use — it returns the authoritative set. Optional — omit to return all location types.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no locations matched — echoes applied filters and suggests how to broaden.
resultsNoMatching locations.
metadataNoPagination metadata. Present when the API returns it.
exhaustedNoTrue when the requested offset is past the end of a non-empty result set — the page is empty but matches exist. Omitted otherwise.
totalCountNoTotal number of matching locations before the page limit.
appliedNameFilterNoThe nameContains value this response was filtered by. Present only when nameContains was supplied; every count below then describes the filtered set, not the whole category.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, so safety is covered structurally, but the description adds genuinely non-obvious behavior: the CDO API exposes no name parameter, so this server enumerates the category and performs substring matching itself; the 4000-location bound on that behavior; and the fact that datasetId/datacategoryId can shrink an oversized category back under the limit. This mechanical disclosure goes well beyond what the annotations convey. No contradiction with annotations.

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?

The description is long, running as a single dense paragraph, but every sentence earns its place — purpose, category enumeration, naming workaround, size limits, pagination fallback, ID formats, downstream routing. Information density is high and the purpose is front-loaded before implementation details. It could be tightened into structured bullets, which costs it one point, but there is no filler.

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 10-parameter lookup tool with output schema and openWorldHint, the description covers everything needed to call it correctly: the search mechanism, the nameContains workaround and its bound, category sizes, sort/pagination fallback for oversized categories, and explicit routing of results to downstream tools. Potential failure modes (oversized categories) are anticipated with concrete mitigations. Nothing an agent needs is missing.

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?

Though schema coverage is 100% (baseline 3), the description adds substantial meaning the schema lacks: worked location-ID formats (FIPS:37 for NC, CITY:US530018 for Seattle, ZIP:98101, FIPS:US), the enumeration/size-limit mechanics behind nameContains, and concrete category semantics (ST=51 entries, CITY=thousands, ZIP). These worked examples and behavioral notes materially improve the agent's ability to construct correct parameter values.

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 opens with a specific verb+resource combination — 'Search for geographic locations by category' — and immediately states the tool's actual purpose: returning location IDs that feed into station search and data queries. It distinguishes itself from siblings by name (noaa_climate_find_stations, noaa_climate_fetch_data) and by its role as the upstream ID lookup step. No ambiguity remains about what this tool does or how it fits the workflow.

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

Usage Guidelines5/5

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

Provides explicit, actionable guidance: use locationCategoryId=ST to list US states (with the 51-entry size note), pass nameContains alongside locationCategoryId to find by name, and route to noaa_climate_list_location_categories when the category is unknown. It even gives a fallback strategy ('sort alphabetically with sortField=name and page through results') for oversized categories. Usage conditions and alternatives are named directly rather than left to inference.

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

All noaa-climate-mcp-server toolsInspect
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.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching data, searching locations, searching stations, getting station metadata, listing categories/datasets/types, and listing location categories. No two tools overlap; an agent can easily select the correct one based on the task.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: fetch_data, find_locations, find_stations, get_station, list_data_categories, list_datasets, list_data_types, list_location_categories. The verbs (fetch, find, get, list) are semantically appropriate and predictable.

Tool Count5/5

With 8 tools, the server is well-scoped for a climate data API. It covers the essential discovery and retrieval workflow without unnecessary bloat. Each tool serves a clear role in fetching or finding climate data elements.

Completeness5/5

The tool set provides a complete workflow: discover datasets, data categories, data types, location categories, find locations, find stations, get station metadata, and fetch observation data. There are no obvious gaps for the stated purpose of accessing NOAA climate data.

Resources