Skip to main content
Glama
gitPratikSingh

Weather MCP Server

by gitPratikSingh
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Weather MCP Server

A complete Model Context Protocol (MCP) server that provides weather information through tools, resources, and prompts, designed for integration with Cursor IDE.

What is MCP (Model Context Protocol)?

MCP is a protocol that enables AI assistants (like Cursor) to connect to external data sources and tools. It allows AI models to:

  • Call Tools: Execute functions to perform actions (e.g., fetch weather data, query databases)

  • Read Resources: Access structured data from external sources (e.g., files, APIs, databases)

  • Use Prompts: Leverage reusable prompt templates for consistent interactions

How MCP Works

┌─────────────┐         MCP Protocol         ┌──────────────┐
│   Cursor    │ ◄──────────────────────────► │  MCP Server  │
│     IDE     │     (stdin/stdout or HTTP)    │  (Python)    │
└─────────────┘                               └──────────────┘
      │                                              │
      │  Calls tools, reads resources,              │
      │  uses prompts                               │
      │                                              │
      └──────────────────────────────────────────────┘
                    External APIs/Data

The MCP server acts as a bridge between the AI assistant and external services, providing a standardized interface for accessing data and functionality.

Related MCP server: Weather MCP Server

Features

This Weather MCP Server provides:

Tools

  • get_current_weather(location: str) - Fetch current weather conditions for a location

  • get_weather_forecast(location: str, days: int) - Get multi-day weather forecast

  • search_locations(query: str) - Search for location names

Resources

  • weather://current/{location} - Current weather data as a readable resource

  • weather://forecast/{location} - Forecast data as a readable resource

Prompts

  • analyze_weather - Template for analyzing weather patterns and conditions

  • compare_locations - Template for comparing weather between different locations

Setup

Prerequisites

  • Python 3.12 or higher

  • uv package manager (or pip)

Installation

  1. Install dependencies:

uv sync
# or
pip install -r requirements.txt

  1. Set up environment variables (optional, for real API):

    Create a .env file in the project root:

    # .env
WEATHER_API_KEY=your_api_key_here

    Get a free API key from OpenWeatherMap

    Note: If no API key is provided, the server will use mock data for demonstration purposes.

Running the Server

python main.py

The server will start and communicate via stdio (standard input/output), which is the standard transport for MCP servers in Cursor IDE.

Cursor IDE Integration

To use this MCP server in Cursor IDE:

  1. Open Cursor IDE settings (Cmd/Ctrl + ,)

  2. Navigate to Features → MCP Servers (or search for "MCP" in settings)

  3. Click Add Server or edit the MCP servers configuration

  4. Add the following configuration (update the path to match your project location):

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": [
        "run",
        "python",
        "/Users/pratik/weather/main.py"
      ],
      "env": {}
    }
  }
}

Important: Replace /Users/pratik/weather/main.py with the absolute path to your main.py file.

  1. Save the configuration

  2. Restart Cursor IDE

  3. The AI assistant can now use the weather tools, resources, and prompts!

Alternative: You can also copy the configuration from cursor_mcp_config.json and merge it into your Cursor settings.

Usage Examples

Once integrated with Cursor IDE, you can ask the AI assistant:

  • "What's the weather in New York?"

  • "Get a 5-day forecast for London"

  • "Compare the weather in San Francisco and Seattle"

  • "Search for locations matching 'Paris'"

The AI will automatically use the appropriate MCP tools, resources, or prompts to fulfill your request.

Weather MCP Server Usage Example

Example: Asking "What's the weather in New York?" in Cursor IDE with the Weather MCP Server

Architecture

┌─────────────┐
│   Cursor    │
│     IDE     │
└──────┬──────┘
       │ MCP Protocol
       │
┌──────▼──────────────────┐
│   MCP Weather Server    │
│  (main.py)              │
├─────────────────────────┤
│ • Tools                 │
│ • Resources             │
│ • Prompts               │
└──────┬──────────────────┘
       │
┌──────▼──────────┐
│ Weather API     │
│ (weather_api.py)│
└─────────────────┘

Development

Project Structure

