mcp-weather-server
Summary: A read-only MCP server exposing US National Weather Service alerts and forecasts.
Fetch active weather alerts for a US state via
get-alerts, given a two-letter state code.Fetch the next five forecast periods for a US location via
get-forecast, given latitude and longitude.Return structured alert details (event, area, severity, description, instructions) and forecast details (period name, temperature/unit, wind speed/direction, detailed forecast).
Run locally for free over stdio with no API key, or use the hosted per-call endpoint.
Handle failures as tool results, use a 10-second upstream timeout, and replace missing NWS fields with
Unknownrather thannull.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-weather-serverwhat's the forecast for 37.7749,-122.4194?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Weather Server — US alerts and forecasts for AI agents
A minimal Model Context Protocol server that exposes US weather data from the National Weather Service API as two read-only tools.
The NWS API is free, keyless and US-only, so this server needs no credentials and no account to run.
Tool | Input | Returns |
|
| Active weather alerts for that state |
|
| The next five forecast periods for that point |
Both tools are annotated readOnlyHint: true and destructiveHint: false, so a
host that respects tool annotations can invoke them without asking first. Both
reach out to api.weather.gov and are marked openWorldHint: true for that reason.
Use it hosted, paid per call
Running it yourself costs nothing. There is also a hosted version, paid per call in USDC on Base over x402, for agents that would rather not carry a Node process and a data layer:
https://agent-evidence.thx93.dev/weather/mcpIt serves the same two tools, with the same output schemas and the same null
fallbacks, plus a free health tool and free tools/list so the service can be
discovered and probed before paying. Discovery is free; a tools/call for
get-alerts or get-forecast returns 402 with the price. Both are declared
read-only, so a host that respects annotations will not ask twice.
The server.json in this repository advertises that remote, so an MCP client can
install it by registry name rather than by cloning anything.
Related MCP server: Weather MCP Server
Prerequisites
Node.js 24+
npm
Build, test and run
npm install
npm test # builds, then runs the suite
npm run build # compile only
node build/index.jsThe suite drives the real server over InMemoryTransport with the NWS API stubbed,
so npm test touches no network and needs no credentials. It covers tool
discovery and annotations, the get-alerts and get-forecast data paths, the
fallbacks for fields the NWS sends as null, the failure contract, and input
validation.
Running node build/index.js speaks the MCP protocol over stdio: it prints to
stderr and waits for a client on stdin, so it is meant to be launched by a host
rather than by hand.
Adding it to a client
Most MCP hosts use the same three-line shape:
{
"mcpServers": {
"weather": {
"command": "node",
"args": ["/absolute/path/to/mcp-weather-server/build/index.js"]
}
}
}Or straight from npm — published 2026-10-19:
npx -y @thx93/mcp-weather-serverOr, equivalently, as a client config entry:
{
"mcpServers": {
"weather": { "command": "npx", "args": ["-y", "@thx93/mcp-weather-server"] }
}
}Or straight from the repository, with no registry account needed:
npm install github:Thx93/mcp-weather-serverThat path works because prepare builds the server during the install; build/ is
not committed, so without it the bin would point at a file that does not exist. It
was verified end to end — install from GitHub, then speak MCP to the result, and both
tools list with object output schemas.
Verified against the source
The tools return the National Weather Service's own data, so correctness is
checkable rather than asserted. On 2026-10-19, api.weather.gov reported one active
alert for TX and a paid call to the hosted get-alerts returned exactly one -
Event: Flood Advisory - for the same state.
That matters more than it sounds: the sibling evidence service carries a documented
reliability gap in its verdict (see its docs/evidence-quality.md), while these
tools have no inferred judgement to get wrong. They fetch and reshape; the values are
the NWS's.
Behaviour worth knowing
Failures are tool results, not protocol errors. A request the NWS cannot answer —
a non-US location, an outage, a timeout — comes back as
{ isError: true, content: [{ type: "text", text: "<what failed>" }] }. That is
the MCP contract for "this call was well formed and the work failed", as distinct
from a JSON-RPC error, which means the call itself was broken. A client can show
the text to a user and retry.
The NWS is slow to give up and we are not. Every request carries a 10-second timeout, so a stalled upstream surfaces as a failed tool call instead of a hung one.
Missing fields fall back rather than printing null. The NWS returns null for
fields it does not have. A missing event name renders as Unknown, a missing
temperature as Unknown — never the literal string null.
get-forecast returns at most five periods. Enough to answer "what is the
weather like", short enough for a context window.
Structured content
Both tools declare an outputSchema and return structuredContent, and both
schemas are objects: get-forecast returns { latitude, longitude, periods },
get-alerts returns { alerts: [...] }.
get-alerts previously declared a top-level array, which protocol revision
2026-07-28 does permit. It was changed because a client on the widely-deployed MCP
SDK rejects the entire tools/list response when it meets an array schema —
invalid_value: expected "object" — so such a client cannot connect to the server
at all. Wrapping the array in an object is what makes these tools reachable from
ordinary clients; the textual summary a model reads is unchanged.
FAQ
What is this?
An MCP (Model Context Protocol) server that exposes US weather data from the National
Weather Service as two read-only tools, get-alerts and get-forecast. It runs over
stdio when you install it, and the same code is served over streamable HTTP at
https://agent-evidence.thx93.dev/weather/mcp where it is paid per call.
Do I need an API key? No. The National Weather Service API needs no key, and neither the local server nor the hosted endpoint asks for one, for an account, or for a signup.
How much does it cost?
Running it yourself is free — it is ISC-licensed and published as
@thx93/mcp-weather-server on npm. The hosted endpoint charges 0.01 USDC per call on
Base through x402, which is how an agent with a wallet but no ability to sign up for
anything can still call it.
Which locations are supported? US only. The data is the National Weather Service's, which covers the United States and its territories. A coordinate outside that coverage returns an error rather than a guess.
What do the tools return?
get-alerts takes a two-letter state code and returns every active alert: event, area,
severity, description and the official instruction. get-forecast takes a latitude and
longitude and returns five forecast periods: name, temperature, wind speed and
direction, and the plain-language forecast. Both declare an object output schema.
How do I add it to Claude Desktop, Cursor or another MCP client?
{
"mcpServers": {
"weather": { "command": "npx", "args": ["-y", "@thx93/mcp-weather-server"] }
}
}Why does it exist? It began as the MCP "Build a server" tutorial and was extended: typed output schemas, read-only annotations, a bounded fetch, an explicit failure contract and a test suite.
Provenance
Started from the Build an MCP server tutorial and then went past it: typed output schemas, read-only tool annotations, a bounded fetch with an explicit failure contract, and a test suite. Licensed ISC.
Available Tools
2 toolsget-alertsGet Weather AlertsARead-onlyIdempotentInspect
Get weather alerts for a state
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code (e.g. CA, NY) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds the state-scoping behavior, but it does not disclose additional behavioral details such as whether alerts are current, source, or result limits. This is adequate but not rich.
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 a single, front-loaded sentence with no filler. Every word contributes to the agent's understanding of what the tool does, and it is appropriately sized for a simple one-parameter getter.
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 a single required parameter, a fully documented schema, rich safety annotations, and an output schema present, the description is nearly complete. The only gap is that it does not explicitly route the agent between alerts and forecast, but the resource names make the distinction easy to infer.
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% and the state parameter already has a clear description with min/max length and an example. The description adds no meaning beyond saying 'for a state,' so it meets the baseline for full schema coverage.
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 uses a specific verb and resource: 'Get weather alerts for a state.' It clearly identifies both the resource (weather alerts) and the scope (a state), and the tool name and resource type immediately distinguish it from the sibling get-forecast.
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 makes the intended context clear: use when weather alerts for a specific state are needed. It does not explicitly name get-forecast as the alternative or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-forecastGet Weather ForecastBRead-onlyIdempotentInspect
Get weather forecast for a location
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude of the location | |
| longitude | Yes | Longitude of the location |
Output Schema
| Name | Required | Description |
|---|---|---|
| periods | Yes | The forecast periods, soonest first |
| latitude | Yes | Latitude the forecast is for |
| longitude | Yes | Longitude the forecast is for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a safe read-only, idempotent operation, so the description does not need to restate that. It adds no behavioral context beyond 'for a location', but it does not contradict the annotations either.
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 a single short sentence with no filler. The core action and object are front-loaded, making it easy to scan.
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 simple two-parameter schema, rich annotations, and an output schema, the description is mostly sufficient. A minor gap is that it does not clarify what kind of forecast data is returned, but the output schema likely covers that.
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%, and the description does not add parameter-level detail. The phrase 'for a location' loosely maps to latitude/longitude, but the schema already documents those parameters adequately.
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 states a clear verb and resource: it fetches a weather forecast for a location. It does not explicitly differentiate from the sibling get-alerts, though the resource names imply different purposes.
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?
No guidance is given about when to use this tool over get-alerts, nor any conditions, prerequisites, or exclusions. The intended context must be inferred entirely from the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.0- First observed
get-alerts - First observed
get-forecast
TDQS
Scored across 2 tools
The two tools are clearly distinct: one provides alerts for a state, the other provides forecasts for a location. No overlap or ambiguity.
Both tools follow a consistent 'get-' verb prefix with a clear noun (alerts, forecast), maintaining a predictable pattern.
With only 2 tools, the server feels thin. It's borderline—sufficient for a minimal weather use case but lacking the breadth typically expected.
The server lacks common weather operations such as current conditions, radar, or location search, creating significant gaps for typical weather-related queries.
Maintenance
Related MCP Connectors
Get US weather forecasts, active alerts, and current observations.
Provide real-time and forecast weather information for locations in the United States using natura…
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides access to National Weather Service (NWS) data, enabling users to retrieve active weather alerts for US states and weather forecasts for specific geographic coordinates.66 npmMIT
- AlicenseBqualityDmaintenanceProvides weather information and alerts from the National Weather Service, including active weather alerts for US states and location-based forecasts using latitude/longitude coordinates.2MIT
- FlicenseBqualityDmaintenanceProvides access to US weather data from the National Weather Service API, enabling retrieval of active weather alerts by state and detailed forecasts for specific coordinates.21-
- AlicenseNot gradedqualityDmaintenanceProvides weather information using the US National Weather Service API, including active weather alerts for US states and location-specific forecasts based on latitude and longitude coordinates.66 npmMIT