Skip to main content
Glama
jalateras

weather

by jalateras
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Weather MCP Server

Overview

This project implements a Model Context Protocol (MCP) server that provides weather information services. It leverages the National Weather Service (NWS) API to fetch weather alerts and forecasts, and exposes them as tools that can be used by MCP clients like Claude.

The server is built with a modular architecture following best practices for Python projects, making it easy to maintain and extend.

Features

  • Weather Tools: Get weather alerts for states and forecasts for specific coordinates

  • System Tools: Run shell commands and view system process information

  • MCP Integration: Seamlessly integrates with MCP clients like Claude Desktop

Related MCP server: Weather MCP Server

Installation

Prerequisites

  • Python 3.11 or higher

  • uv package manager

Setup

  1. Clone the repository:

    git clone https://github.com/yourusername/weather.git
cd weather

  2. Install dependencies using uv:

    make install

  3. For development, install additional dependencies:

    make dev

Usage

Running the Server

To start the MCP server:

make run

Or directly with uv:

uv run python -m main

Connecting to Claude Desktop

  1. Update your Claude Desktop configuration to include the weather server:

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["-m", "main"],
      "cwd": "/path/to/weather"
    }
  }
}

  1. Restart Claude Desktop to apply the changes

  2. In Claude Desktop, you can now select the "weather" MCP server from the MCP server dropdown menu

The weather MCP server will be available to Claude Desktop, allowing you to interact with weather data directly in your conversations.

Example Queries

Once connected, you can ask Claude:

  • "What are the current weather alerts in CA?"

  • "What's the forecast for latitude 37.7749, longitude -122.4194?"

  • "What processes are using the most CPU on my system?"

Project Structure

weather/
├── src/
│   └── weather/
│       ├── __init__.py          # Package initialization
│       ├── server.py            # Main server setup
│       ├── tools/               # Tool implementations
│       │   ├── __init__.py
│       │   ├── weather_tools.py
│       │   └── system_tools.py
│       ├── resources/           # Resource implementations
│       │   ├── __init__.py
│       │   └── system_resources.py
│       ├── services/            # External service integrations
│       │   ├── __init__.py
│       │   ├── weather_service.py
│       │   └── system_service.py
│       └── utils/               # Helper functions
│           ├── __init__.py
│           ├── http.py
│           └── formatting.py
├── tests/                       # Test suite
├── main.py                      # Entry point
├── pyproject.toml               # Dependencies and metadata
├── Makefile                     # Build commands
└── README.md                    # This file

Make Targets

The project includes several make targets to simplify development:

Target

Description

install

Install project dependencies using uv

lint

Run ruff linter with auto-fix using uv

format

Run black formatter using uv

format-check

Check if files would be reformatted by black

lint-format

Run both linter and formatter

test

Run tests using pytest with uv

clean

Remove build artifacts and cache files

outdated

Check for outdated dependencies using uv

upgrade-deps

Upgrade all outdated dependencies using uv

run

Start the MCP server using uv

inspector

Start the MCP Inspector for testing

hooks

Install git hooks

dev-server

Start the MCP server in development mode

stop-server

Stop the MCP server and Inspector

claude-install

Install the server in Claude Desktop

claude-uninstall

Uninstall the server from Claude Desktop

Run make help to see all available targets.

Using with Claude Desktop

To use the weather MCP server with Claude Desktop:

  1. Install the server in Claude Desktop:

make claude-install

This will:

  • Use the MCP CLI to install the server in Claude Desktop

  • Install the project in editable mode (-e .)

  • Register the server with the name "weather"

  • Configure the server to run from your project directory

  1. Restart Claude Desktop to apply the changes

  2. In Claude Desktop, you can now select the "weather" MCP server from the MCP server dropdown menu

The weather MCP server will be available to Claude Desktop, allowing you to interact with weather data directly in your conversations.

To uninstall the server from Claude Desktop:

make claude-uninstall

This will remove the weather MCP server configuration from Claude Desktop. You'll need to restart Claude to apply the changes.

