Ein kleiner MCP-Server (Model Context Protocol), der einem KI-Assistenten wie Claude die Möglichkeit gibt, echte Wetterdaten abzurufen — aktuelle Bedingungen und Vorhersagen —, indem er die kostenlose Open-Meteo-API kapselt. Kein API-Schlüssel erforderlich.
Als Lernprojekt erstellt, um zu verstehen, wie MCP-Server Ende-zu-Ende funktionieren: Tools definieren, sie lokal ausführen und sie mit einem echten KI-Client verbinden.
Sobald es mit einem MCP-kompatiblen Client (wie Claude) verbunden ist, stellt es drei Tools bereit:
Tool | Funktion |
| Wandelt einen Ortsnamen („London") in Koordinaten um |
| Aktuelle Temperatur, Wind, Niederschlag usw. für eine Koordinate |
| Bis zu einer 16-Tage-Vorhersage (täglich und/oder stündlich) für eine Koordinate |
So kann eine Person einen Assistenten fragen: „Wie wird das Wetter morgen in Lissabon?" und der Assistent ruft diese Tools selbst auf, um es herauszufinden und zu antworten — er ist nicht mit Wetterdaten vorprogrammiert, sondern holt sie live ab.
Related MCP server: Weather MCP Server
src/server.ts — defnert die drei Tools und wie jedes einzene die Open-Meteo-API aufruft. Dies ist das eigentliche „Gehirn“ des Servers.
src/index.ts — fürt den Server über stdio (Standardeingabe/-ausgabe) aus. Dies ist der Transport, der von lokalen Entwicklungswerkzeugen wie dem MCP Inspector und von Desktop-Apps verwendet wird, die den Server als Unterprozess starten.
src/http.ts — fürt den gleichen Server über Streamable HTTP aus, sodass er über das Netzwerk erreichbar ist — z. B. wenn er irgendwo gehostet wird oder von einem browserbasierten Client aus erreicht werden kann. Das macht es möglisch, eine Demo vorzuführen, ohne lokal etwass zu installieren.
Beide Einstiegspunkte teilen sich dieselben Tool-Definitionen in server.ts, sodass es nur eine Stelle gibt, an der die eigentliche Logik lebt.
npm install
npm run buildLokaler/stdio-Modus (für Tools, die den Server als Unterprozess starten):
npm startHTTP-Modus (zum Verbinden eines entfernten Clients, z. B. über einen weitergeleiteten Codespaces-Port oder einen Hosting-Anbieter):
node build/http.jsDies startet einen einfachen HTTP-Server auf Port 3000 (konfigurierbar über PORT) mit einem einzelen MCP-Endpunkt unter POST /mcp sowie einem GET /health-Check.
Der CLI-Modus des MCP Inspector ist der schnellste Weg, es direkt vom Terminal aus zu testen, ohne Browser:
# 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: Verweisen Sie in der Konfiguration des Clients auf build/index.js als stdio-MCP-Server.
Claude.ai custom connectors: Verweisen Sie auf die /mcp-URL einer laufenden HTTP-Instanz (erfordert einen Plan, der benutzerdefinierte Connectors erlaubt).
Anthropic API direkt: Übergeben Sie die /mcp-URL im Parameter mcp_servers einer /v1/messages-Anfrage — so kann jede benutzerdefinierte App oder Seite die Tools nutzen, ohne einen vorgefertigten MCP-Client zu benötigen.
Open-Meteo bietet weitaus mehr Variablen und Endpunkte, als dieses Projekt nutzt (Luftqualität, Meeresvorhersagen, historische/Archivdaten, Ensembles). Um weitere hinzuzufügen, folgen Sie dem Muster eines vorhandenen Tools in src/server.ts — registrieren Sie einen neuen server.tool(...)-Block mit einem eigenen Eingabeschema und der Open-Meteo-Anfrage.
Daten © 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.
v1.0.0geocode_locationget_current_weatherget_weather_forecastScored across 3 tools
Each 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.
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
Current weather and forecast lookup as an agent tool.
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…