Skip to main content
Glama
630156145

Weather MCP Server

by 630156145
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Weather and Feishu MCP Server

A comprehensive Model Context Protocol (MCP) server that provides both weather data and Feishu document access to AI agents like Claude and cursor.

Features

Weather Tools

  • get-alerts: Get weather alerts for a US state

  • get-forecast: Get weather forecast for specific coordinates

Feishu (Lark) Tools

  • get-feishu-doc: 获取飞书文档内容（纯文本格式）

Related MCP server: Weather MCP Server

Installation

npm install

Configuration

Weather功能

Weather功能无需配置，直接使用美国国家气象局(NWS)的公开API。

飞书功能配置

  1. 创建飞书自建应用

  2. 应用权限配置

  3. 环境变量设置

    # 复制环境变量模板
cp .env.example .env

# 编辑.env文件，填入你的飞书应用信息
FEISHU_APP_ID=your_feishu_app_id_here
FEISHU_APP_SECRET=your_feishu_app_secret_here

Usage

作为MCP服务运行 (推荐)

Stdio 模式 (用于Claude Desktop等)

npm start
# 或者
node index.mjs stdio

HTTP/SSE 模式 (用于网页应用)

node index.mjs sse [port]
# 默认端口8080，或自定义端口
node index.mjs sse 3001

工具使用示例

天气功能

  • get-alerts - 参数: state (两字母州代码，如 "CA", "NY")

  • get-forecast - 参数: latitude, longitude (纬度经度)

飞书文档功能

  • get-feishu-doc - 参数: docId (文档ID或完整URL)

    • 支持多种文档类型：

      • doc/docx: 文档 - https://feishu.cn/docx/xxxxx

      • sheet/sheets: 表格 - https://feishu.cn/sheets/xxxxx

      • slides: 演示文稿 - https://feishu.cn/slides/xxxxx

      • bitable: 多维表格 - https://feishu.cn/bitable/xxxxx

      • wiki: 知识库 - https://feishu.cn/wiki/xxxxx

      • file: 云文档文件 - https://feishu.cn/file/xxxxx

      • mindnote: 思维笔记 - https://feishu.cn/mindnote/xxxxx (基本信息)

在Cursor中使用

  1. 配置MCP客户端 将此服务添加到你的MCP客户端配置中

  2. 使用天气功能

    请帮我查询加州的天气预警
请获取纬度37.7749，经度-122.4194的天气预报

  3. 使用飞书文档功能

    请帮我读取这个飞书文档：https://feishu.cn/docx/doccnxxx...
请帮我读取这个飞书表格：https://feishu.cn/sheets/shtcnxxx...
请分析这个演示文稿：https://feishu.cn/slides/phtcnxxx...
请查看这个多维表格：https://feishu.cn/bitable/bblcnxxx...

项目结构

weather-server-javascript/
├── index.mjs              # 主服务文件
├── services/
│   └── feishu.mjs        # 飞书服务模块
├── config/
│   └── index.mjs         # 配置管理
├── .env.example          # 环境变量模板
├── package.json          # 依赖管理
└── README.md             # 说明文档

故障排除

飞书功能不可用

  • 检查是否设置了 FEISHU_APP_ID 和 FEISHU_APP_SECRET 环境变量

  • 确认飞书应用具有对应文档类型的读取权限：

    • 文档权限：读取与编辑文档

    • 表格权限：读取与编辑电子表格

    • 演示文稿权限：读取与编辑演示文稿

    • 多维表格权限：读取与编辑多维表格

    • 云文档权限：读取与编辑云空间文件

  • 检查文档ID或URL格式是否正确，支持的格式：

    • https://feishu.cn/{type}/{id} (type: doc, docx, sheet, sheets, slides, bitable, wiki, file, mindnote)

    • 直接提供文档ID

天气功能限制

  • 仅支持美国地区的天气数据（NWS API限制）

  • 坐标必须在美国境内

技术特性

  • 双协议支持: Stdio和HTTP/SSE传输模式

  • 错误处理: 完善的错误提示和降级处理

  • 环境适配: 开发和生产环境配置分离

  • 类型安全: 使用Zod进行参数验证

License

ISC License

更新日志

  • v1.0.0: 集成飞书文档读取功能，保持原有天气功能

    • 新增飞书文档内容获取

    • 支持文档URL自动解析

    • 优化配置管理系统

Available Tools

3 tools
get-alertsC

Get weather alerts for a state

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesTwo-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-feishu-docC

获取飞书文档内容（纯文本）

ParametersJSON Schema
NameRequiredDescriptionDefault
docIdYes飞书文档ID，通常在URL中找到。支持以下类型的完整链接或文档ID：doc、docx、sheet、sheets、mindnote、bitable、file、slides、wiki

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 carries full burden. It states the tool retrieves document content as plain text, which implies a read-only operation, but doesn't disclose important behavioral traits like authentication requirements, rate limits, error conditions, or what happens with different document types mentioned in the schema. The description is minimal and lacks operational context.

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 extremely concise - a single Chinese phrase that communicates the core purpose efficiently. There's no wasted language, though one could argue it's almost too minimal. It's front-loaded with the essential information in compact form.

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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the plain text output takes, how different document types are handled, authentication requirements, or error scenarios. For a tool that interacts with external documents, more operational context would be helpful.

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%, so the schema already fully documents the single parameter (docId). The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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 ('获取' - get/retrieve) and resource ('飞书文档内容' - Feishu document content) with specificity about the format ('纯文本' - plain text). It distinguishes from potential siblings by focusing on document content retrieval rather than alerts or forecasts, though it doesn't explicitly differentiate from hypothetical document-related tools.

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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, context for use, or exclusions. While the sibling tools (get-alerts, get-forecast) are clearly different, there's no explicit comparison or usage context provided.

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
NameRequiredDescriptionDefault
latitudeYesLatitude of the location
longitudeYesLongitude 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.

  1. 3 tool updatesv1.0.0
    • First observedget-alerts
    • First observedget-feishu-doc
    • First observedget-forecast
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

C2.5/5.0

Scored across 3 tools

Disambiguation1/5

The tools have no coherent domain overlap, making them highly ambiguous as a set. 'get-alerts' and 'get-forecast' relate to weather, while 'get-feishu-doc' is unrelated (document retrieval), causing clear confusion about the server's purpose and tool selection.

Naming Consistency2/5

Naming is inconsistent with mixed conventions: 'get-alerts' and 'get-forecast' use kebab-case with a 'get-' prefix, while 'get-feishu-doc' uses kebab-case but includes a non-English term, breaking pattern. The verbs are consistent ('get'), but the overall style lacks uniformity.

Tool Count2/5

With only 3 tools, the count is too low for a coherent weather server, as it lacks essential operations like historical data or radar. The inclusion of an unrelated document tool further dilutes the scope, making the set feel incomplete and mismatched.

Completeness1/5

The tool set is severely incomplete for a weather domain, missing basic CRUD operations like update or delete, and lacking coverage for key weather aspects (e.g., current conditions, historical data). The unrelated document tool creates a gap in domain coherence, making the surface unusable for weather-related tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Weather Server

    adarshem
    A
    license
    B
    quality
    D
    maintenance
    A 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
    55 npm
    1
    MIT

  • Weather MCP Server

    mauricioTechDev
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI models to fetch weather alerts and detailed forecasts for US locations using the National Weather Service API.
    55 npm
    GPL 3.0

Appeared in Searches