Development Mode

For active development with automatic reloading when code changes:

# Start the server in development mode with the MCP Inspector
make dev-server

This will:

  1. Start the MCP server using the mcp dev command

  2. Install the project in editable mode (-e .)

  3. Launch the MCP Inspector automatically

  4. Enable automatic reloading when your code changes

The MCP Inspector will be available at http://localhost:5173 in your web browser.

To stop the server and Inspector:

make stop-server

This setup is ideal for iterative development as the server will automatically reload when you make changes to your code.

Inspector Features

The MCP Inspector allows you to:

  1. Explore Tools: View all available tools, their parameters, and documentation.

  2. Call Tools: Execute tools with custom parameters and see the results.

  3. Browse Resources: View all available resources and their current values.

  4. Test Prompts: If your server provides prompt templates, you can test them with different inputs.

  5. View Logs: See detailed logs of all interactions between the Inspector and your server.

Testing Weather Tools

With the Inspector, you can easily test the weather tools:

  1. Find the get_weather_alerts tool in the Inspector interface

  2. Enter a state code (e.g., "CA", "NY", "FL") in the parameters field

  3. Execute the tool and view the results

Similarly, you can test the get_forecast tool by providing latitude and longitude coordinates.

Testing System Tools

The Inspector also makes it easy to test system tools:

  1. Find the run_shell_command tool

  2. Enter a safe command (e.g., "ls -la", "echo hello") in the parameters field

  3. Execute the tool and view the results

Debugging with the Inspector

The Inspector is particularly useful for debugging:

  1. It shows detailed error messages if a tool call fails

  2. You can see the exact request and response payloads

  3. It helps identify issues with parameter validation or tool implementation

For more information about the MCP Inspector, visit the Model Context Protocol documentation.

Testing Locally

You can test your MCP server locally using the MCP CLI tool that comes with the mcp[cli] package:

  1. Start your server:

    make run

  2. In a separate terminal, use the MCP CLI to interact with your server:

    # List all available tools
make inspector

# Call a specific weather tool
mcp call-tool http://localhost:8000 get_weather_alerts --args '{"state": "CA"}'

# Get a weather forecast
mcp call-tool http://localhost:8000 get_forecast --args '{"latitude": 37.7749, "longitude": -122.4194}'

# List system resources
mcp list-resources http://localhost:8000

# Get system processes
mcp get-resource http://localhost:8000 top_processes

If you're using uv directly, you can run the MCP CLI with:

uv run mcp list-tools http://localhost:8000

Development

Adding New Tools

To add a new tool to the server:

  1. Create a function in the appropriate tools module

  2. Register it with the @server.tool() decorator

  3. Update the tool registration in tools/__init__.py

Example:

@server.tool()
async def my_new_tool(param1: str, param2: int) -> str:
    """
    Tool description.
    
    Args:
        param1: Description of param1
        param2: Description of param2
        
    Returns:
        Description of return value
    """
    # Implementation
    return result

Adding New Resources

To add a new resource:

  1. Create a function in the appropriate resources module

  2. Register it with the @server.resource() decorator

  3. Update the resource registration in resources/__init__.py

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

Available Tools

3 tools
get_alertsA
    Get active weather alerts for a state.

    Args:
        state: Two-letter state code (e.g., 'CA', 'NY')

    Returns:
        Formatted alerts or error message
ParametersJSON Schema
NameRequiredDescriptionDefault
stateYes

TDQS

A3.6/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 the full burden. It states the tool returns 'Formatted alerts or error message' but does not disclose behavioral traits such as read-only nature, rate limits, authentication needs, or error conditions. Minimal transparency.

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 a clear structure: purpose line, args section, returns section. It is front-loaded and each sentence serves a purpose, though it omits some useful context.

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 one-parameter tool with no output schema or annotations, the description is adequate. It explains the input format and basic return, but lacks details on what 'active' means, possible multiple alerts, formatting specifics, and error scenarios.

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?

