Skip to main content
Glama
tjguitar2025

Context Weather

by tjguitar2025
OverviewSchemaRelated ServersScoreDiscussions
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: Claude-NWS Protocol Bridge

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. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedget_alerts
    • First observedget_forecast
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

The two tools are clearly distinct: get_alerts targets state-level weather alerts, while get_forecast targets point-based forecast. No overlap in purpose or arguments.

Naming Consistency5/5

Both tools follow a consistent get_verb_noun pattern (get_alerts, get_forecast), which is predictable and clear.

Tool Count3/5

With only 2 tools, the server feels minimal. While it serves a focused purpose, a typical weather API would offer more operations, making the count borderline.

Completeness4/5

The server covers alerts and forecast, but lacks current conditions or radar data. The gaps are minor given the server's 'context' focus.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tjguitar2025/MCP_Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server