A
licenseB
qualityF
maintenanceA Model Context Protocol server that provides tools to fetch weather alerts for US states and forecasts based on latitude/longitude coordinates using the US National Weather Service API.
2
159 npm
1
MIT
Weather MCP Server
by akaramanapp
天气 MCP 服务器
一个模型上下文协议 (MCP) 服务器，使用国家气象局 (NWS) API 提供美国各地的天气信息和警报。该服务器旨在供 AI 代理通过模型上下文协议使用。
特征
获取美国任何州天气警报的工具
使用坐标获取美国任何地点详细天气预报的工具
支持温度、风力状况和简短预报描述
来自国家气象局的实时数据
Related MCP server: Weather MCP Server
先决条件
Node.js（v16 或更高版本）
npm 或 yarn 包管理器
安装
克隆存储库：
git clone https://github.com/akaramanapp/weather-mcp-server.git
cd weather-mcp-server安装依赖项：
npm install构建应用程序：
npm run buildMCP 工具
服务器提供了两个可供AI代理使用的MCP工具：
获取警报
获取特定美国州的天气警报。
参数：
state：两个字母的州代码（例如 CA、NY）
响应示例：
{
"content": [
{
"type": "text",
"text": "Active alerts for CA: ..."
}
]
}获取预测
使用坐标获取特定位置的天气预报。
参数：
latitude：位置的纬度（-90 到 90）longitude：位置经度（-180 至 180）
响应示例：
{
"content": [
{
"type": "text",
"text": "Morning: Temperature: 72°F, Wind: 5mph NW, Partly cloudy..."
}
]
}项目结构
weather/
├── src/
│ └── index.ts # Main server code with MCP tool implementations
├── build/ # Compiled JavaScript files
├── package.json # Project dependencies and scripts
└── tsconfig.json # TypeScript configuration技术细节
使用 TypeScript 构建
实现模型上下文协议（MCP）服务器
使用@modelcontextprotocol/sdk 实现 MCP 服务器
与国家气象局 (NWS) API 接口
ES2022 目标与 Node16 模块解析
发展
要修改或扩展服务器：
在
src/index.ts文件中进行更改重建应用程序：
npm run build依赖项
@modelcontextprotocol/sdk：MCP服务器实现框架
zod：工具参数的运行时类型检查和验证
TypeScript：类型安全的开发依赖关系
执照
国际学习中心
笔记
该服务器仅适用于美国地区，因为它使用国家气象局 API
API 请求有速率限制，并且需要 User-Agent 标头
所有坐标均应采用十进制度格式
这不是一个独立的 CLI 应用程序，而是一个通过模型上下文协议为 AI 代理提供工具的服务器
Available Tools
2 toolsget-alertsC
Get weather alerts for a state
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code (e.g. CA, NY) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe traits like rate limits, authentication needs, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
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 the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex alert data. It doesn't explain what the alerts include, how they're formatted, or any limitations, leaving the agent with insufficient context for effective use.
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?
The description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% coverage and fully documents the 'state' parameter. This meets the baseline score of 3, as the schema adequately handles parameter semantics without needing extra description.
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 verb ('Get') and resource ('weather alerts for a state'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling tool 'get-forecast', which likely provides different weather data, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus its sibling 'get-forecast' or any alternatives. It lacks context about usage scenarios, exclusions, or prerequisites, offering only a basic statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-forecastC
Get weather forecast for a location
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude of the location | |
| longitude | Yes | Longitude of the location |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the response format might be. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 that there are no annotations and no output schema, the description is incomplete. It doesn't provide enough context about behavioral aspects, response format, or how this tool differs from its sibling. For a tool with this level of complexity and lack of structured data, the description should do more to compensate.
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?
The schema description coverage is 100%, with both parameters (latitude and longitude) well-documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema, so it meets the baseline score of 3.
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 verb ('Get') and resource ('weather forecast for a location'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get-alerts', which likely provides different weather-related information, so it doesn't achieve the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'get-alerts' or explain the difference between getting a forecast versus alerts, leaving the agent without context for tool selection.
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.
2 tool updates
- First observed
get-alerts - First observed
get-forecast
TDQS
B3.1/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: get-alerts retrieves weather alerts for a state, while get-forecast provides weather forecasts for a location. There is no overlap in functionality, and an agent can easily differentiate between them based on their specific use cases.
Naming Consistency5/5
Both tools follow a consistent verb_noun naming pattern with hyphens (get-alerts and get-forecast). This uniformity makes the tool set predictable and easy to understand, with no deviations in style or convention.
Tool Count2/5
With only two tools, the server feels thin for a weather domain, as it lacks essential operations like getting current conditions, historical data, or radar information. While the tools are well-defined, the count is too low to provide comprehensive coverage for typical weather-related tasks.
Completeness2/5
The tool set is severely incomplete for a weather server, missing core functionalities such as current weather, historical data, and radar or satellite imagery. Agents will face significant gaps when trying to perform common weather queries, leading to potential failures in broader tasks.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
US weather for AI agents: active NWS alerts by state, 5-period forecasts by lat/lon. Paid per call.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI models to fetch weather alerts and detailed forecasts for US locations using the National Weather Service API.159 npmGPL 3.0
- FlicenseBqualityDmaintenanceA Model Context Protocol (MCP) server that provides US weather forecasts and active alerts using the National Weather Service API.2-
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides real-time weather alerts and forecasts using the National Weather Service API.-