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., "@MCP Weather Server get the forecast for London for the next 3 days"
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.
A weather query MCP server based on FastMCP, providing current weather, future forecasts, Celsius/Fahrenheit conversion, popular city resources, and travel weather advice prompts.
The project includes two entry points:
server.py: Local stdio mode, suitable for local MCP clients like Claude Desktop, Cursor, and Cherry Studio.
server_remote.py: Streamable HTTP mode, suitable for deployment to remote hosting platforms like ModelScope.
get_weather(city: str): Query current weather for a specified city.
get_forecast(city: str, days: int = 3): Query future weather forecast for a specified city, default is 3 days.
temperature_convert(value: float, from_unit: str): Convert between Celsius and Fahrenheit.
weather://cities: Returns a resource list of common cities.
travel_advisor(destination: str, date: str): Generate a travel weather advice prompt.
Weather data is provided by wttr.in, no additional API tokens required.
Related MCP server: weather-mcp-server
Python >= 3.12
It is recommended to use uv for dependency management
uv syncIf you are not using uv, you can also install dependencies in a virtual environment:
pip install "mcp[cli]>=1.27.0" "httpx>=0.28.1"stdio mode:
uv run python server.pyMCP client configuration example:
{
"mcpServers": {
"weather-server": {
"command": "uv",
"args": ["run", "python", "server.py"]
}
}
}Streamable HTTP mode:
uv run python server_remote.pyDefault listening on:
http://0.0.0.0:8000/mcp/Remote MCP client configuration example:
{
"mcpServers": {
"weather-server": {
"url": "http://127.0.0.1:8000/mcp/"
}
}
}When creating or deploying an MCP Server on ModelScope, you can enter the GitHub repository address of this project and use the remote entry file:
python server_remote.pyThe service will start in Streamable HTTP mode, listening on 0.0.0.0:8000, with the MCP endpoint at:
/mcp/If the platform supports custom startup commands, it is recommended to use:
uv run python server_remote.pyOr use it after installing dependencies in the platform environment beforehand:
python server_remote.py.
├── README.md
├── pyproject.toml
├── server.py
├── server_remote.py
└── uv.lockIf you need to release it as open source, please add a License file according to your actual situation.
获取指定城市未来几天的天气预报。
参数：
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
Open-Meteo tabanlı anahtarsız hava durumu tahmin MCP sunucusu.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/liusicheng/mcp-weather'
If you have feedback or need assistance with the MCP directory API, please join our Discord server