nws-weather-mcp-server

Nws Get Alert Counts

nws_get_alert_counts

Read-only

Count active weather alerts nationwide, per state/territory or marine area, and per marine region, in one small response — the answer to "how many alerts are active, and where" without fetching the alerts themselves. Counts cover every message status, Test and Exercise included, so totalAlerts can run above the totalCount a national nws_search_alerts search reports under its default status of Actual. An alert counts once in each area its zones fall in, so the area counts can sum past totalAlerts; landAlerts plus marineAlerts equals totalAlerts. Takes no filters. For counts per zone or under a filter, call nws_search_alerts with that zone or filter and read its totalCount.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`areas`	No	Active alert counts keyed by state/territory code (e.g., "WA", "PR") or marine area code (e.g., "PZ", "GM"). Only areas with an active alert appear. An alert counts once in each area its zones fall in, so these can sum past totalAlerts. Area "AL" is Alabama; Alaska waters are region "AL" in regions.
`error`	No	Present when the call failed. Absent on success.
`regions`	No	Active marine alert counts keyed by marine region: "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). Only regions with an active alert appear, so the map is empty when no marine alert is active.
`landAlerts`	No	Active alerts affecting land zones.
`totalAlerts`	No	Active alerts nationwide across every message status (Actual, Exercise, System, Test, Draft). Can exceed the totalCount of a national nws_search_alerts search, which counts status Actual by default.
`marineAlerts`	No	Active alerts affecting marine zones. landAlerts + marineAlerts = totalAlerts.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 30, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true. The description adds substantial behavioral context beyond that: counts include every message status including Test and Exercise, so totalAlerts can exceed nws_search_alerts' default Actual totalCount; area counts can sum past totalAlerts because an alert counts once per area its zones fall in; and landAlerts plus marineAlerts equals totalAlerts. This is rich, non-obvious operational detail.

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 definition is dense but front-loaded: the first sentence states purpose, scope, and output size. Subsequent sentences explain non-obvious count semantics and route the agent to the sibling tool for filtered cases. Every sentence adds distinct value with 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?

An output schema exists, so the description need not document return fields. Given the tool takes no parameters, the description covers everything an agent needs: what it counts, what is included, how counts relate to nws_search_alerts, and when to use the alternative.

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

Parameters4/5

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

There are no parameters, so the schema is empty and the baseline is 4. The description reinforces this with 'Takes no filters,' which is useful but consistent with the empty schema and additionalProperties=false.

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 states a specific verb and resource: 'Count active weather alerts nationwide, per state/territory or marine area, and per marine region, in one small response.' It distinguishes itself from siblings by specifying that it answers 'how many alerts are active, and where' without fetching the alerts themselves, and it explicitly points to nws_search_alerts for filtered counts.

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?

It gives explicit when-to-use guidance ('the answer to ... without fetching the alerts themselves') and when-not/alternative guidance ('Takes no filters. For counts per zone or under a filter, call nws_search_alerts with that zone or filter and read its totalCount'). An agent knows exactly which tool to choose and when.

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.