ClaudeのようなAIアシスタントに、実際の気象データ（現在の状況と予報）を調べる機能を提供する、小さなMCP（Model Context Protocol）サーバーです。無料のOpen-Meteo APIをラップしています。APIキーは不要です。
エンドツーエンドでMCPサーバーの仕組みを理解するための学習プロジェクトとして作られました。ツールの定義、ローカルでの実行、実際のAIクライアントへの接続までを扱います。
MCP互換クライアント（Claudeなど）に接続すると、次の3つのツールを公開します：
ツール | 機能 |
| 場所の名前（"London"）を座標に変換する |
| 座標に対する現在の気温、風、降水量など |
| 座標に対する最大16日間の予報（日次/時間別、またはその両方） |
つまり、ユーザーがアシスタントに「明日のリスボンの天気は？」と尋ねると、アシスタントはこれらのツールを自ら呼び出して調べ、答えることができます。天気データがあらかじめプログラムされているわけではなく、リアルタイムで取得します。
Related MCP server: Weather MCP Server
src/server.ts — 3つのツールと、各ツールがOpen-Meteo APIを呼び出す方法を定義します。サーバーの実際の「頭脳」にあたる部分です。
src/index.ts — stdio（標準入出力）でサーバーを実行します。これは、MCP Inspectorのようなローカル開発ツールや、サーバーをサブプロセスとして起動するデスクトップアプリで使用されるトランスポートです。
src/http.ts — 同じサーバーをStreamable HTTPで実行します。ネットワーク経由で到達できるようになります（例：どこかにホストする、ブラウザベースのクライアントからアクセスする）。ローカルに何もインストールせずにデモができるのはこのためです。
両方のエントリポイントはserver.tsの同じツール定義を共有するため、実際のロジックは一箇所にのみ存在します。
npm install
npm run buildローカル/stdioモード（サーバーをサブプロセスとして起動するツール向け）：
npm startHTTPモード（リモートクライアントを接続する場合、例：転送されたCodespacesポートやホスティングプロバイダ経由）：
node build/http.jsこれにより、ポート3000（PORTで設定可能）でプレーンなHTTPサーバーが起動し、POST /mcpに単一のMCPエンドポイント、さらにGET /healthのヘルスチェックが用意されます。
ブラウザ不要でターミナルから直接試すには、MCP InspectorのCLIモードが最速です：
# 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: クライアントの設定で、build/index.jsをstdio MCPサーバーとして指定します。
Claude.aiカスタムコネクタ: 実行中のHTTPインスタンスの/mcp URLを指定します（カスタムコネクタを利用できるプランが必要です）。
Anthropic API直接: /v1/messagesリクエストのmcp_serversパラメータに/mcp URLを渡します。これにより、事前に構築されたMCPクライアントを必要とせず、任意のカスタムアプリやページでツールを使用できます。
Open-Meteoには、このプロジェクトが使用しているもの以外にも、多くの変数とエンドポイントがあります（大気質、海洋予報、履歴/アーカイブデータ、アンサンブルなど）。さらに追加するには、src/server.ts内の既存ツールのパターンに従って、独自の入力スキーマとOpen-Meteoリクエストを持つ新しいserver.tool(...)ブロックを登録してください。
データ © 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…