Un pequeño servidor MCP (Model Context Protocol) que da a un asistente de IA como Claude la capacidad de consultar datos meteorológicos reales — condiciones actuales y pronósticos — envolviendo la API gratuita de Open-Meteo. No se requiere clave de API.
Construido como un proyecto de aprendizaje para entender cómo funcionan los servidores MCP de principio a fin: definir herramientas, ejecutarlas localmente y conectarlas a un cliente de IA real.
Una vez conectado a un cliente compatible con MCP (como Claude), expone tres herramientas:
Herramienta | Qué hace |
| Convierte un nombre de lugar («Londres») en coordenadas |
| Temperatura, viento, precipitación, etc. actuales para una coordenada |
| Pronóstico de hasta 16 días (diario y/o por horas) para una coordenada |
Así, una persona puede preguntarle a un asistente «¿qué tiempo hará en Lisboa mañana?» y el asistente llamará él mismo a estas herramientas para averiguarlo y responder — no está preprogramado con datos meteorológicos, los obtiene en tiempo real.
Related MCP server: Weather MCP Server
src/server.ts — define las tres herramientas y cómo cada una llama a la API de Open-Meteo. Este es el «cerebro» real del servidor.
src/index.ts — ejecuta el servidor a través de stdio (entrada/salida estándar). Este es el transporte que usan las herramientas de desarrollo locales como el MCP Inspector y las aplicaciones de escritorio que lanzan el servidor como subproceso.
src/http.ts — ejecuta el mismo servidor a través de Streamable HTTP, de modo que se puede acceder a él por red — p. ej. alojado en algún sitio o desde un cliente basado en navegador. Esto es lo que hace posible hacer una demo sin instalar nada localmente.
Ambos puntos de entrada comparten las mismas definiciones de herramientas en server.ts, de modo que la lógica real vive en un solo lugar.
npm install
npm run buildModo local/stdio (para herramientas que lanzan el servidor como subproceso):
npm startModo HTTP (para conectar un cliente remoto, p. ej. a través de un puerto reenviado de Codespaces o un proveedor de alojamiento):
node build/http.jsEsto inicia un servidor HTTP simple en el puerto 3000 (configurable mediante PORT) con un único endpoint MCP en POST /mcp, además de una comprobación GET /health.
El modo CLI del MCP Inspector es la forma más rápida de probarlo directamente desde una terminal, sin necesidad de navegador:
# 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: apunta a build/index.js como servidor MCP stdio en la configuración del cliente.
Conectores personalizados de Claude.ai: apunta a la URL /mcp de una instancia HTTP en ejecución (requiere un plan que permita conectores personalizados).
API de Anthropic directamente: pasa la URL /mcp en el parámetro mcp_servers de una solicitud /v1/messages — esto permite que cualquier aplicación o página personalizada use las herramientas sin necesidad de un cliente MCP previamente construido.
Open-Meteo tiene muchas más variables y endpoints de los que usa este proyecto (calidad del aire, pronósticos marinos, datos históricos/de archivo, ensembles). Para añadir más, sigue el patrón de una herramienta existente en src/server.ts — registra un nuevo bloque server.tool(...) con su propio esquema de entrada y la solicitud a Open-Meteo.
Datos © 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.
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…
Current weather and forecasts for any coordinates, backed b… — paid per call (x402/credits), 1 tools