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., "@Weather MCP Server what's the weather forecast for Tokyo 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.
基于 Open-Meteo API 的 MCP (Model Context Protocol) 天气服务器，为 LLM 大模型提供实时天气查询功能。
支持中英文城市名称查询
自动地理编码（城市名→坐标）
获取7天天气预报
详细的天气信息包括：
温度: 最高/最低温度、体感温度
风力: 风速、阵风、风向
舒适度: 基于温度和湿度的舒适度评估
天气状况: 晴、雨、雪等详细描述
降水信息: 降水量、降雨量、降雪量
其他: 日出日落时间、湿度等
Related MCP server: MCP Weather Server
npm install在 Claude Desktop 或其他 MCP 客户端的配置文件中添加：
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"weather": {
"command": "node",
"args": ["/Users/wanli/.config/mcp/weather-mcp-metro/index.js"]
}
}
}npm start服务器提供了一个工具 get_weather，可以通过以下方式调用：
请帮我查询北京的天气或
What's the weather like in Shanghai?获取指定城市的天气预报信息。
参数:
city (string, 必需): 城市名称，支持中英文
返回示例:
{
"城市信息": {
"名称": "Beijing",
"国家": "China",
"坐标": "39.9075, 116.39723",
"时区": "Asia/Shanghai"
},
"当前天气": {
"时间": "2025-10-17T10:00",
"温度": "18°C",
"体感温度": "16°C",
"湿度": "65%",
"天气状况": "部分多云",
"风速": "12 km/h",
"风向": "东北",
"舒适度": "舒适"
},
"七天预报": [
{
"日期": "2025-10-17",
"最高温度": "22°C",
"最低温度": "14°C",
"天气状况": "部分多云",
"降水量": "0mm",
"降雨量": "0mm",
"降雪量": "0cm",
"最大风速": "15 km/h",
"最大阵风": "25 km/h",
"主导风向": "东",
"日出": "2025-10-17T06:30",
"日落": "2025-10-17T18:15",
"舒适度": "舒适"
}
// ... 其余6天
]
}地理编码 API: https://geocoding-api.open-meteo.com/v1/search
天气数据 API: https://api.open-meteo.com/v1/forecast
temperature_2m_max/min: 最高/最低温度
weathercode: 天气代码（自动转换为中文描述）
precipitation_sum: 总降水量
rain_sum: 降雨量
snowfall_sum: 降雪量
windspeed_10m_max: 最大风速
windgusts_10m_max: 最大阵风
winddirection_10m_dominant: 主导风向
sunrise/sunset: 日出日落时间
relative_humidity_2m: 相对湿度
apparent_temperature: 体感温度
基于体感温度和湿度计算：
非常寒冷 (< 0°C)
寒冷 (0-10°C)
凉爽 (10-16°C)
舒适 (16-24°C)
温暖 (24-28°C)
炎热 (28-32°C)
酷热 (> 32°C)
同时考虑湿度影响（高湿度/干燥提示）
@modelcontextprotocol/sdk: MCP SDK
MIT
Open-Meteo API 是免费开源的，无需 API 密钥
数据更新频率取决于 Open-Meteo 服务
建议合理使用，避免过于频繁的请求
获取指定城市的天气预报信息。支持1-16天的天气预报，包括温度、风力、舒适度、降雨降雪、紫外线指数、PM2.5等详细信息。
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | 城市名称，可以是中文或英文，例如：北京、Shanghai、New York等 | |
| days | No | 预报天数，范围1-16天，默认7天 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the forecast range and data types but lacks details on error handling, rate limits, authentication needs, or response format. For a tool with no annotations, this leaves significant behavioral gaps, though it does add some context about the forecast capabilities.
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 a single, efficient sentence that front-loads the core purpose and includes relevant details without unnecessary elaboration. Every part contributes to understanding the tool's functionality, though it could be slightly more structured for clarity.
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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and data types well but lacks details on behavioral aspects like error handling or response structure, which are important for a weather API tool with no annotations to guide the agent.
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%, with clear documentation for both parameters (city and days). The description adds minimal value beyond the schema by implying the 'days' parameter relates to the 1-16 day forecast range mentioned, but it does not provide additional syntax or format details. This meets the baseline for high schema coverage.
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 specific action ('获取...天气预报信息' - get weather forecast information) and resource ('指定城市' - specified city). It distinguishes the tool by detailing the comprehensive data returned (temperature, wind, comfort level, precipitation, UV index, PM2.5, etc.) and the 1-16 day forecast range, making its purpose explicit and well-defined.
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 implies usage by specifying the forecast range (1-16 days) and the types of information provided, but it does not explicitly state when to use this tool versus alternatives. Since there are no sibling tools mentioned, the lack of comparative guidance is less critical, but no explicit prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as fetching weather forecasts for a specified city.
The single tool name 'get_weather' follows a clear verb_noun pattern. Since there are no other tools to compare, consistency is inherently perfect.
A single tool is too few for a weather server, as it lacks operations like searching locations, getting historical data, or setting preferences. This minimal set limits functionality and may cause agent failures in broader weather-related tasks.
The server is severely incomplete for a weather domain. It only provides forecast retrieval, missing essential operations such as current conditions, alerts, location search, or multi-city queries, which are standard in weather APIs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time weather conditions and multi-day forecasts via Open-Meteo — free, no API key required
Global weather via Open-Meteo: forecast, ERA5 archive, marine, air quality, geocoding, elevation.
Free, keyless real-time weather and 7-day forecasts for any city worldwide.
Get current weather for any city and create images from your prompts. Streamline planning, reports…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ctermiii/weather-mcp-metro'
If you have feedback or need assistance with the MCP directory API, please join our Discord server