FastMCPベースの天気検索MCPサーバーで、現在の天気、今後の天気予報、摂氏/華氏の変換、人気都市のリソース、および旅行の天気アドバイス用プロンプトを提供します。
プロジェクトには2つの起動エントリーポイントが含まれています：
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)：旅行の天気アドバイス用プロンプトを生成します。
天気データは wttr.in から取得しており、追加のAPIトークンは不要です。
Related MCP server: weather-mcp-server
Python >= 3.12
依存関係の管理には uv を推奨します
uv syncuv を使用しない場合は、仮想環境で依存関係をインストールすることも可能です：
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リポジトリURLを入力し、リモート用のエントリーファイルを使用してください：
python server_remote.pyサービスはStreamable HTTP方式で起動し、0.0.0.0:8000 をリッスンします。MCPエンドポイントは以下の通りです：
/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.