Skip to main content
Glama
gaurigshankar

Weather MCP Server

by gaurigshankar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Weather MCP Server

A Model Context Protocol (MCP) server that provides weather information and alerts using the National Weather Service (NWS) API. This server enables AI assistants to access real-time weather data for US locations.

Features

  • Weather Forecasts: Get detailed weather forecasts for any US location using latitude/longitude coordinates

  • Weather Alerts: Retrieve active weather alerts for any US state

  • NWS Integration: Uses the official National Weather Service API for reliable, up-to-date weather data

  • MCP Compatible: Works with any MCP-compatible AI assistant or application

Related MCP server: Weather MCP Server

Available Tools

get_forecast

Get weather forecast for a specific location.

Parameters:

  • latitude (number): Latitude of the location (-90 to 90)

  • longitude (number): Longitude of the location (-180 to 180)

Returns: Detailed weather forecast including temperature, wind conditions, and weather descriptions for multiple periods.

get_alerts

Get active weather alerts for a US state.

Parameters:

  • state (string): Two-letter state code (e.g., "CA", "NY", "TX")

Returns: List of active weather alerts including severity, affected areas, and descriptions.

Prerequisites

  • Node.js (version 14 or higher)

  • npm or yarn

  • An MCP-compatible client (like VS Code with GitHub Copilot)

Installation

  1. Clone the repository:

    git clone <repository-url>
cd weather-mcp-server

  2. Install dependencies:

    npm install

Building the Server

Build the TypeScript code to JavaScript:

npm run build

This will:

  • Compile TypeScript files from src/ to build/

  • Make the main executable file executable (chmod 755 build/index.js)

Usage with VS Code GitHub Copilot

To use this weather MCP server with VS Code GitHub Copilot, you need to update your MCP configuration:

Step 1: Update MCP Configuration

Edit your mcp.json file (usually located in your VS Code settings directory) and add the weather server:

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/Users/gshanka/Documents/ReactDev/weather-mcp-server/build/index.js"]
    }
  }
}

Note: Replace the path in args with the absolute path to your built index.js file.

Step 2: Restart VS Code

After updating the configuration, restart VS Code to load the new MCP server.

Step 3: Use Weather Tools

Once configured, you can ask GitHub Copilot for weather information:

  • "What's the weather forecast for San Francisco?" (Copilot will ask for coordinates or you can provide: latitude 37.7749, longitude -122.4194)

  • "Are there any weather alerts in California?" (Use state code "CA")

  • "Get me the forecast for latitude 40.7128, longitude -74.0060" (New York City)

Example Usage

Getting Weather Forecast

User: "What's the weather forecast for Seattle?"
Assistant: I'll get the weather forecast for Seattle (latitude: 47.6062, longitude: -122.3321).

[The server will return a detailed forecast with temperature, wind, and conditions for multiple periods]

Getting Weather Alerts

User: "Are there any weather alerts in Florida?"
Assistant: I'll check for weather alerts in Florida.

[The server will return any active weather alerts for the state of FL]

Development

Project Structure

weather-mcp-server/
├── src/
│   ├── index.ts          # Main MCP server implementation
│   └── weather-utils.ts  # Weather API utilities and types
├── build/                # Compiled JavaScript output
├── package.json
├── tsconfig.json
└── README.md

Running in Development

# Build and run
npm run build
node build/index.js

Debugging

The server logs errors to stderr, which you can monitor when running the server directly or check in your MCP client's logs.

API Limitations

  • US Only: The National Weather Service API only provides data for US locations

  • Rate Limiting: The NWS API has rate limits; avoid making excessive requests

  • Data Availability: Some remote or maritime locations may not have forecast data available

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Build and test the server

  5. Submit a pull request

License

ISC License - see package.json for details.

Troubleshooting

Server Not Loading

  • Ensure the path in mcp.json points to the correct build/index.js file

  • Verify the server was built successfully with npm run build

  • Check VS Code's MCP logs for error messages

