Skip to main content
Glama
deenesjakoruzh
overstarry

qweather-mcp

by overstarry
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

qweather-mcp

铁匠徽章

英语 |简体中文

QWeather API 的 MCP 服务器，通过模型上下文协议 (MCP) 提供全面的天气信息查询功能。

✨ 特点

  • 🌤️实时天气查询

  • 📅 多日天气预报（3/7/10/15/30 天）

  • 🔑 简单的 API 密钥配置

  • 🔌 自定义 API 基本 URL 支持

  • 🛠️ 完整的工具集成

Related MCP server: OpenWeatherMap MCP Server

📦安装

通过史密斯里

推荐：使用Smithery自动为 Claude Desktop 安装：

npx -y @smithery/cli install @overstarry/qweather-mcp --client claude

手动配置

  1. 首先，从QWeather 控制台获取您的 API 密钥。

  2. 启动服务器：

# stdio server
npx -y qweather-mcp

  1. 配置环境变量：

QWEATHER_API_BASE=https://api.qweather.com
QWEATHER_API_KEY=<your-api-key>

JSON 配置

添加到您的配置文件：

{
  "mcpServers": {
    "qweather": {
      "command": "npx",
      "args": ["-y", "qweather-mcp"],
      "env": {
        "QWEATHER_API_BASE": "<your-api-url>",
        "QWEATHER_API_KEY": "<your-api-key>"
      }
    }
  }
}

🛠️ 可用工具

获取当前天气

获取指定位置的当前天气信息。

获取天气预报

获取指定位置的天气预报信息，可自定义预报天数：

  • 3天预报

  • 7天预报

  • 10天预报

  • 15天预报

  • 30天预报

预测数据包括：

  • 温度范围（最小/最大）

  • 白天/夜间天气状况

  • 日出/日落时间

  • 沉淀

  • 湿度

  • 风力条件

  • 紫外线指数

获取每分钟降水量

提供未来2小时逐分钟降水预报，包括：

  • 降水类型（雨/雪）

  • 每分钟降水量

  • 精确的时间预测

  • 实时预报描述

获取每小时预报

提供 24、72 或 168 小时的每小时天气预报，包括：

  • 温度变化

  • 天气状况

  • 风向和风力

  • 相对湿度

  • 气压

  • 降水概率

  • 云覆盖

获取天气预警

提供实时天气预警信息，包括：

  • 警告发布机构

  • 警告级别和类型

  • 详细警告内容

  • 警告有效期

  • 相关建议

获取天气指数

提供气象生命指数信息，支持多种指数类型：

  • 运动指数

  • 洗车指数

  • 敷料指数

  • 钓鱼指数

  • 紫外线指数

  • 旅游指数

  • 过敏指数及其他16项生活指数

获取空气质量

提供实时空气质量数据，包括：

  • AQI指数

  • 空气质量等级

  • 主要污染物

  • 健康建议

  • 污染物浓度

每小时获取空气质量

提供未来24小时每小时的空气质量预报：

  • 每小时空气质量指数预测

  • 污染物浓度变化

  • 健康影响评估

  • 保护建议

每日获取空气质量

提供未来3天的空气质量预报：

  • 每日空气质量指数预测

  • 主要污染物预报

  • 空气质量水平变化

  • 健康防护建议

🤝 贡献

欢迎提出问题并提出改进！请查看我们的贡献指南。

📄 许可证

麻省理工学院

🔗 相关链接

Available Tools

2 tools
get-weather-nowC

Get current weather for a location using QWeather API

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesLocation ID for the city

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description implies a read operation but lacks details about API key requirements, error handling, or response format. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise single sentence. Could be improved by adding a hint about the sibling tool or output format without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity, the description is incomplete. It does not explain how to obtain the location ID or what the output contains, missing essential context for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the parameter described as 'Location ID for the city'. The description adds no extra parameter info, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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 location' with a specific API mention. However, it does not differentiate from sibling 'lookup-city', which likely provides city IDs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention that the location parameter might come from the sibling tool 'lookup-city'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup-cityC

Look up city information by name

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNameYesName of the city to look up

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states the basic action, with no mention of side effects, authentication needs, rate limits, or error handling (e.g., if city not found). 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action. It could be more structured (e.g., listing what information is returned), but it is not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with one parameter and no output schema, the description does not specify what fields of city information are returned, nor any behavioral context. This leaves the agent uncertain about the response format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (single parameter well-described in schema). The description adds no extra meaning beyond 'by name', but the schema already provides a clear description. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'look up city information by name', specifying verb and resource. However, it does not differentiate from the sibling tool 'get-weather-now', which may also involve city queries. The description lacks detail on what information is returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No mention of prerequisites, limitations, or cases to avoid. The sibling tool exists but is not differentiated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget-weather-now
    • First observedlookup-city
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools serve clearly distinct purposes: one retrieves current weather data, and the other looks up city information. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern using snake_case: get-weather-now and lookup-city. The naming is predictable and clear.

Tool Count3/5

With only 2 tools, the set is on the lower end of reasonable. While it covers the basics, it feels minimal for a weather API, which typically includes more operations like forecasts or alerts.

Completeness2/5

The tool set lacks essential weather features such as forecasts, historical data, or severe weather alerts. For a weather-focused server, the absence of these common operations is a notable gap.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches