Click on "Deploy 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., "@OpenWeather-OneCall3-MCP What's the current weather in Tokyo?"
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.
一个基于 Model Context Protocol (MCP) 的服务器，使用 OpenWeather One Call API 3.0 提供天气数据。该服务器允许 AI 智能体（如 Claude Desktop）获取任何地点的当前天气、天气预报和历史天气数据。
A Model Context Protocol (MCP) server that provides weather data using the OpenWeather One Call API 3.0. This server allows AI agents (like Claude Desktop) to access current weather, forecasts, and historical weather data for any location.
当前天气与预报 | Current & Forecast: 获取详细的当前天气状况和每日/每小时天气预报。Get detailed current weather and daily/hourly forecasts.
时间机器 | Time Machine: 获取特定时间戳的历史天气数据。Retrieve historical weather data for specific timestamps.
地理编码 | Geocoding: 内置工具，支持按名称（如"伦敦"、"东京"）搜索地点。Built-in tool to search for locations by name (e.g., "London", "Tokyo").
本地执行 | Local Execution: 通过 Stdio 本地运行，确保您的 API 密钥安全保存在本地机器上。Runs locally via Stdio, keeping your API keys secure on your machine.
Related MCP server: mcp-weather
Node.js: 版本 16 或更高。Version 16 or higher.
OpenWeather API 密钥 | OpenWeather API Key: 需要一个具有 "One Call API 3.0" 订阅的密钥。在此获取。You need a key with "One Call API 3.0" subscription. Get one here.
克隆此仓库 | Clone this repository:
git clone https://github.com/your-username/openweather-mcp.git
cd openweather-mcp安装依赖 | Install dependencies:
npm install构建项目 | Build the project:
npm run build发布到 NPM 后，用户可以使用 npx 运行服务器，无需手动下载代码或配置路径。
Once published to NPM, users can run the server without manually downloading code or configuring paths using npx.
{
"mcpServers": {
"openweather": {
"command": "npx",
"args": ["-y", "openweather-one-call-3.0-mcp"],
"env": {
"OPENWEATHER_API_KEY": "your_api_key_here"
}
}
}
}如果从源码本地运行：
If running locally from source:
{
"mcpServers": {
"openweather": {
"command": "node",
"args": ["C:/Absolute/Path/To/openweather-mcp/dist/index.js"],
"env": {
"OPENWEATHER_API_KEY": "your_api_key_here"
}
}
}
}get_current_weather获取指定地点的当前天气和预报。Fetch current weather and forecast for a location.
参数 | Args: lat（数字，纬度 | number），lon（数字，经度 | number），exclude（数组，可选 | array, optional）
get_weather_history获取特定时间的历史天气。Fetch historical weather for a specific time.
参数 | Args: lat（数字，纬度 | number），lon（数字，经度 | number），dt（Unix 时间戳 | unix timestamp）
get_coordinates_from_location搜索城市或行政区域以获取坐标。Search for a city or administrative area to get coordinates.
参数 | Args: query（字符串，搜索查询 | string）
MIT
Retrieve latitude and longitude for a given city or administrative area name. Use this when you need coordinates (lat/lon) for a place.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (default 5) | |
| query | Yes | City or administrative area name, state code (optional), country code (optional). E.g. 'London', 'New York, NY, US' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the schema. It does not mention that geocoding a name can return multiple matches (consistent with the default limit of 5), what happens on an unresolved or ambiguous query, or whether results are ranked.
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 purpose is front-loaded in one efficient sentence, but the trailing 'use this when...' clause largely duplicates it and earns little of its space. No structural problems otherwise.
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 read-only lookup with a fully documented two-parameter schema, the description is nearly sufficient. However, with no annotations and no output schema, it should have clarified that multiple coordinate candidates may be returned and in what order.
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%, and the schema already documents both 'query' (with examples) and 'limit' (default 5). The description adds no syntax, disambiguation, or ranking details beyond what the schema states, so the baseline 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 first sentence names a specific verb (retrieve) plus the exact resource (latitude and longitude) and the accepted input (city or administrative area name). It is unmistakably distinct from the sibling weather tools, so an agent can select it without opening the schema.
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 second sentence ('Use this when you need coordinates for a place') gives an implied usage context, but it is essentially a restatement of the purpose. There are no when-not conditions, no mention of alternatives, and no guidance on handling ambiguous place names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current weather and forecast for a specific location (lat/lon). Returns current weather, daily forecast for 8 days, and hourly forecast for 48 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude | |
| lon | Yes | Longitude | |
| exclude | No | Parts of weather data to exclude |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully discloses the return payload (current conditions, 8-day daily, 48-hour hourly), which tells the agent what it will get back. However, it omits any auth, rate-limit, or data-refresh context, so it only partially covers the behavioral profile.
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 tight sentences with zero waste; the location constraint is front-loaded and the return scope follows immediately.
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?
With no output schema, the description usefully explains the return contents, which is the key missing structured data. The only gap is the undocumented exclusion behavior and any location-vs-coordinate prerequisite, but overall it is sufficient to call the tool correctly.
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 lat, lon, and exclude are all documented in the schema. The description restates lat/lon meaning but adds no syntax or format detail and never mentions the exclude filtering capability. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb and resource ('Get current weather and forecast') and scopes it to a lat/lon location, which implicitly sets it apart from get_coordinates_from_location. It is clear but does not explicitly name the sibling tools it should be chosen over.
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 '(lat/lon)' qualifier implies you must already have coordinates, hinting that get_coordinates_from_location is a prerequisite step, but this is left to inference. There is no explicit statement of when to prefer this over get_weather_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical weather data for a specific timestamp (Time Machine).
| Name | Required | Description | Default |
|---|---|---|---|
| dt | Yes | Timestamp (Unix time, UTC) | |
| lat | Yes | Latitude | |
| lon | Yes | Longitude |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose read-only nature explicitly, data availability limits, historical range boundaries, or response shape — all relevant for a history endpoint.
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?
A single front-loaded sentence with no waste. The '(Time Machine)' parenthetical is unexplained jargon, a minor blemish on otherwise tight phrasing.
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 three-parameter read tool with a fully covered schema, this is minimally viable. With no annotations and no output schema, the missing historical-range and return-format context leaves a gap an agent would notice.
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 lat, lon, and dt are already documented in the schema. The description adds only the qualifier that the timestamp selects a historical point; the '(Time Machine)' tag adds no semantic value.
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 verb (Get) and resource (historical weather data) plus the scoping constraint (a specific timestamp). It implicitly contrasts with the sibling get_current_weather via 'historical', but does not name or differentiate against it explicitly.
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?
Usage is implied: use this when you need weather for a past timestamp rather than the current conditions. There is no explicit when-to-use, when-not-to-use, or named alternative (get_current_weather) to route the agent.
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.1get_coordinates_from_locationget_current_weatherget_weather_historyScored across 3 tools
Each tool targets a distinct part of the weather API: current/forecast, historical time machine, and geocoding. There is no overlapping purpose, so an agent can easily select the right tool.
All three tools use a consistent get_ prefix with snake_case noun phrases. The pattern is predictable and readable across the set.
Three tools are well-scoped for a weather API wrapper, covering geocoding, current conditions with forecast, and historical data. Each tool earns its place without redundancy.
Core read operations are covered: geocoding, current/forecast, and historical weather. Minor gaps exist such as reverse geocoding, direct query by city name without a separate geocode step, or weather alerts/minutely data, but agents can work around these.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
OpenWeather MCP — wraps the OpenWeatherMap API (openweathermap.org)
