Skip to main content
Glama

nws-weather-mcp-server

by io.github.cyanheads

Nws Search Alerts

nws_search_alerts
Read-only

Search active weather alerts (watches, warnings, advisories) across the US. Filter by state, coordinates, zone, land/marine region, event type, severity, urgency, or certainty. area, point, zone, region_type, and region are mutually exclusive — provide at most one. Omit all filters for a national search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoUS state/territory code (e.g., "WA", "OK", "PR") or marine area code (e.g., "GM"). Mutually exclusive with point and zone.
zoneNoNWS forecast zone (e.g., "WAZ558") or county zone (e.g., "WAC033"). Mutually exclusive with area and point.
eventNoFilter to specific event types (e.g., ["Tornado Warning"]). Matches are case-insensitive and partial, so "tornado" matches both "Tornado Warning" and "Tornado Watch". Use nws_list_alert_types to discover valid names.
limitNoMaximum number of alerts to include in this page (1-25, default 25). totalCount still reports the full number of distinct matches, so a small limit returns a digest of broad or national searches without dropping the total; pass the returned nextCursor as cursor to reach the rest.
pointNoCoordinates as "lat,lon" (e.g., "47.6,-122.3"). Returns alerts whose geometry contains this point. Mutually exclusive with area and zone.
cursorNoOpaque continuation token from a previous response's nextCursor. Omit for the first page. The token carries its own page size, so limit applies to the first page only. Every call re-fetches /alerts/active, so alerts are contiguous within one response but not across calls — the active set changes continuously as alerts are issued and expire, so a continued page covers the collection as it stands at that moment.
regionNoRestrict to NWS marine region groups: "AL" (Alaska waters), "AT" (Atlantic Ocean), "GL" (Great Lakes), "GM" (Gulf of Mexico), "PA" (Eastern Pacific and US West Coast), "PI" (Central and Western Pacific). Marine alerts only — a land alert never matches. Mutually exclusive with area, point, zone, and region_type.
statusNoAlert status filter. Default "Actual". Use a different value only when you specifically need non-live alerts.Actual
urgencyNoFilter by urgency level.
severityNoFilter by severity level.
certaintyNoFilter by certainty level.
region_typeNoRestrict to land-based or marine alerts. Mutually exclusive with area, point, zone, and region.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
shownNoNumber of alerts included in this response
alertsNoMatching alerts for this page (at most the requested limit, max 25)
noticeNoGuidance when no alerts matched (echoes applied filters and suggests how to broaden), when matches remain beyond this page, or when the supplied cursor points past the end of the match set.
nextCursorNoOpaque token for the next page of matches — pass it back as `cursor`. Omitted when this is the last page.
totalCountNoTotal distinct alerts matching the filters in this fetch, before the page window is applied. NWS repeats some alerts verbatim within one response; the copies are collapsed on id, so this counts each alert once. Compare against shown to tell whether matches were withheld from this page.
appliedFiltersNoSummary of applied search filters

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description takes on the burden of behavioral detail. It discloses non-obvious behavior: case-insensitive/partial event matching, pagination mechanics (cursor carries its own page size, limit applies only to first page), and that each call re-fetches /alerts/active so results are contiguous within a response but not across calls. This is exactly the kind of context an agent needs.

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 but every sentence earns its place. The core purpose and filter list come first, followed by the mutual-exclusivity rule and the national-search fallback. It avoids repetition and packs the most critical operational details (pagination, event matching) into the schema descriptions, which is appropriate. Slight verbosity in listing every filter type, but it's a complex tool.

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?

With 12 optional parameters and an output schema, the description covers all necessary operational aspects: the search scope, how each filter works, mutual exclusivity, pagination, and how to handle the cursor. It cross-references nws_list_alert_types for event discovery, which closes a potential knowledge gap. Nothing an agent needs to call this correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds substantial value beyond the schema: clarification of event matching (case-insensitive, partial), the meaning of totalCount with small limits, the behavior of cursor tokens, and the interpretation of region codes. It also reinforces the mutual-exclusivity rule for the group of parameters. This transforms ambiguous filters into actionable guidance.

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?

Description opens with a specific verb+resource: "Search active weather alerts (watches, warnings, advisories) across the US." It immediately distinguishes the tool from siblings like nws_get_forecast or nws_get_observations. It also clearly enumerates filter dimensions, leaving no doubt about scope.

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?

Provides clear context: how to filter (state, coordinates, zone, etc.), states the mutual-exclusivity rule, and explicitly covers the national-search case ("Omit all filters"). It points to nws_list_alert_types for discovering valid event names. It doesn't explicitly name alternatives or say when not to use this tool, but the sibling tools are different enough that this is unnecessary.

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

All nws-weather-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/5.0
Disambiguation4/5

Each tool targets a distinct data product (stations, forecast, observations, office discussion, zone forecast, alert types, alerts). Forecast-related tools are clearly differentiated by granularity and purpose, though get_forecast and get_zone_forecast could be confused by users unfamiliar with NWS terminology.

Naming Consistency5/5

All tool names follow the consistent pattern nws_verb_noun in snake_case (e.g., find_stations, get_forecast, list_alert_types). This makes the API highly predictable and easy to navigate.

Tool Count5/5

Seven tools is well within the ideal 3-15 range for a weather-focused server. Each tool covers a major NWS data category without unnecessary redundancy, making the set feel tight and purposeful.

Completeness4/5

The tool set covers the core weather workflow: station discovery, observations, forecasts, zone text, office discussions, and alert searching. Minor gaps like marine-specific products or radar imagery exist, but the essential weather information needs are well covered.

Resources