Skip to main content
Glama
PRIYADHARSANK

MCP Weather Project

by PRIYADHARSANK
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

MCP Weather Project

A Model Context Protocol (MCP) server implementation that provides weather alerts via the National Weather Service (NWS) API. This project includes both a FastMCP server and a LangChain-based client with memory capabilities.

Features

  • Weather Alerts: Fetch active weather alerts for any US state using the NWS API.

  • Echo Resource: A simple resource that echoes back messages.

  • Greeting Prompt: A customizable greeting prompt generator.

  • Interactive Client: A CLI-based chat client powered by Groq's Llama 3.3 model with conversation memory.

Related MCP server: Weather MCP Server

Prerequisites

  • Python 3.12 or higher

  • uv (recommended for dependency management)

  • A Groq API Key for the client.

Installation

  1. Clone the repository:

    git clone <repository_url>
cd mcpfile

  2. Install dependencies: Using uv (recommended):

    uv sync

    Or using pip:

    pip install -r requirements.txt

    (Note: You may need to generate a requirements.txt from pyproject.toml if not using uv)

  3. Set up Environment Variables: Create a .env file in the root directory and add your Groq API key:

    GROQ_API_KEY=your_groq_api_key_here

Usage

Running the Entry Point

The main.py is a simple entry point script that prints a welcome message.

uv run main.py
# OR
python main.py

Running the interactive Client

The client connects to the weather server and allows you to interact with it using natural language.

  1. Ensure the server configuration in server/weather.json is correct (it points to server/weather.py).

  2. Run the client:

    uv run server/client.py
# OR if using a virtual environment directly:
# python server/client.py

  3. Example Interaction:

    You: Check weather alerts for TX
Assistant: Checking weather alerts for Texas...
[Agent responds with alerts]

Running the MCP Server Standalone

You can run the MCP server directly using uv. This is useful for inspection or debugging with the MCP Inspector.

uv run --with mcp[cli] mcp run server/weather.py

Configuration Verification

Ensure that server/weather.json points to the correct absolute path of your server/weather.py file.

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "/your/absolute/path/to/mcp/mcpfile/server/weather.py" 
      ]
    }
  }
}

Project Structure

  • server/weather.py: The main MCP server implementation using FastMCP. Defines tools (get_alerts), resources, and prompts.

  • server/client.py: An MCP client implementation using LangChain and ChatGroq. Handles the interactive chat session.

  • server/weather.json: Configuration file for the MCP client to locate the server.

  • main.py: Simple entry point script.

  • pyproject.toml: Project configuration and dependencies.

Tools Available

  • get_alerts(state: str): Get active weather alerts for a US state (e.g., "CA", "NY").

Resources

  • echo://{message}: Echoes a message.

Prompts

  • greet_user(name: str, style: str): Generates a greeting in a specified style ("friendly", "formal", or "casual").

Available Tools

1 tool
get_alertsB

Get weather alerts for a US state.

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

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/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 of behavioral disclosure. It doesn't mention return format, pagination, whether alerts are current or historical, severity levels, or any rate limits or auth requirements. For a read-type tool the lack of annotations leaves significant gaps.

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 and well-scoped. The description is two lines with an args docstring for the single parameter. Every word is functional with zero waste.

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?

An output schema exists, which reduces the burden for explaining return values. However, with 0% schema description coverage, 1 single param (already covered in the args), no annotations, and no behavioral details (alert types, severity, expiration, update frequency), the description is minimal. For a weather alert tool, agents would benefit from knowing what constitutes an alert return vs. a no-alert return.

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 single parameter 'state' is described in the argument docstring as a two-letter US state code with examples (CA, NY), which adds meaning beyond the bare schema. However, it doesn't specify case sensitivity, whether territories are included (e.g., DC, PR), or what happens for invalid state codes. The examples help but full semantics aren't covered.

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 gets weather alerts for a US state, with a specific verb ('get') and resource ('weather alerts') and a geographic scope ('US state'). It distinguishes from the sibling tool 'get_forecast' by the resource type, though it doesn't explicitly name the sibling.

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 context ('for a US state') but provides no when-to-use guidance, no exclusions, and no comparison to the sibling get_forecast tool. The intent is reasonably clear but the agent doesn't know when alerts vs forecast is more appropriate.

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. 1 tool update
    • First observedget_alerts
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.3/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'get_alerts' has a clear and distinct purpose that cannot be confused with any other tool in this set.

Naming Consistency5/5

The naming pattern is trivially consistent as there is only one tool. The tool name 'get_alerts' follows a clear verb_noun convention (get + alerts), which would be consistent if more tools were added.

Tool Count2/5

A single tool is generally too few for a weather server's apparent scope, which typically includes forecasts, current conditions, and other weather data beyond just alerts. This feels thin and limited for the domain.

Completeness2/5

The tool surface is severely incomplete for a weather domain. It only provides alerts for US states, missing essential operations like getting forecasts, current weather, radar data, or international coverage, which will cause significant agent failures.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Weather MCP Server

    agentventure
    F
    license
    B
    quality
    D
    maintenance
    An MCP server that provides weather information and alerts for US locations using the National Weather Service API, enabling retrieval of weather forecasts and active weather alerts.
    2
    -

  • Weather MCP Server

    onceagainarise
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to get real-time weather alerts for US states and echo messages through both MCP server tools and a modern web interface. Provides weather information access with multiple deployment options for different use cases.
    1
    -

  • weather

    jalateras
    F
    license
    C
    quality
    D
    maintenance
    An MCP server that provides weather alerts and forecasts using the National Weather Service API, with additional system tools for shell commands and process information.
    4
    3
    1
    -