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 what's the weather in Lisbon this week?"
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.
An MCP server that gives any MCP client weather forecasts and current conditions for any city, backed by the free Open-Meteo API — no API key, no account.
Requires Node 18 or newer. Nothing else — there is no API key and no configuration.
git clone https://github.com/jyotsna1357/open-meteo-mcp.git
cd open-meteo-mcp
npm install
npm run buildRelated MCP server: Weather MCP Server
Connect it to Claude Code (run from the repo root, so $(pwd) resolves to the checkout):
claude mcp add weather -- node "$(pwd)/dist/index.js"Check it registered with claude mcp list, then ask: "What's the weather in Lisbon this week?"
For any other MCP client, add it to that client's config with an absolute path:
{
"mcpServers": {
"weather": {
"command": "node",
"args": ["/absolute/path/to/open-meteo-mcp/dist/index.js"]
}
}
}To run the server directly — it speaks JSON-RPC over stdin/stdout and will sit there waiting for a client, which is the expected behaviour:
npm start # run the built server
npm run dev # run from source, restarts on saveexamples/forecast.mjs starts the server and calls both tools:
import { fileURLToPath } from "node:url";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
const serverPath = fileURLToPath(new URL("../dist/index.js", import.meta.url));
const client = new Client({ name: "forecast-example", version: "1.0.0" });
await client.connect(new StdioClientTransport({ command: "node", args: [serverPath] }));
const forecast = await client.callTool({
name: "get_forecast",
arguments: { city: "Lisbon", days: 3 },
});
console.log(forecast.content[0].text);
await client.close();$ node examples/forecast.mjs
3-day forecast for Lisbon, Lisbon District, Portugal (times in Europe/Lisbon)
Sun 9 Aug — Partly cloudy
High 28.8°C / Low 21.0°C · Rain 0% chance, 0.0 mm · Wind up to 17.7 km/h
Mon 10 Aug — Partly cloudy
High 28.6°C / Low 20.5°C · Rain 0% chance, 0.0 mm · Wind up to 18.2 km/h
Tue 11 Aug — Partly cloudy
High 29.0°C / Low 20.6°C · Rain 0% chance, 0.0 mm · Wind up to 17.4 km/hAnd get_current returns:
Current conditions in Lisbon, Lisbon District, Portugal
As of Sun 9 Aug, 07:30 local time (Europe/Lisbon)
Partly cloudy, 21.1°C
Feels like: 24.2°C
Humidity: 90%
Wind: 3.6 km/h from the W
Precipitation: 0.0 mm in the last hour
Daylight: yesTwo tools:
Tool | Arguments | Returns |
|
| One entry per day: conditions, high/low, chance and amount of rain, peak wind |
|
| Conditions, temperature, feels-like, humidity, wind, recent precipitation |
Both accept a plain city name and resolve it through Open-Meteo's geocoder, so "New York" and "Springfield, United States" both work.
src/
index.ts server setup, stdio transport, signal handling
format.ts WMO weather codes and readable text output
logger.ts stderr-only logging
api/
client.ts fetch with a 10s timeout, schema validation, error mapping
open-meteo.ts geocoding and forecast endpoints, response schemas
errors.ts WeatherError, the one error type raised on purpose
tools/
get-forecast.ts tool definition and Zod input schema
get-current.ts tool definition and Zod input schema
tool-result.ts turns any failure into readable tool content
examples/
forecast.mjs the example aboveEvery failure — an unknown city, a timeout, an upstream outage, a response whose shape changed — comes back as readable text with isError set, never as an empty result or a thrown exception. All logging goes to stderr, because stdout is the transport.
Most MCP examples are either a toy that echoes a string or a large server where the protocol is buried under application code. This is meant to be the thing in between: small enough to read in one sitting, complete enough to copy from. It wraps a real API with real failure modes, so the error handling, input validation, and output formatting are the parts worth stealing.
These are deliberate. The server does not:
Support any unit but metric. Temperatures are °C, wind is km/h, precipitation is mm. There is no unit parameter.
Disambiguate city names. The geocoder's top match wins, which is usually the most populous. Ask for "Springfield, United States" if the bare name is ambiguous — the resolved location is always named in the output, so you can tell when it guessed wrong.
Forecast beyond 7 days. Open-Meteo itself offers up to 16; this caps at 7.
Provide hourly data. Forecasts are daily aggregates. Current conditions are a single reading, and its precipitation figure covers the preceding hour.
Cache anything. Every tool call hits the network. Open-Meteo's free tier is generous but rate-limited and non-commercial — check their terms before putting this in front of real traffic.
Retry failed requests. One attempt, 10-second timeout, then an error explaining what happened. Retrying is the caller's decision.
Geocode in languages other than English. The geocoder is queried with language=en.
Speak any transport but stdio. No HTTP or SSE.
Also out of scope on purpose: authentication, Docker, a test suite, and a Python port.
MIT — see LICENSE.
Find out what the weather is like in a city right now. Use this for questions about the present moment — whether it is raining, how warm it is, whether someone needs a jacket before heading out. You get the conditions, temperature and what it feels like, humidity, wind, and recent precipitation, measured at the city's local time. If you need tomorrow or the days after, use get_forecast instead.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The city to look up, written the way a person would say it — "Lisbon", "New York", or "Springfield, United States" when the name alone is ambiguous. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states what output to expect (conditions, temperature, feels-like, humidity, wind, recent precipitation) and notes that measurements are 'measured at the city's local time.' It does not mention error handling or units, but for a simple read-only weather tool, it provides sufficient transparency.
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 three sentences, each earning its place: purpose, what you get, and when to use an alternative. It is front-loaded with the main action and avoids fluff.
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?
For a simple one-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers what data is returned, when to use the tool, and the alternative for other time frames. No critical information seems missing.
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% — the 'city' parameter has a detailed description ('written the way a person would say it'). The tool description adds no extra parameter information, so the baseline of 3 applies.
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: 'Find out what the weather is like in a city right now.' It specifies the resource (city weather) and the verb (find out/get current), and explicitly distinguishes from the sibling by advising 'If you need tomorrow or the days after, use get_forecast instead.'
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 explicit usage context: 'Use this for questions about the present moment' and gives examples of when it's appropriate. It also names an alternative tool for future forecasts, giving clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the daily weather forecast for a city, for anywhere from 1 to 7 days ahead. Use this when the question is about the future — what tomorrow looks like, whether the weekend will be dry, whether to pack for rain. You get one entry per day with the expected conditions, high and low temperature, chance and amount of rain, and peak wind speed. For conditions at this exact moment, use get_current instead.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The city to look up, written the way a person would say it — "Lisbon", "New York", or "Springfield, United States" when the name alone is ambiguous. | |
| days | No | How many days to forecast, counting today as day one. Open-Meteo covers up to 7 days; ask for 1 if only today matters, 7 for the full range. Leave this out for a general outlook and you get 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it explains the output format (one entry per day with conditions, temps, rain, wind) and the forecast horizon. It doesn't mention potential limitations or side effects, but for a read-only forecast, no such concerns are expected, so this is acceptable.
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 compact and front-loaded. It uses three sentences to cover purpose, usage examples, and the alternative tool, with no filler. Every sentence contributes value.
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 fully compensates for the missing output schema by summarizing the response structure. It also provides semantic context (daily entries, fields) and clear sibling differentiation. For a simple 2-parameter tool with a rich schema, nothing essential is missing.
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 input schema covers 100% of parameters with detailed descriptions. The tool description adds a little extra context about output entries and the usable day range, but it largely reiterates what the schema already conveys, so it doesn't significantly elevate beyond the schema baseline.
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 function ('Look up the daily weather forecast for a city') and scope (1-7 days ahead). It explicitly distinguishes from the sibling tool get_current by directing users there for current conditions, making the purpose unambiguous.
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?
Provides explicit when-to-use guidance with concrete examples ('what tomorrow looks like, whether the weekend will be dry') and names the alternative for real-time conditions ('use get_current instead'). This fully addresses usage context and selection among siblings.
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.0get_currentget_forecastThe two tools are clearly separated by time: get_forecast for future days and get_current for the present moment. Each description explicitly references the other to prevent confusion.
Both tool names follow the exact same verb_noun pattern: get_ + forecast/current. This is perfectly consistent and predictable.
With only 2 tools, the server feels thin but not unusable. For a focused weather-with-current-and-forecast scope, it is borderline acceptable, though a richer API would typically include more.
The two tools cover the primary current and short-term forecast use cases. Missing historical data and weather alerts are notable gaps, but for many queries these tools are sufficient.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server for weather information by @kulybaba
An MCP server for weather information by @kulybaba
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jyotsna1357/open-meteo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server