Weather MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Weather MCP Serverwhat's the forecast for New York City this weekend?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Creating an MCP Server Using Python and the Open-Meteo API
MCP servers extend the capabilities of language models by connecting them to data sources and services. Practically speaking, they are agnostic applications that facilitate integration with whatever data or service you point at and do pretty much anything you can think of. Think function calling, except the functions are plugins, and you start getting the idea.
MCP servers expose three main primitives:
Resources client-controlled
Exposes data to be used as context to clients on request.
Use a resource when you want to passively expose data or content to an MCP client and let the client choose when to access it.
Tools model-controlled
Exposes executable functionality to client models.
Use a tool when you want the client to perform an action, for example to request content from an API, transform data, or send an email.
Prompts user-controlled
Exposes reusable prompts and workflows to users.
Use a prompt when you want the client to surface prompts and workflows to the user, for example to streamline interaction with a resource or tool.
Let's talk about the weather LLMs are great for transforming data into natural language. One practical example of this is how they can translate weather data like temperature, wind speed, dew point, etc into descriptions of what the weather will feel like and recommendations on what type of clothing to wear.
In this tutorial you'll build an MCP server that uses the Open-Meteo API to provide real-time weather information and weather forecasts. The Open-Meteo API is free for non-commercial use, easily configurable through query parameters, and does not require an API key which makes it ideal for LLM integration.
How to use this tutorial This tutorial shows you how to start from scratch and set up an MCP server locally on your computer. Keeping the files local makes it easier to test the MCP server in Claude Desktop.
As you follow along, use the fully built-out example in the open-meteo-weather folder in the exercise files repository for this course for reference.
Requirements To follow along you need the following (much of this was covered earlier in the course):
A Claude.ai account (MCP support is available for all account types) The Claude Desktop app, available for macOS and Windows A code editor like Visual Studio Code uv - a Rust-based Python package manager (full installation instructions): macOS via Homebrew:
brew install uv Windows via WinGet:
winget install --id=astral-sh.uv -e
Setting up the project To set up your project, open your code editor to the folder you want to add your project. Then follow these steps to set up your project:
Create a new folder called mcp-server-weather using the editor tools or terminal: mkdir mcp-server-weather Navigate to the folder in terminal: cd mcp-server-weather Initiate a new uv project: uv init Create a virtual environment using uv: uv venv Start the virtual environment: source .venv/bin/activate Note: To stop the virtual environment, run deactivate in terminal. Install the Python MCP SDK with the CLI extension and additional Python dependencies in the virtual environment: uv add "mcp[cli]" httpx 2. Building the weather MCP server In the project folder there is a file called main.py. You can choose to work with this one, or create a new file called server.py. While the name is unimportant as long as you remember it for later, the naming convention for MCP servers is converging towards server.py so that's what this tutorial will use moving forward.
Scaffolding Start by adding scaffolding for the MCP server:
from typing import Any import httpx from mcp.server.fastmcp import FastMCP
Initialize FastMCP server
mcp = FastMCP("weather")
The rest of your code goes between here...
... and here.
if name == "main": # Initialize and run the server mcp.run(transport='stdio') This adds strong typing, the httpx client for accessing the web, the FastMCP class for building MCP servers, and runs the MCP server using stdio (standard input/output) as the transport mechanism, which is what Claude Desktop and other MCP clients expect.
Constants and helper functions Next, add constants and a helper function to interact with the Open-Meteo API:
Constants
OPENMETEO_API_BASE = "https://api.open-meteo.com/v1" USER_AGENT = "weather-app/1.0"
Helper function to make a request to the Open-Meteo API
async def make_openmeteo_request(url: str) -> dict[str, Any] | None: """Make a request to the Open-Meteo API with proper error handling.""" headers = { "User-Agent": USER_AGENT, "Accept": "application/json" } async with httpx.AsyncClient() as client: try: response = await client.get(url, headers=headers, timeout=30.0) response.raise_for_status() return response.json() except Exception: return None Create a get_forecast tool The Open-Weather API has a /forecast endpoint that can provide current weather and hourly forecast for any location defined by latitude and longitude with optional parameters for the data you need. For the full specification, visit the API documentation.
Since we want the LLM to be able to automatically request data from the API, and may also want the MCP server to perform actions on that data, each API interaction in this MCP server is best exposed as a tool.
Here's how to build a tool requesting the current weather using the Python SDK:
@mcp.tool() async def get_current_weather(latitude: float, longitude: float) -> str: """Get current weather for a location.
Args:
latitude: Latitude of the location
longitude: Longitude of the location
"""
url = f"{OPENMETEO_API_BASE}/forecast?latitude={latitude}&longitude={longitude}¤t=temperature_2m,is_day,showers,cloud_cover,wind_speed_10m,wind_direction_10m,pressure_msl,snowfall,precipitation,relative_humidity_2m,apparent_temperature,rain,weather_code,surface_pressure,wind_gusts_10m"
data = await make_openmeteo_request(url)
if not data:
return "Unable to fetch current weather data for this location."
return data
(See the official documentation for instructions on how to define tools without the SDK.)
Tools are defined using @mcp.tool() The LLM uses the initial comment as its prompt for when and how to use the tool, so this is where you define the tool operation Tools are written as regular Python function with your specified arguments Tools should always return data The LLM receives the returned data for further processing TIP: Resist the urge to format the returned data! The tool above returns the entire data set unaltered to the LLM allowing the LLM to process the data and generate an appropriate answer. This runs counter to how we normally build software, but makes sense when we work with language models.
Testing and running the MCP server The MCP server is now fully functional and ready to test using the MCP Inspector. You'll learn more about the inspector in the next video, but here's a preview:
In terminal, start your MCP server in developer mode by running: mcp dev server.py The MCP Inspector is now available at http://localhost:5173; open the URL in your browser Select the "Connect" button Select the "Tools" tab Select the "List Tools" button Select the get_current_weather tool In the get_current_weather panel, enter a latitude and longitude, eg 63.4463991, 10.8127596 Under "Tool Result" you'll see a JSON object with weather data Press Ctrl+C in terminal to crash out of the MCP Inspector.
Extend the MCP server with more features Now that you've built a tool, take what you've learned to add more tools and resources to the MCP server. Here are two ideas to get you started:
get_forecast - Retrieves the forecast for the specified location, with an optional argument for the range of the forecast get_location - Uses the Open-Meteo Geocoding API for more accurate location searches (without this you are relying on the LLM to generate the latitude and longitude, which can result in errors) Troubleshooting If your MCP server is not working as expected, compare it to the open-meteo-weather folder in the exercise files repository for this course, and watch the "Troubleshooting MCP servers" video later in this chapter. If you're still running into trouble, consult the official documentation for debugging tools and best-practices.
run project with
mcp dev server.py Available Tools
1 toolget_current_weatherB
Get current weather for a location.
Args: latitude: Latitude of the location longitude: Longitude of the location
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 only states the basic function without disclosing behavioral traits such as rate limits, authentication needs, error handling, or what the output contains. This leaves significant gaps for an AI agent to understand how to interact with the tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The additional parameter details are concise and relevant, though the formatting with 'Args:' could be slightly more integrated. Overall, it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters) and the presence of an output schema, the description is minimally complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. The output schema mitigates the need to explain return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by specifying that latitude and longitude are for a 'location,' which clarifies the context of the parameters. With 0% schema description coverage and 2 parameters, this compensation is valuable, though it doesn't detail formats or constraints. Since there are no parameters beyond the two required, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current weather for a location.' It uses a specific verb ('Get') and resource ('current weather'), but since there are no sibling tools, it cannot demonstrate differentiation from alternatives. The purpose is unambiguous and not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, prerequisites, or context. It simply states what the tool does without any usage instructions or exclusions. Since there are no sibling tools, this is less critical, but still a gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as retrieving current weather for a location.
The single tool name 'get_current_weather' follows a clear verb_noun pattern. Since there is only one tool, consistency is inherently perfect with no deviations to evaluate.
A single tool for a weather server is too few for the apparent scope. Weather domains typically require multiple operations like forecasts, historical data, or alerts, making this server feel incomplete and limited in functionality.
The tool surface is severely incomplete for a weather server. It only provides current weather, with no support for forecasts, historical data, alerts, or other common weather-related operations, which will likely cause agent failures in broader tasks.
Maintenance
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
Real-time weather conditions and multi-day forecasts via Open-Meteo — free, no API key required
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
Current weather and forecasts for any coordinates, backed b… — paid per call (x402/credits), 1 tools
Provide real-time and forecast weather information for locations in the United States using natura…
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to fetch current weather conditions and forecasts for any city using the Open-Meteo API. Provides temperature, precipitation, and hourly forecast data through natural language queries.
- FlicenseNot gradedqualityDmaintenanceProvides real-time weather and forecasts via Open-Meteo, supporting queries by coordinates or city name.
- FlicenseBqualityDmaintenanceProvides current weather conditions and forecasts for any location using the Open-Meteo API.2
- FlicenseNot gradedqualityCmaintenanceEnables to get current weather conditions for any location via the Open-Meteo API, returning temperature, humidity, wind, and more.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/olsigjecii/mcp-server-weather'
If you have feedback or need assistance with the MCP directory API, please join our Discord server