noaa-climate-mcp-server
Server Details
Search NOAA climate stations and datasets, fetch historical weather observations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 7 of 7 tools scored.
Each tool has a clear, distinct purpose: listing datasets/categories/types for discovery, finding locations and stations, retrieving a single station's metadata, and fetching actual observation data. No overlap exists.
All tools follow the 'noaa_climate_<verb>_<noun>' pattern with consistent snake_case. Verbs (list, find, get, fetch) appropriately reflect the operation's nature.
7 tools cover the full data discovery and retrieval workflow for a climate data API without being excessive. Each tool contributes a necessary step in the pipeline.
The tools comprehensively cover the API surface: listing datasets, data categories, data types, searching locations and stations, fetching station metadata, and retrieving observation records. No obvious gaps for a read-only climate data service.
Available Tools
7 toolsnoaa_climate_fetch_dataFetch NOAA Climate Observation DataARead-onlyInspect
Fetch historical observation records from a NOAA CDO dataset for a given date range. Requires datasetId (e.g., GHCND for daily, GSOM for monthly), startDate, and endDate. Optionally scope to specific stations, locations, and data types. Date range limits per request: sub-daily and daily datasets (GHCND, PRECIP_15, PRECIP_HLY, NORMAL_DLY, NORMAL_HLY) are limited to 1 year; monthly and annual datasets (GSOM, GSOY, NORMAL_MLY, NORMAL_ANN) are limited to 10 years. For climate normals (NORMAL_*), use startDate=2010-01-01 and endDate=2010-12-31 — that is the API proxy year regardless of which 30-year period is being described. Returns flat tuples of { date, datatype, station, value, attributes }. Strongly recommended: pass units=metric or units=standard — without it, GHCND values are raw tenths-of-unit integers (TMAX=256 = 25.6°C, PRCP=12 = 1.2mm). GSOM/GSOY are already scaled.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records to return (1–1000). Defaults to 25. | |
| units | No | Unit system for returned values. Without this parameter, GHCND returns raw tenths-of-unit integers (TMAX=256 = 25.6°C). Strongly recommended: pass metric (SI units) or standard (Fahrenheit/inches). Optional. | |
| offset | No | Zero-based index of the first record to return for pagination. Defaults to 0. | |
| endDate | Yes | End date for observations (YYYY-MM-DD). Must be within 1 year of startDate for sub-daily/daily datasets (GHCND, PRECIP_15, PRECIP_HLY, NORMAL_DLY, NORMAL_HLY) or within 10 years for monthly/annual datasets (GSOM, GSOY, NORMAL_MLY, NORMAL_ANN). For any NORMAL_* dataset use 2010-12-31. | |
| datasetId | Yes | Dataset ID to query (e.g., GHCND for daily data, GSOM for monthly, GSOY for annual, NORMAL_DLY/MLY/ANN/HLY for 1981–2010 climate normals). Determines date range limit: GHCND/PRECIP_*/NORMAL_DLY/NORMAL_HLY allow 1-year max per request; GSOM/GSOY/NORMAL_MLY/NORMAL_ANN allow 10-year max. | |
| sortField | No | Sort results by this field. Optional. | |
| sortOrder | No | Sort direction. Optional; defaults to asc. | |
| startDate | Yes | Start date for observations (YYYY-MM-DD). For NORMAL_* datasets use 2010-01-01 regardless of the years being analyzed — 2010 is the API proxy year for all normals. | |
| stationId | No | One or more station IDs to filter by (e.g., ["GHCND:USC00450974"]). Obtain from noaa_climate_find_stations. Multiple IDs return comparative readings across stations. Optional. | |
| datatypeId | No | One or more data type IDs to include (e.g., ["TMAX", "TMIN", "PRCP"]). Without this, all data types for the dataset are returned. Use noaa_climate_list_data_types to discover valid IDs. Optional. | |
| locationId | No | One or more location IDs to filter by (e.g., ["FIPS:37", "ZIP:98101"]). Broader than stationId — returns data from all stations within the location. Optional. | |
| includemetadata | No | Include pagination metadata in the response. Defaults to true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no records were returned — echoes query parameters and suggests how to broaden. |
| results | Yes | Flat array of observation records sorted by date by default. |
| metadata | No | Pagination metadata. Present when includemetadata=true. |
| totalCount | Yes | Total number of matching observation records before the page limit. |
| effectiveQuery | Yes | Summary of the effective query: dataset, date range, units, and any station/location/datatype filters applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context beyond this: specific date range limits (1 year for daily, 10 years for monthly/annual), the proxy year constraint for normals (2010), and the raw value scaling issue ('TMAX=256 = 25.6°C'). No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the core purpose and required parameters, then detailing constraints and recommendations. It is somewhat long but every sentence adds value, with no tautology. Could be slightly more compact, but the complexity justifies the length.
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 12 parameters (3 required) and complex constraints, the description covers all essential aspects: date limits, normals proxy year, unit scaling, recommended parameter values, pagination, and return format (flat tuples). The presence of an output schema (not shown) reduces the need to detail return values further. The description is comprehensive.
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%, so baseline is 3. The description adds significant value beyond the schema: explains the impact of datasetId on date limits, provides explicit dates for normals, explains the units parameter's effect on raw values, and guides users to other tools for station/datatype IDs. This greatly enhances parameter understanding.
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 clearly states 'Fetch historical observation records from a NOAA CDO dataset for a given date range,' using a specific verb and resource. It also mentions the dataset ID, date range, and optional filters, distinguishing it from sibling tools that deal with stations, locations, or data type discovery.
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 usage context: requires datasetId, startDate, and endDate, and notes date range limits per dataset type. It references sibling tools for obtaining station IDs and data type IDs (e.g., 'Obtain from noaa_climate_find_stations'). However, it does not explicitly state when not to use this tool or alternative tools for non-data-fetching purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_climate_find_locationsFind NOAA Climate LocationsARead-onlyInspect
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. Use locationCategoryId=ST to list US states (51 entries — small enough to retrieve completely). Use locationCategoryId=CITY for cities (thousands of entries — use pagination and sortField=name to navigate alphabetically). The CDO API has no name-search parameter; to find a specific city, sort alphabetically with sortField=name and page through results. Location IDs: states as FIPS:37 (NC), cities as CITY:US530031, zip codes as ZIP:98101, countries as CNTRY:US. Obtain location IDs here, then pass them to noaa_climate_find_stations or noaa_climate_fetch_data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–1000). Defaults to 25. | |
| offset | No | Zero-based index of the first result to return for pagination. Defaults to 0. | |
| endDate | No | Filter to locations with data on or before this ISO date (YYYY-MM-DD). Optional. | |
| datasetId | No | Filter to locations covered by this dataset (e.g., "GHCND"). Optional. | |
| sortField | No | Sort results by this field. Use name with sortOrder=asc to browse alphabetically when searching for a specific city or location name. Optional. | |
| sortOrder | No | Sort direction. Optional; defaults to asc. | |
| startDate | No | Filter to locations with data on or after this ISO date (YYYY-MM-DD). Optional. | |
| datacategoryId | No | Filter to locations with this data category (e.g., "TEMP"). Optional. | |
| locationCategoryId | No | Category 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, CLIM_REG for NOAA climate regions, CLIM_DIV for climate divisions, HYD_ACC/HYD_CAT/HYD_REG/HYD_SUB for hydrological categories. Optional — omit to return all location types. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no locations matched — echoes applied filters and suggests how to broaden. |
| results | Yes | Matching locations. |
| metadata | No | Pagination metadata. Present when the API returns it. |
| totalCount | Yes | Total number of matching locations before the page limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and open-world. Description adds context: no name-search parameter, location ID formats, and pagination advice for large categories, enhancing behavioral understanding beyond 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?
Approximately 160 words, front-loaded with purpose and practical examples. Every sentence adds value without redundancy, making it efficient and effective.
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?
Given 9 optional parameters and a complex domain, the description covers categories, pagination, search strategy, and ties to sibling tools. Output schema likely details return format, so description is sufficiently complete.
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%, baseline 3. Description adds value by explaining specific category values (ST, CITY, etc.) and their cardinality, and suggesting sortField=name for alphabetical browsing, going beyond schema definitions.
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 clearly states it searches for geographic locations by category and returns location IDs for use in other tools. It distinguishes itself from sibling tools like noaa_climate_find_stations by focusing on location retrieval.
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?
Provides explicit guidance on using locationCategoryId=ST (small, retrieve completely) versus CITY (large, paginate), and advises alphabetical sorting for searching. Lacks explicit 'when not to use' but context from siblings implies it's for location needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_climate_find_stationsFind NOAA Climate StationsARead-onlyInspect
Search for weather observation stations by location, bounding box, dataset, and data type. Returns station IDs, names, coordinates, elevation, and data coverage dates. Filter by locationId (e.g., "FIPS:37" for all NC stations), extent (lat/lon bounding box), datasetId, datatypeId, and date range. Station IDs returned here are used as stationId in noaa_climate_fetch_data. A station must have data for the dataset and date range you want — filter by datasetId and startDate/endDate to ensure compatibility. Common station ID formats: GHCND:USC00450974, COOP:010008.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–1000). Defaults to 25. | |
| extent | No | Bounding box filter as "minLat,minLon,maxLat,maxLon" (e.g., "47.5,-122.4,47.7,-122.1" for central Seattle). Optional. | |
| offset | No | Zero-based index of the first result to return for pagination. Defaults to 0. | |
| endDate | No | Filter to stations with data on or before this ISO date (YYYY-MM-DD). Optional. | |
| datasetId | No | Filter to stations that have data in this dataset (e.g., "GHCND" for daily observations). Optional. | |
| sortField | No | Sort results by this field. Optional. | |
| sortOrder | No | Sort direction. Optional; defaults to asc. | |
| startDate | No | Filter to stations with data on or after this ISO date (YYYY-MM-DD). Optional. | |
| datatypeId | No | Filter to stations that record these data types (e.g., ["TMAX", "TMIN", "PRCP"]). Optional. | |
| locationId | No | Filter to stations within this location ID (e.g., "FIPS:37" for NC, "CITY:US530031" for Seattle). Obtain from noaa_climate_find_locations. Optional. | |
| datacategoryId | No | Filter to stations with data in this category (e.g., "TEMP"). Optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no stations matched — echoes applied filters and suggests how to broaden. |
| results | Yes | Matching stations. |
| metadata | No | Pagination metadata. Present when the API returns it. |
| totalCount | Yes | Total number of matching stations before the page limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open world. Description adds behavior context: stations must have data for dataset/dates to return results, and gives common station ID formats. No contradictions.
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?
Efficient ~100-word description. Front-loads the purpose, uses bullet-like structure with periods, no wasted words. Every sentence adds value.
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?
Given 11 parameters (0 required), output schema exists, and sibling tools, the description covers all key aspects: filters, usage flow, examples, and prerequisites for compatible data. Complete for a find tool.
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 has 100% coverage with descriptions, so baseline is 3. Description adds value with concrete examples (e.g., 'FIPS:37' for locationId, lat/lon for extent) and explains relationship to other tool 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 clearly states the tool searches for weather stations by various filters and lists return fields (IDs, names, coordinates, etc.). It distinguishes from siblings by specifying that station IDs are used in noaa_climate_fetch_data, and location IDs come from noaa_climate_find_locations.
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?
Provides good context: use this to find stations before fetching data, and filter by dataset/dates to ensure compatibility. Mentions where to get location IDs. Could be explicit about alternatives (e.g., when to use get_station instead), but overall strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_climate_get_stationGet NOAA Climate StationARead-onlyInspect
Fetch full metadata for a single weather station by its ID (e.g., "GHCND:USC00450974", "COOP:010008"). Returns name, coordinates, elevation, and the full date range for which data is available. Use when you have a station ID from noaa_climate_find_stations and want its complete details, or to verify a station before querying data.
| Name | Required | Description | Default |
|---|---|---|---|
| stationId | Yes | Station ID to fetch (e.g., "GHCND:USC00450974", "COOP:010008"). Obtain from noaa_climate_find_stations. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Station ID. |
| name | Yes | Station name. |
| maxdate | No | Latest date data is available at this station (YYYY-MM-DD). Omitted when not provided. |
| mindate | No | Earliest date data is available at this station (YYYY-MM-DD). Omitted when not provided. |
| latitude | No | Station latitude in decimal degrees. Omitted when not provided by the API. |
| elevation | No | Station elevation. Unit depends on elevationUnit. Omitted when not provided. |
| longitude | No | Station longitude in decimal degrees. Omitted when not provided by the API. |
| datacoverage | No | Fractional data coverage (0–1). Omitted when not provided by the API. |
| elevationUnit | No | Unit for elevation (e.g., "Meters"). Omitted when not provided. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is safe. The description adds specifics on returned fields (name, coordinates, elevation, date range), providing behavioral context beyond annotations. No contradictions.
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?
Two sentences, front-loaded with action and examples. Extremely concise with no wasted words.
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?
Given the tool's simplicity (one required param, output schema exists, annotations provided), the description fully covers purpose, usage, and output. A complete and self-contained entry.
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% with a detailed parameter description including examples and source. The tool description repeats examples but adds little new semantic value. Baseline 3 is appropriate as schema does the heavy lifting.
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 clearly states the tool fetches full metadata for a single weather station by ID, with specific examples. It distinguishes from sibling tools like noaa_climate_find_stations by focusing on retrieving details of one station.
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 advises using this tool after obtaining a station ID from noaa_climate_find_stations, and for verifying a station before data queries. It implicitly indicates not to use it without an ID, but does not explicitly list alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_climate_list_data_categoriesList NOAA Climate Data CategoriesARead-onlyInspect
List data categories that group related data types — Temperature, Precipitation, Wind, Pressure, Sunshine, Sky cover, Weather Type, and more. Use to discover what types of measurements are available before calling noaa_climate_list_data_types. Optionally filter by dataset, location, station, or date range. There are 42 categories in total.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–1000). Defaults to 25. | |
| offset | No | Zero-based index of the first result to return for pagination. Defaults to 0. | |
| endDate | No | Filter to categories with data on or before this ISO date (YYYY-MM-DD). Optional. | |
| datasetId | No | Filter to categories available in this dataset (e.g., "GHCND", "GSOM"). Optional. | |
| sortField | No | Sort results by this field. Optional. | |
| sortOrder | No | Sort direction. Optional; defaults to asc. | |
| startDate | No | Filter to categories with data on or after this ISO date (YYYY-MM-DD). Optional. | |
| stationId | No | Filter to categories available at this station ID. Optional. | |
| locationId | No | Filter to categories available at this location ID. Optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no data categories matched — echoes applied filters and suggests how to broaden. |
| results | Yes | Matching data categories. |
| metadata | No | Pagination metadata. Present when the API returns it. |
| totalCount | Yes | Total number of matching data categories before the page limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds behavioral context: mentions total count (42 categories) and provides examples of category types. No contradiction. Adequate for a read-only listing tool.
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?
Two sentences, front-loaded with purpose and examples, then usage hint and total count. No unnecessary words; each sentence adds value.
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 output schema (not shown but present) and full schema coverage, description adds useful context (total count, typical usage flow). Could mention output fields briefly, but not essential. Overall complete for the tool's simplicity.
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 covers all 9 parameters with descriptions (100% coverage). Description merely summarizes optional filters without adding new semantic detail beyond grouping concepts. Baseline of 3 is appropriate.
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?
Description clearly states the verb ('list'), resource ('data categories'), and purpose ('discover what types of measurements are available'). It provides concrete examples (Temperature, Precipitation, etc.) and distinguishes from sibling tool noaa_climate_list_data_types by positioning it as a prerequisite.
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?
Explicitly states to use before noaa_climate_list_data_types, giving clear context. Lists optional filters (dataset, location, station, date range). Lacks explicit 'when not to use' or alternatives, but the guidance is sufficient for the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_climate_list_datasetsList NOAA Climate DatasetsARead-onlyInspect
List available NOAA CDO datasets with their IDs, names, and temporal coverage. Returns all ~11 datasets by default (no required parameters). Optionally filter to datasets that contain a specific data type, cover a location or station, or overlap a date range. Common datasets: GHCND (daily observations, 1763–present), GSOM (monthly summaries), GSOY (annual summaries), NORMAL_DLY/MLY/ANN/HLY (1981–2010 climate normals). Use this first to discover available datasets before calling noaa_climate_fetch_data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–1000). Defaults to 25. | |
| offset | No | Zero-based index of the first result to return for pagination. Defaults to 0. | |
| endDate | No | Filter to datasets with data on or before this ISO date (YYYY-MM-DD). Optional. | |
| sortField | No | Sort results by this field. Optional. | |
| sortOrder | No | Sort direction. Optional; defaults to asc. | |
| startDate | No | Filter to datasets with data on or after this ISO date (YYYY-MM-DD). Optional. | |
| stationId | No | Filter to datasets covering this station ID (e.g., "GHCND:USC00450974"). Optional. | |
| datatypeId | No | Filter to datasets containing these data type IDs (e.g., ["TMAX", "PRCP"]). Optional. | |
| locationId | No | Filter to datasets covering this location ID (e.g., "FIPS:37" for NC). Optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no datasets matched — echoes applied filters and suggests how to broaden. |
| results | Yes | Matching datasets. |
| metadata | No | Pagination metadata. Present when the API returns it. |
| totalCount | Yes | Total number of matching datasets before the page limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only. Description adds context about default return set and common dataset examples, but lacks pagination details.
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, each purposeful: purpose, default, filters, usage guidance. No redundancy.
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?
Output schema exists, so no need to describe returns. Description covers purpose, filters, common datasets, and usage order with siblings. Adequate for tool complexity.
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 has 100% parameter coverage, so baseline 3. Description adds value by grouping filter options and giving examples like datatypeId and locationId.
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?
Description clearly states it lists NOAA CDO datasets with IDs, names, temporal coverage, and distinguishes it from siblings by suggesting using it first before fetching data.
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?
Explicitly states default behavior (no required parameters, returns all ~11 datasets), optional filters, and when to use (discover datasets before calling noaa_climate_fetch_data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_climate_list_data_typesList NOAA Climate Data TypesARead-onlyInspect
List available data types (measurement labels like TMAX, TMIN, PRCP, SNOW) for a given dataset or category. Pass a datasetId to see what is measured in that dataset, or a datacategoryId (e.g., "TEMP") to see all temperature-related types. Hundreds of types exist across all datasets. Use this before calling noaa_climate_fetch_data when the data type IDs are unknown. Common GHCND types: TMAX (max temperature), TMIN (min temperature), PRCP (precipitation), SNOW (snowfall), SNWD (snow depth), AWND (average wind speed).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–1000). Defaults to 25. | |
| offset | No | Zero-based index of the first result to return for pagination. Defaults to 0. | |
| endDate | No | Filter to data types with data on or before this ISO date (YYYY-MM-DD). Optional. | |
| datasetId | No | Filter to data types available in this dataset (e.g., "GHCND", "GSOM"). Optional. | |
| sortField | No | Sort results by this field. Optional. | |
| sortOrder | No | Sort direction. Optional; defaults to asc. | |
| startDate | No | Filter to data types with data on or after this ISO date (YYYY-MM-DD). Optional. | |
| stationId | No | Filter to data types available at this station ID. Optional. | |
| locationId | No | Filter to data types available at this location ID. Optional. | |
| datacategoryId | No | Filter to data types in this category (e.g., "TEMP" for temperature types, "PRCP" for precipitation). Optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no data types matched — echoes applied filters and suggests how to broaden. |
| results | Yes | Matching data types. |
| metadata | No | Pagination metadata. Present when the API returns it. |
| totalCount | Yes | Total number of matching data types before the page limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's read-only nature is redundant. Description adds that 'Hundreds of types exist across all datasets,' implying pagination may be needed, but no additional behavioral traits beyond standard listing.
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?
Two sentences plus a compact list of common types. No redundant information; each sentence serves a clear purpose. Front-loaded with the tool's core function.
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?
Output schema exists (not shown) so return values are covered. Description explains the tool's role and filtering, though it doesn't explicitly discuss pagination limits but schema does. Sufficient for a listing tool.
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%, so baseline 3. Description adds value by explaining datacategoryId with example 'TEMP' and listing common GHCND types, which aids understanding beyond the schema's field descriptions.
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 clearly states the tool lists available data types (measurement labels) for a given dataset or category, with specific examples like TMAX and PRCP. It is distinct from sibling tools like noaa_climate_fetch_data, which fetches actual data.
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?
Explicitly advises using this tool before noaa_climate_fetch_data when data type IDs are unknown. Provides filtering guidance (datasetId, datacategoryId) and examples, but no explicit when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!