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., "@Open-Meteo MCP Server What's the weather in Tokyo 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.
A small MCP (Model Context Protocol) server that gives an AI assistant like Claude the ability to look up real weather data — current conditions and forecasts — by wrapping the free Open-Meteo API. No API key required.
Built as a learning project to understand how MCP servers work end to end: defining tools, running them locally, and connecting them to a real AI client.
Once connected to an MCP-compatible client (like Claude), it exposes three tools:
Tool | What it does |
| Turns a place name ("London") into coordinates |
| Current temperature, wind, precipitation, etc. for a coordinate |
| Up to a 16-day forecast (daily and/or hourly) for a coordinate |
So a person can ask an assistant "what's the weather in Lisbon tomorrow?" and the assistant will call these tools itself to find out and answer — it isn't pre-programmed with weather data, it fetches it live.
Related MCP server: Weather MCP Server
src/server.ts — defines the three tools and how each one calls the
Open-Meteo API. This is the actual "brains" of the server.
src/index.ts — runs the server over stdio (standard input/output).
This is the transport used by local dev tools like the
MCP Inspector and by
desktop apps that launch the server as a subprocess.
src/http.ts — runs the same server over Streamable HTTP, so it
can be reached over the network — e.g. hosted somewhere, or reached from a
browser-based client. This is what makes it possible to demo without
installing anything locally.
Both entry points share the same tool definitions in server.ts, so there's
only one place where the actual logic lives.
npm install
npm run buildLocal/stdio mode (for tools that spawn the server as a subprocess):
npm startHTTP mode (for connecting a remote client, e.g. over a forwarded Codespaces port or a hosting provider):
node build/http.jsThis starts a plain HTTP server on port 3000 (configurable via PORT) with
a single MCP endpoint at POST /mcp, plus a GET /health check.
The MCP Inspector's CLI mode is the fastest way to poke at it directly from a terminal, no browser needed:
# See what tools are available
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/list
# Actually call one
npx @modelcontextprotocol/inspector --cli node build/index.js \
--method tools/call --tool-name geocode_location --tool-arg name=LondonClaude Desktop / Claude Code: point at build/index.js as a stdio MCP
server in the client's config.
Claude.ai custom connectors: point at the /mcp URL of a running HTTP
instance (requires a plan that allows custom connectors).
Anthropic API directly: pass the /mcp URL in the mcp_servers
parameter of a /v1/messages request — this lets any custom app or page
use the tools without needing a pre-built MCP client.
Open-Meteo has many more variables and endpoints than this project uses
(air quality, marine forecasts, historical/archive data, ensembles). To add
more, follow the pattern of an existing tool in src/server.ts — register
a new server.tool(...) block with its own input schema and Open-Meteo
request.
Data © Open-Meteo.com, CC BY 4.0.
Look up geographic coordinates (latitude/longitude) for a place name, e.g. 'London', 'Paris, TX', or 'Tokyo'. Use this before calling the weather tools if you only have a place name rather than coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Place name to search for, e.g. 'San Francisco' | |
| count | No | Maximum number of matching locations to return (default 5) | |
| language | No | Language for place names, as an ISO 639-1 code (default 'en') | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It clearly signals a read-only lookup and the output type (coordinates), but does not disclose that multiple matches may be returned or how result ordering/selection works. This is adequate for a simple lookup but leaves some behavior unspecified.
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?
Two sentences with no filler. The core action and examples are front-loaded, and the usage guidance is delivered efficiently in the second sentence.
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?
The tool is simple and the input schema is fully covered, but there is no output schema. The description does not specify the exact return shape (e.g., list of objects with lat/lng fields), which the agent must infer for downstream weather tool calls. Enough for a basic lookup, but not fully complete.
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?
Schema coverage is 100%, so the schema fully documents all three parameters. The description adds useful input examples for the 'name' parameter but no meaningful new semantics for 'count' or 'language' beyond what the schema already states.
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?
States a specific action ('Look up geographic coordinates') with concrete examples of valid inputs. Clearly distinguishes this geocoding tool from the weather sibling tools.
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?
Explicitly instructs when to use this tool: before calling weather tools when only a place name is available. This directly guides the agent to the right workflow and differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current weather conditions (temperature, wind, precipitation, etc.) for a specific latitude/longitude. Use geocode_location first if you only have a place name.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in decimal degrees | |
| timezone | No | Timezone for returned timestamps, e.g. 'America/New_York' or 'auto' to infer from coordinates | auto |
| longitude | Yes | Longitude in decimal degrees | |
| wind_speed_unit | No | Unit for wind speed values | kmh |
| temperature_unit | No | Unit for temperature values | celsius |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It accurately communicates a read-only, coordinate-based lookup and names the main returned data (temperature, wind, precipitation). It does not detail the response shape or any API-specific quirks, which would add clarity, but for a simple current-weather read it is adequate.
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 two compact sentences with no filler. The main operation is front-loaded, and the routing guidance is placed second where it is easy to notice.
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?
The description provides enough for an agent to decide to call this tool for current weather at coordinates and to geocode place names first. However, with no output schema and no annotations, it would benefit from a brief statement of the response format or the forecast alternative.
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 schema already describes all five parameters with 100% coverage, so the baseline is 3. The description adds only the geocoding hint, which helps clarify that latitude/longitude are required but does not enrich the optional unit or timezone parameters beyond the schema.
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 uses a specific verb and resource: 'Get the current weather conditions' for a given latitude/longitude. The word 'current' cleanly distinguishes it from sibling get_weather_forecast, and the coordinate-based scope distinguishes it from geocode_location.
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?
It explicitly tells the agent to call geocode_location first when only a place name is available, which is clear routing guidance. It does not explicitly mention when to choose get_weather_forecast, but the term 'current' implies that boundary reasonably well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a multi-day hourly and/or daily weather forecast (up to 16 days) for a specific latitude/longitude. Use geocode_location first if you only have a place name. Defaults to a useful set of daily summary variables; pass include_hourly=true for hour-by-hour detail as well.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude in decimal degrees | |
| timezone | No | Timezone for returned timestamps, e.g. 'America/New_York' or 'auto' to infer from coordinates | auto |
| longitude | Yes | Longitude in decimal degrees | |
| forecast_days | No | Number of forecast days to return (1-16, default 7) | |
| include_hourly | No | Whether to also include hourly detail (default: daily summary only) | |
| wind_speed_unit | No | Unit for wind speed values | kmh |
| temperature_unit | No | Unit for temperature values | celsius |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains the default behavior (daily summary variables), how to opt into hourly detail, the 16-day limit, and the prerequisite of having coordinates. It does not mention error conditions, rate limits, or exact return contents, but for a read-only forecast fetch the core behavior is transparent.
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?
Three concise sentences front-load the core purpose, then add routing guidance and default behavior. Every sentence earns its place without unnecessary detail or repetition.
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?
The description is complete enough for a straightforward forecast tool: it covers purpose, coordinate requirement, geocoding prerequisite, forecast length, granularity, and default behavior. There is no output schema, and the 'useful set of daily summary variables' is not enumerated, but the core invocation context is well covered.
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?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds meaningful context for include_hourly and the 16-day maximum, but it does not substantially enhance the parameter semantics beyond what the schema provides, so the baseline of 3 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 states a specific verb-resource pair ('Get a multi-day ... weather forecast') with explicit scope (latitude/longitude, up to 16 days). It clearly distinguishes this from the sibling tools by emphasizing multi-day forecast versus geocoding or current weather.
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?
It explicitly instructs to use geocode_location first when only a place name is available, which is strong routing guidance. It does not explicitly contrast with get_current_weather, but 'multi-day forecast' versus 'current weather' is a clear implied distinction. Lacks an explicit when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0geocode_locationget_current_weatherget_weather_forecastEach tool has a clearly distinct purpose: geocoding converts place names to coordinates, while the other two retrieve weather data. The current weather and forecast tools are differentiated by time horizon and description.
All tool names follow a consistent snake_case verb_noun pattern: geocode_location, get_current_weather, get_weather_forecast. The naming style is uniform and predictable.
With 3 tools, the server is tightly scoped for its purpose: location resolution, current conditions, and forecast. Each tool earns its place and the count feels complete without redundancy.
The core weather lookup flow is fully covered: geocode a place name, get current conditions, or get a forecast. Minor gaps exist such as historical weather data or alerts, but these are not essential for the apparent primary use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Worldwide place search with coordinates (Open-Meteo) — paid per call (x402/credits), 1 tools
Get current weather for any city and create images from your prompts. Streamline planning, reports…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/clarehancock/open-meteo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server