No Weather Data

  • Verify you're using valid US coordinates

  • Check that the NWS API is accessible from your network

  • Ensure you're using valid two-letter state codes for alerts

Permission Errors

  • Make sure the build/index.js file is executable

  • The build script should handle this automatically with chmod 755

Available Tools

2 tools
get_alertsB

Get weather alerts for a state

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesTwo-letter state code (e.g. CA, NY)

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention that the tool is read-only, any rate limits, or what the output contains. The description is too minimal to inform an agent about side effects or safety.

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 description is a single sentence with no unnecessary words. It is efficiently structured and front-loads the essential information.

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 lack of output schema and annotations, the description is incomplete. It does not describe the return format or structure of alerts, which is important for an agent to process the results. For a simple tool, this gap is significant.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already documents the 'state' parameter fully (two-letter code, example). The description adds no additional information about parameters, so baseline score of 3 is appropriate.

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 clearly states the verb 'Get' and the resource 'weather alerts' with a qualifier 'for a state', making the purpose unambiguous. The sibling tool 'get_forecast' is distinct enough to differentiate without explicit mention.

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 on when to use this tool versus alternatives like 'get_forecast'. No mention of prerequisites or conditions for use. The description only states what the tool does, not when to use it.

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

get_forecastB

Get weather forecast for a location

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYesLatitude of the location
longitudeYesLongitude of the location

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits, but it only states 'Get weather forecast for a location'. It does not mention what kind of forecast (current, daily, hourly), potential destructive actions (none implied but not confirmed), or any required permissions. The agent has no insight into side effects or return behavior.

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 description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool with two well-documented parameters.

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

Completeness3/5

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

Given the tool's low complexity (2 params, no output schema, no annotations), the description is minimally adequate. However, it omits key details such as the forecast type, time horizon, units, and any specifics about the response. A slightly more complete description would improve usability.

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

Parameters3/5

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

Schema description coverage is 100% with each parameter having a clear description. The tool description adds no further parameter meaning. Baseline score of 3 is appropriate since the schema already documents parameters adequately.

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 action (get) and resource (weather forecast) with a location qualifier. However, it does not differentiate from the sibling tool 'get_alerts', which likely also relates to weather. Without distinguishing context, the agent may not know when to choose one over the other.

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 the alternative 'get_alerts'. There is no mention of prerequisites, typical use cases, or selection criteria, leaving the agent without context to make an informed choice.

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 updates
    • 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: one retrieves weather alerts for a state, while the other provides forecasts for a location. There is no overlap in functionality or ambiguity between them, making it easy for an agent to select the correct tool based on the need.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with 'get_' as the prefix, ensuring predictability and readability. The naming is uniform across the set, with no deviations in style or convention.

Tool Count2/5

With only two tools, the server feels thin for a weather domain, lacking essential operations like current conditions, historical data, or radar information. This minimal set may limit agent capabilities and require workarounds for common weather-related tasks.

Completeness2/5

The tool surface is significantly incomplete for a weather server, missing core functionalities such as current weather, hourly forecasts, or severe weather details. Agents will face gaps in handling typical weather queries, leading to potential failures or incomplete responses.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Weather MCP Server

    amuralik-gh
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to get weather forecasts and alerts for any US city and state through natural language queries using the National Weather Service API.
    -

  • Weather MCP Server

    aitiwari
    F
    license
    B
    quality
    D
    maintenance
    Provides real-time US weather alerts and forecasts by integrating with the National Weather Service API. It enables AI assistants to fetch state-specific alerts and detailed local forecasts using geographic coordinates.
    2
    1
    -

  • mcp-weather

    jpan8866
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides real-time weather alerts and forecasts from the National Weather Service for US locations, integrating with AI assistants via the Model Control Protocol.
    -

  • mcp-weather-api

    devgrunge
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides weather forecasts and alerts for US locations via the National Weather Service API, enabling AI assistants to deliver real-time weather information.
    8 npm
    -

Appeared in Searches