一个基于 FastMCP 的天气查询 MCP Server，提供当前天气、未来天气预报、摄氏度/华氏度转换、热门城市资源和旅行天气建议 Prompt。
项目包含两个启动入口：
server.py：本地 stdio 模式，适合 Claude Desktop、Cursor、Cherry Studio 等本地 MCP 客户端。
server_remote.py：Streamable HTTP 模式，适合部署到 ModelScope 等远程托管平台。
get_weather(city: str)：查询指定城市当前天气。
get_forecast(city: str, days: int = 3)：查询指定城市未来天气预报，默认 3 天。
temperature_convert(value: float, from_unit: str)：摄氏度与华氏度互转。
weather://cities：返回常用城市列表资源。
travel_advisor(destination: str, date: str)：生成旅行天气咨询 Prompt。
天气数据来自 wttr.in，无需额外 API Token。
Related MCP server: weather-mcp-server
Python >= 3.12
推荐使用 uv 管理依赖
uv sync如果不使用 uv，也可以在虚拟环境中安装依赖：
pip install "mcp[cli]>=1.27.0" "httpx>=0.28.1"stdio 模式：
uv run python server.pyMCP 客户端配置示例：
{
"mcpServers": {
"weather-server": {
"command": "uv",
"args": ["run", "python", "server.py"]
}
}
}Streamable HTTP 模式：
uv run python server_remote.py默认监听：
http://0.0.0.0:8000/mcp/远程 MCP 客户端配置示例：
{
"mcpServers": {
"weather-server": {
"url": "http://127.0.0.1:8000/mcp/"
}
}
}在 ModelScope 创建或部署 MCP Server 时，可填写本项目的 GitHub 仓库地址，并使用远程入口文件：
python server_remote.py服务会以 Streamable HTTP 方式启动，监听 0.0.0.0:8000，MCP endpoint 为：
/mcp/如果平台支持自定义启动命令，建议使用：
uv run python server_remote.py或在平台环境中提前安装依赖后使用：
python server_remote.py.
├── README.md
├── pyproject.toml
├── server.py
├── server_remote.py
└── uv.lock如需开源发布，请根据实际情况补充 License 文件。
获取指定城市未来几天的天气预报。
参数：
city: 城市名称（英文）
days: 预报天数，默认 3 天，最多 3 天
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that city must be in English and days max is 3, but does not mention read-only nature, error handling, or output format. Basic constraints are provided but deeper behavior is missing.
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 highly concise, using a short paragraph with bullet points. Every sentence adds necessary information without redundancy.
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 tool with two parameters and no output schema, the description covers input constraints adequately. However, it omits what the response contains, which would be helpful for an agent invoking the tool.
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 0%, so the description adds value by specifying city format (English) and days limit (max 3). This compensates for missing schema descriptions, though more details on valid values would help.
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 it retrieves weather forecasts for a specified city over a number of days. However, it does not differentiate from the sibling tool 'get_weather', leaving ambiguity about when to use each.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_weather' or 'temperature_convert'. The description lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定城市的当前天气信息。
参数：
city: 城市名称（英文），如 Beijing、Tokyo、London
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the core functionality without disclosing behavioral traits such as rate limits, data source, units, or error handling. This is insufficient for a tool with no annotations.
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 concise, front-loaded with the action, and uses a clear bullet-style parameter list. Every sentence adds value without unnecessary words.
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 tool with one parameter and no output schema, the description covers the essential purpose and parameter format. However, missing details like output format (e.g., temperature, units) slightly reduce completeness.
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 description adds meaning beyond the input schema by specifying that the city name must be in English (e.g., Beijing, Tokyo, London). The schema only defines 'city' as a string with no further info, so this guidance is valuable.
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 '获取指定城市的当前天气信息' (get current weather for a specified city), which is a specific verb+resource combination. It distinguishes from siblings 'get_forecast' and 'temperature_convert' by focusing on 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?
The description implies usage for current weather queries with city name in English, but does not explicitly state when to use this tool vs. alternatives like 'get_forecast' or 'temperature_convert'. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
摄氏度与华氏度互相转换。
参数：
value: 温度数值
from_unit: 原始单位，C 表示摄氏度，F 表示华氏度
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| from_unit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It correctly identifies a pure conversion function with no side effects. It does not mention any limitations (e.g., no time-related inputs), but the behavior is straightforward and well-described.
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 extremely concise: one sentence for purpose and a simple list for parameters. Every word adds value, and the structure is front-loaded with the core action.
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 simplicity (two parameters, no output schema, no nested objects), the description is fully complete. It explains what the tool does, what inputs are needed, and how to use them. No additional context is required.
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 0%, so the description must compensate. It explains 'value' as numeric temperature and 'from_unit' as 'C' or 'F'. While it does not specify case sensitivity or exact valid values, it adds sufficient meaning beyond the raw JSON 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 explicitly states '摄氏度与华氏度互相转换' (converts between Celsius and Fahrenheit), using a specific verb and resource. It clearly distinguishes from sibling tools like get_forecast and get_weather, which are weather data services.
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 provides clear parameter explanations but does not explicitly state when to use this tool versus alternatives. However, given the sibling tools are about weather forecasts, the conversion context is clear enough for an AI to infer appropriate usage.
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.
v0.1.0get_forecastget_weathertemperature_convertScored across 3 tools
Each tool has a clearly distinct purpose: get_forecast for future days, get_weather for current conditions, and temperature_convert for unit conversion. No overlap exists.
All tools use snake_case, but two follow verb_noun pattern (get_forecast, get_weather) while one uses noun_verb (temperature_convert), a minor inconsistency.
3 tools is slightly below average for a weather server, but still reasonable for core functionality (current, forecast, conversion). The count feels lean but not insufficient.
Covers basic current weather and forecast, plus a unit converter. Missing features like alerts or historical data, but the essential weather information needs are met.
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
An MCP server for weather information by @kulybaba
An MCP server for weather information by @kulybaba
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.