weather/
├── main.py                 # MCP server implementation
├── weather_api.py          # Weather API client
├── pyproject.toml          # Dependencies
├── cursor_mcp_config.json  # Cursor IDE configuration
├── .env.example            # Environment template
└── README.md               # This file

Adding New Features

  • New Tools: Add functions to the tools list in main.py

  • New Resources: Add URI patterns to the resources list in main.py

  • New Prompts: Add prompt templates to the prompts list in main.py

License

MIT

Available Tools

3 tools
get_current_weatherC

Get current weather conditions for a specific location

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesCity name or location (e.g., 'New York', 'London')

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 full burden for behavioral disclosure. It states what the tool does but reveals nothing about permissions, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 address behavioral aspects like authentication needs, rate limits, or what the return values look like. For a tool with no structured safety or output information, the description should provide more context.

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 schema description coverage is 100%, with the single parameter 'location' fully documented in the schema. The description adds no additional parameter details beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.

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 current weather conditions') and resource ('for a specific location'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_weather_forecast' (current vs. forecast) or 'search_locations' (weather vs. location search), which prevents a perfect score.

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_weather_forecast' or 'search_locations'. It lacks any mention of prerequisites, exclusions, or contextual cues, leaving the agent to infer usage based on tool names alone.

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

get_weather_forecastC

Get weather forecast for a specific location for multiple days

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesCity name or location (e.g., 'New York', 'London')
daysNoNumber of days to forecast (1-5)

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 behavioral traits such as rate limits, authentication needs, error handling, or what the forecast includes (e.g., temperature, precipitation). 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 front-loads the core purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function, making it appropriately sized and well-structured.

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 complexity of a weather forecasting tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the forecast returns (e.g., data format, units), potential limitations, or how it differs from siblings, leaving gaps for effective agent use.

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 schema description coverage is 100%, with clear documentation for both parameters ('location' and 'days'), including constraints like the 1-5 range for 'days'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema 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 verb ('Get') and resource ('weather forecast') with specific scope ('for a specific location for multiple days'), making the purpose evident. However, it doesn't explicitly distinguish from sibling tools like 'get_current_weather' (which likely provides current conditions rather than forecasts) or 'search_locations' (which might find locations rather than provide weather data).

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_current_weather' or 'search_locations'. It lacks context about prerequisites, exclusions, or comparative use cases, leaving the agent to infer usage based on tool names alone.

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

search_locationsC

Search for location names matching a query string

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query for location name

TDQS

C2.9/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 only states the basic action without details like search scope (e.g., global vs. local), result format, pagination, rate limits, or error handling. For a search tool with zero annotation coverage, 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.

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple search tool, making it easy for an agent to parse quickly.

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., list of locations, IDs, coordinates) or behavioral aspects like search behavior. For a tool with no structured data beyond the input schema, more context is needed.

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 input schema has 100% description coverage, with the 'query' parameter fully documented. The description adds no additional meaning beyond the schema, such as query syntax examples or matching criteria. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose as 'Search for location names matching a query string,' which includes a specific verb ('Search') and resource ('location names'). However, it doesn't differentiate from sibling tools like get_current_weather or get_weather_forecast, which are weather-related rather than location search tools, so it doesn't need sibling differentiation here.

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. It doesn't mention any context, prerequisites, or exclusions, such as whether it's for autocomplete, exact matches, or how it relates to weather tools. This leaves the agent without usage direction.

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 updatesv1.0.0
    • First observedget_current_weather
    • First observedget_weather_forecast
    • First observedsearch_locations
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_current_weather retrieves current conditions, get_weather_forecast provides future predictions, and search_locations handles location queries. An agent can easily differentiate between these three functions.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern (get_current_weather, get_weather_forecast, search_locations) with clear, descriptive names. There are no deviations in style or convention across the toolset.

Tool Count4/5

Three tools is reasonable for a weather server, covering core functions like current conditions, forecasts, and location search. However, it feels slightly thin as it lacks tools for historical weather data or alerts, which are common in weather APIs.

Completeness4/5

The toolset covers essential weather operations: retrieving current data, forecasts, and location lookup. A minor gap exists in not including historical weather data or severe weather alerts, but agents can still perform most common weather-related tasks effectively.

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

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/gitPratikSingh/weather_mcp_server'

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