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., "@mcpapp1 What weather alerts are active in Texas?"
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.
A small Model Context Protocol server that exposes live US weather alerts to MCP clients such as Claude Desktop, Claude Code, and Cursor.
Data comes from the National Weather Service API, which is free and requires no API key.
Kind | Name | Description |
Tool |
| Active weather alerts for a US state, by two-letter code (e.g. |
Resource |
| Echoes a message back; useful for verifying the server is reachable |
Related MCP server: Weather MCP Server
Python 3.13+
git clone https://github.com/eyosiasbisrat/mcpapp1.git
cd mcpapp1
uv syncRun the server directly over stdio:
uv run server/weather.pyOr via the MCP CLI:
uv run mcp run server/weather.pyInspect it interactively in the MCP Inspector:
uv run mcp dev server/weather.pyAn MCP server speaks JSON-RPC over stdin/stdout, so running it by hand just waits silently for input. That is expected — normally a client launches it for you.
Both configs are already checked in and use relative paths, so they work after uv sync with no edits:
.mcp.json — Claude Code
.cursor/mcp.json — Cursor
Reload the editor window and approve the server when prompted.
uv run mcp install server/weather.pyThen quit Claude Desktop completely — including the tray icon, since closing the window leaves it running — and reopen it.
If this prints Claude app not found while Claude Desktop is definitely installed, see below.
Claude app not found on Windowsmcp install looks for Claude Desktop's config in a fixed location:
%APPDATA%\ClaudeIf Claude Desktop was installed as an MSIX / Microsoft Store package, its data is redirected into the package container and that directory never exists:
%LOCALAPPDATA%\Packages\Claude_<id>\LocalCache\Roaming\Claude\claude_desktop_config.jsonTwo ways to resolve it.
Edit the real config directly — add an mcpServers entry to the claude_desktop_config.json at the packaged path above, keeping any existing keys intact.
Or bridge the paths once with a directory junction, after which mcp install works normally for every server:
cmd /c mklink /J "%APPDATA%\Claude" "%LOCALAPPDATA%\Packages\Claude_<id>\LocalCache\Roaming\Claude"Substitute your actual package folder name for Claude_<id>. To undo it, cmd /c rmdir "%APPDATA%\Claude" removes only the link, not the config.
When registering the server manually on Windows, use uv's absolute path (e.g. C:\Users\<you>\.local\bin\uv.exe). Packaged apps do not reliably inherit your shell PATH, so a bare uv may fail to launch.
Confirm the client spawned it by checking process parentage:
Get-CimInstance Win32_Process -Filter "Name='uv.exe'" | ForEach-Object {
$p = Get-CimInstance Win32_Process -Filter "ProcessId=$($_.ParentProcessId)"
"$($_.ProcessId) <- $($p.Name)"
}A uv.exe whose parent is Claude.exe means the server is running. Note that some Claude Desktop builds do not write per-server logs to logs\, so an empty log folder is not evidence of failure.
server/weather.py the MCP server: tool, resource, and NWS client
main.py placeholder entrypoint
.mcp.json Claude Code server config
.cursor/mcp.json Cursor server config
pyproject.toml dependencies (httpx, mcp[cli])get_alerts covers US states only, since NWS is a US agency.
Requests carry a User-Agent header, which the NWS API requires.
Network and HTTP errors are swallowed and surface as a friendly "unable to fetch" message rather than a traceback.
Get weather alerts for a US state.
Args: state: Two-letter US state code (e.g. CA, NY)
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read-only operation, but the description does not explicitly state side-effect-free behavior or any caveats about alert types or data source. It is not misleading, but it adds minimal behavioral context beyond what the name implies.
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 extremely concise, with a front-loaded purpose statement followed by a compact Args block. Every sentence earns its place and there is no filler.
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 well-documented parameter, an output schema, and no siblings, the description plus schema fully covers what an agent needs to invoke the tool correctly. No missing context for this simple operation.
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 description coverage is 0%, yet the description fully compensates by specifying the parameter format ('Two-letter US state code') and providing concrete examples ('CA, NY'). This adds real meaning beyond the raw schema type string.
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 specific verb ('Get'), a clear resource ('weather alerts'), and a clear scope ('US state'). It is unambiguous and leaves no doubt about what the tool does, even without siblings to differentiate from.
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?
There are no sibling tools, so explicit routing guidance is unnecessary. The description clearly implies usage: when you need weather alerts for a US state. It lacks explicit exclusions, but nothing is misleading or missing for a tool of this simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_alertsScored across 1 tool
With only one tool, there is no possibility of ambiguity or misselection. The tool's purpose is clearly defined in its name and description.
The single tool name follows the verb_noun pattern (get_alerts), which is clean and predictable. There are no other tools to create inconsistency.
One tool feels thin for a server, even one dedicated to weather alerts. While alerts retrieval is a focused task, a small set of supporting tools (e.g., list states or get alert details) would make the server feel more complete.
For the stated purpose of retrieving weather alerts, the get_alerts tool covers the core operation without obvious gaps. The domain is narrow, and no additional lifecycle operations are necessary for read-only alert access.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
Get US weather forecasts, active alerts, and current observations.
NOAA and ECMWF weather forecast MCP for discovery, validation, and GribStream OAuth queries.
Smarter Weather MCP: forecasts, alerts, outlooks, observations, AQI, grids, and map imagery.
