Skip to main content
Glama
gaurigshankar

Weather MCP Server

by gaurigshankar
OverviewSchemaRelated ServersScoreDiscussions
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_alertsC

Get weather alerts for a state

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

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits such as whether it's read-only, rate-limited, authentication requirements, error conditions, or what format the alerts are returned in. This is a significant gap for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool with one parameter and is front-loaded with 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 annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., alert types, format, timestamps) or any behavioral aspects like error handling. For a tool with no structured metadata, the description should provide more context to be fully helpful to an agent.

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?

The description doesn't add any parameter information beyond what's already in the schema, which has 100% coverage and fully documents the 'state' parameter. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.

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 verb ('Get') and resource ('weather alerts for a state'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'get_forecast', which appears to be a related weather tool but for forecasts rather than alerts.

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?

The description provides no guidance on when to use this tool versus alternatives like 'get_forecast'. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent to infer usage based on the tool name alone.

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?

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get weather forecast' implies a read-only operation, but the description doesn't specify what kind of forecast data is returned (e.g., hourly/daily, temperature/precipitation), whether there are rate limits, authentication requirements, or data freshness considerations.

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, efficient sentence that states exactly what the tool does without any unnecessary words. It's appropriately sized for a simple tool with two parameters and gets straight to the point.

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?

For a simple read-only tool with complete schema coverage but no output schema, the description provides the basic purpose but lacks important context. Without annotations or output schema, users don't know what format the forecast data will be in, what time periods it covers, or how to interpret the results.

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 both latitude and longitude parameters well-documented in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline expectation when schema coverage is complete.

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 verb 'get' and resource 'weather forecast for a location', making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_alerts', which presumably also provides weather-related information but for alerts rather than forecasts.

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?

The description provides no guidance on when to use this tool versus alternatives. With a sibling tool 'get_alerts' available, there's no indication of when to choose forecast data over alert data, or whether these tools should be used together or separately.

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 updates
    • First observedget_alerts
    • First observedget_forecast
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
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
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

  • 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.
    28
    -

Appeared in Searches

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/gaurigshankar/weather-mcp-server'

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