Skip to main content
Glama
shreyyzsh

Claude-NWS Protocol Bridge

by shreyyzsh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Context Weather

A Model Context Protocol (MCP) server that integrates the US National Weather Service API with Claude Desktop, providing real-time weather data and forecasts directly within your Claude conversations.

Features

  • Real-time weather conditions and forecasts

  • Location-based weather queries using coordinates or place names

  • Seamless integration with Claude Desktop via MCP

  • Live data from the official US National Weather Service API

  • Detailed weather metrics including temperature, humidity, wind, and precipitation

Related MCP server: Weather MCP Server

Prerequisites

  • Claude Desktop App

  • Python (v3.12 or higher)

  • uv package manager

  • Internet connection for API access

Installation

  1. Clone this repository:

    git clone https://github.com/yourusername/claude-nws-protocol-bridge.git
cd claude-nws-protocol-bridge

  2. Install dependencies:

    uv sync

  3. Configure the MCP server in your Claude Desktop settings:

    {
 "mcpServers": {
   "nws-weather": {
     "command": "uv",
     "args": ["run", "python", "weather.py"]
   }
 }
}

Usage

Once configured, you can ask Claude weather-related questions such as:

  • "What's the current weather in San Francisco?"

  • "Give me a 7-day forecast for New York City"

  • "What's the temperature and humidity right now?"

  • "Is it going to rain today in Seattle?"

API Reference

The bridge provides the following MCP tools:

get-current-weather

Retrieves current weather conditions for a specified location.

Parameters:

  • location (string): City name, coordinates, or ZIP code

get-weather-forecast

Gets weather forecast data for a specified location.

Parameters:

  • location (string): City name, coordinates, or ZIP code

  • days (number, optional): Number of forecast days (default: 7)

Available Tools

2 tools
get_alertsA
Getting weather alerts for a US State.

Args:
    state: two-letter us state code (e.g CA, NY)
ParametersJSON Schema
NameRequiredDescriptionDefault
stateYes

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided. Description implies a read operation but does not disclose any behavioral traits like rate limits, authorization requirements, or side effects. Adequate for a simple query tool.

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?

Extremely concise with no wasted words. The description is front-loaded with the purpose, followed by parameter details in a clear list format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description provides sufficient context. It could mention that it returns alerts or is read-only, but it is largely complete.

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?

Input schema has 0% description coverage, but the description adds meaning to the state parameter: 'two-letter us state code (e.g CA, NY)', which compensates well.

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 explicitly states 'Getting weather alerts for a US State', which is a clear verb+resource combination. It distinguishes from sibling tool get_forecast by focusing on alerts.

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?

Description indicates when to use: for weather alerts of a US state. It does not explicitly state when not to use or mention alternatives, but context is clear.

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

get_forecastC
Getting weather forecast for a location.

Args:
    latitude: latitude of the location
    longitude: longitude of the location
ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes
longitudeYes

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states the basic action without revealing traits like data freshness, units, rate limits, or whether the operation is read-only. The agent cannot infer important constraints or side effects.

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 concise with two short sentences, avoiding fluff. However, the structure is a simple paragraph without front-loading the most critical details. It is efficient but could be better organized to highlight key information first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description omits essential details such as the forecast timeframe, units, and response format. The absence of output schema increases the need for description completeness, which is not met. The agent is left guessing what data will be returned.

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

Parameters2/5

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

The description adds minimal value beyond the schema's property titles. It restates 'latitude of the location' and 'longitude of the location', which are already obvious from the parameter names. No ranges, formats, or semantics are provided, leaving the agent underinformed despite 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a weather forecast for a location using latitude/longitude. The verb is explicit and the resource is defined. However, it does not explicitly differentiate from sibling tool 'get_alerts', though the context implies they serve different data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., get_alerts). There are no explicit usage contexts, prerequisites, or exclusions, leaving the agent without direction on selecting this tool.

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.

  1. 2 tool updatesv1.0.0
    • First observedget_alerts
    • First observedget_forecast
Deploy Server
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

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: get_alerts retrieves weather alerts for a US state, while get_forecast provides weather forecasts for a specific geographic location. There is no overlap in functionality or ambiguity between them.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (get_alerts and get_forecast), using the same verb 'get' followed by a descriptive noun. This makes the tool set predictable and easy to understand.

Tool Count2/5

With only two tools, the server feels thin for a weather service domain. While the tools cover alerts and forecasts, there are likely missing operations such as current conditions, radar data, or historical data that would make the set more complete for typical weather-related tasks.

Completeness2/5

For a weather service, the tool set is significantly incomplete. It lacks core functionalities like getting current weather conditions, radar or satellite imagery, historical data, or air quality information. This limited coverage will likely cause agent failures when trying to perform comprehensive weather-related tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Weather MCP Server

    Danii2020
    F
    license
    D
    quality
    D
    maintenance
    Provides real-time weather forecasts and alerts by fetching data from the National Weather Service API, allowing Claude to answer weather-related questions with up-to-date information.
    2
    -