The schema only defines 'state' as a string with a title. The description adds crucial detail: 'Two-letter state code (e.g., 'CA', 'NY')', clarifying format and providing examples. Since schema description coverage is 0%, the description compensates effectively.

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', the resource 'active weather alerts', and the scope 'for a state'. It effectively distinguishes from siblings: 'get_forecast' is for forecasts, 'run_shell_command' is unrelated.

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

Usage Guidelines3/5

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

The description implies usage for retrieving weather alerts by state but does not explicitly state when to use it versus alternatives or provide exclusion criteria. No when-not or prerequisite information is given.

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

get_forecastC
    Get weather forecast for coordinates.

    Args:
        latitude: Latitude coordinate
        longitude: Longitude coordinate

    Returns:
        Formatted forecast or error message
ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes
longitudeYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only mentions returning a forecast or error message, but omits details like data source, update frequency, or rate limits. The inherent read-only nature is reasonable, but more context would help.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but includes an Args section that is redundant with the input schema. It could be more concise by omitting the Args section, as the schema already defines parameters. Still, it is not overly verbose.

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 simplicity (2 params, no output schema), the description covers the basics: what it does, input coordinates, and output type. However, it lacks completeness on error conditions, coordinate limitations, or any output formatting hints beyond 'formatted forecast'.

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?

Schema coverage is 0%, yet the description only repeats parameter names with minimal description (e.g., 'Latitude coordinate'). It lacks details like valid ranges (-90 to 90), decimal degree format, or that longitude should be between -180 and 180.

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 tool fetches a weather forecast for given coordinates. The verb 'get' and resource 'weather forecast' are specific, and it distinguishes from siblings like 'get_alerts' and 'run_shell_command'.

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 over alternatives (e.g., 'get_alerts' for warnings). The description lacks context for decision-making, such as noting that coordinates should be valid or that this tool is for general forecasts.

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

run_shell_commandC
    Run a shell command and return the output.

    Args:
        command: Shell command to execute

    Returns:
        Command output or error message
ParametersJSON Schema
NameRequiredDescriptionDefault
commandYes

TDQS

C2.8/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. It mentions returning 'command output or error message' but omits critical security implications, side effects, permissions, or sandboxing. For a potentially dangerous tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with three short sentences. However, it sacrifices critical details for brevity. It is front-loaded with purpose but misses essential usage information.

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

Completeness1/5

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

Given the complexity and potential risks of executing shell commands, the description is grossly incomplete. It lacks information on return format, error handling, security, timeouts, and permissions. No output schema or annotations exist to compensate.

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 only parameter 'command' is described as 'Shell command to execute,' which adds almost no value beyond the schema property name. With 0% schema description coverage, the description should provide more detail (e.g., format, restrictions).

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 tool runs a shell command and returns output. It uses a specific verb+resource structure and easily distinguishes from sibling tools like get_alerts and get_forecast.

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. It does not provide any context for when executing a shell command is appropriate or mention any prerequisites or exclusions.

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

TDQS

C2.8/5.0
Disambiguation2/5

The two weather tools (get_alerts, get_forecast) are distinct, but the inclusion of run_shell_command is completely unrelated, making the toolset confusing. An agent might struggle to decide when to use the shell command versus the weather tools, and the server's purpose is unclear.

Naming Consistency3/5

The naming pattern is consistent (verb_noun) across all tools, but run_shell_command disrupts the domain-specific naming expected for a weather server. The pattern itself is fine, but the mismatch in domain reduces consistency.

Tool Count2/5

Three tools is reasonable for a simple weather server, but the presence of run_shell_command makes the count inappropriate because it does not fit the server's purpose. The toolset should focus solely on weather operations.

Completeness2/5

The weather tools cover alerts and forecasts, but miss common operations like current conditions or historical data. Moreover, the shell command is out of place and does not contribute to weather functionality, leaving a gap in the expected weather domain coverage.

Maintenance

ActivityInactive
ResponsivenessNo issues

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/jalateras/weather'

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