This server provides weather information for Chinese cities using the AMap/AutoNavi (高德地图) Maps Weather API. It requires an AMAP_API_KEY from the Gaode Open Platform and offers two tools:
get-weather-live: Retrieve real-time weather conditions for a specified city.
get-weather-forecast: Retrieve a weather forecast covering today and the next 3 days for a specified city.
Both tools support flexible city identification via either a city name (e.g., 上海, 北京东城) or a 6-digit adcode (e.g., 310100).
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., "@@xjt-demo/xjt-weather-mcp what's the live weather in Beijing?"
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.
基于 MCP 官方 Weather Server Quickstart 实现的天气 MCP Server，数据源为高德地图天气查询 API，可通过 npx 直接运行，无需本地安装。
在 高德开放平台 注册并创建应用
申请 Web 服务 类型的 API Key
在 MCP 配置中通过环境变量 AMAP_API_KEY 传入 Key
城市编码（adcode）可参考高德城市编码表，例如：
城市 | adcode |
北京东城 |
|
上海 |
|
广州 |
|
深圳 |
|
Related MCP server: amap-weather-mcp-server
Tool | 说明 |
| 查询指定城市的实况天气 |
| 查询指定城市的天气预报（当天 + 未来 3 天） |
两个工具均接受 city 参数：支持城市名称（如 上海、北京东城）或 6 位 adcode（如 310100）。
发布到 npm 后，使用者无需手动安装依赖。npx 会自动下载包及其 dependencies，然后启动 MCP Server。
{
"mcpServers": {
"xjtWeather": {
"command": "npx",
"args": ["-y", "@xjt-demo/xjt-weather-mcp"],
"env": {
"AMAP_API_KEY": "你的高德 Web 服务 Key"
}
}
}
}预发布通道：
{
"mcpServers": {
"xjtWeatherAlpha": {
"command": "npx",
"args": ["-y", "@xjt-demo/xjt-weather-mcp@alpha"],
"env": {
"AMAP_API_KEY": "你的高德 Web 服务 Key"
}
}
}
}npm install
npm run build
AMAP_API_KEY=你的Key npm run dev本地调试配置：
{
"mcpServers": {
"xjtWeatherLocal": {
"command": "node",
"args": ["/path/to/xjt-weather-mcp/dist/server.js"],
"env": {
"AMAP_API_KEY": "你的高德 Web 服务 Key"
}
}
}
}运行集成测试前， 在.env 文件中填入 Key（.env 已被 git 忽略）：
使用 MCP Inspector 调试：
AMAP_API_KEY=你的Key npx @modelcontextprotocol/inspector node dist/server.js本仓库采用 main（稳定）+ alpha（预发布） 双分支策略：
分支 | 用途 | 发布命令 | npm dist-tag | 版本示例 |
| 新功能开发、预发布验证 |
|
|
|
| 稳定版 |
|
|
|
新功能、较大改动：在 alpha 分支开发；需要对外验证时执行 pnpm release:alpha
小 bugfix、文档修正：可直接在 main 修改；发布后同步回 alpha（git checkout alpha && git merge main）
路径 A：新功能（走 alpha）
npm login
git checkout alpha
# 开发、提交后
pnpm release:alpha
# 验证通过后
git checkout main
git merge alpha
pnpm release:stable路径 B：紧急修复（走 main）
git checkout main
# 修复、提交后
pnpm release:stable
# 同步到 alpha
git checkout alpha
git merge main变更类型 | 版本 | 示例 |
Bug 修复 | PATCH |
|
新功能（向后兼容） | MINOR |
|
破坏性变更 | MAJOR |
|
仅发布配置 / 文档 | 不发版 | — |
npx @xjt-demo/xjt-weather-mcp # latest（稳定版）
npx @xjt-demo/xjt-weather-mcp@alpha # alpha 预发布版release-it 会在发布前自动执行 typecheck 与 build；仅在对应分支上才能发布（见 .release-it.json / .release-it.alpha.json）。
MIT
获取指定城市的天气预报，包含当天及未来 3 天（高德地图）。支持城市名或 6 位 adcode。
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | 城市名称或 6 位 adcode（例如：上海、北京东城、310100） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the time range (today + 3 days) and data source (Gaode map). However, no annotations are provided, and the description does not mention other behavioral traits such as update frequency, units, or error handling. With no annotations, the description carries the full burden but only partially fulfills it.
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?
Extremely concise: two short sentences that front-load the main purpose and scope. Every word adds value; no redundancy or filler.
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 aspects: input format, output time range, and data source. It is nearly complete, though lacking details on output structure or error conditions. Given the tool's low complexity, this is adequate.
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 description's mention of city name or adcode matches the schema's own description. The description adds no new semantic information beyond what the schema already provides, so a baseline score of 3 is appropriate.
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?
Clearly states the tool retrieves a weather forecast for a specified city, including today and next 3 days, using Gaode map data. The name and description effectively distinguish it from the sibling 'get-weather-live' (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?
Mentions acceptable input formats (city name or 6-digit adcode) but provides no explicit guidance on when to use this tool versus 'get-weather-live'. The distinction is implied by 'forecast' vs 'live' but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定城市的实况天气（高德地图）。支持城市名或 6 位 adcode。
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | 城市名称或 6 位 adcode（例如：上海、北京东城、310100） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states it returns 'real-time weather' but omits key traits like what happens on invalid input, error responses, or any side effects. The description is insufficient for safe invocation.
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 with two short sentences, delivering essential information without any fluff. Every word serves a purpose.
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 (one parameter, no output schema), the description covers the basic purpose and input. However, it lacks usage guidance and behavioral details, which are important for correct invocation. It is minimally adequate but not fully complete.
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 the schema already documents the 'city' parameter. The description repeats the same info (city name or 6-digit adcode) without adding new semantic meaning like valid formats or examples, resulting in no added value beyond the 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?
Description clearly states '获取指定城市的实况天气' (get real-time weather for a specified city) with data source '高德地图' (Amap). The verb 'get' and resource 'live weather' are specific, and the sibling tool 'get-weather-forecast' indicates this tool is for live data, distinguishing it well.
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 the sibling 'get-weather-forecast'. The description only explains parameter input format, not usage context or conditions. This lack of differentiation leaves the agent uncertain about which tool to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a clearly distinct weather data type: forecast (future days) vs live (current conditions), with no overlap.
Both tools follow a consistent verb_noun pattern with snake_case: get-weather-forecast and get-weather-live.
Two tools is minimal but covers the core weather needs (forecast and live). Could be expanded with alerts or historical data.
Covers forecast and live conditions, but lacks extras like air quality, UV index, or severe weather warnings that a comprehensive weather service might offer.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
WeatherAPI.com MCP — wraps WeatherAPI.com (api.weatherapi.com)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheHexaflux/xjt-weather-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server