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., "@feishu-mcp-server show me the content of document 123"
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.
让AI读取飞书文档、发送消息、管理日历
📄 文档读取 — 获取文档内容和元信息，搜索文档
💬 消息管理 — 查看群聊消息，发送消息（需关闭只读）
📅 日历查询 — 查看日历和日程
📊 电子表格 — 读取表格数据
🔒 安全优先 — 默认只读，消息发送可限制群聊白名单
🇨🇳 中文优先 — 面向国内飞书用户
Related MCP server: Feishu/Lark OpenAPI MCP
访问 飞书开放平台
创建企业自建应用
获取 App ID 和 App Secret
添加权限：文档读取、消息读写、日历读取、表格读取
{
"mcpServers": {
"feishu": {
"command": "python",
"args": ["-m", "feishu_mcp_server"],
"env": {
"FEISHU_MCP_APP_ID": "your_app_id",
"FEISHU_MCP_APP_SECRET": "your_app_secret",
"FEISHU_MCP_READ_ONLY": "true"
}
}
}
}工具 | 功能 | 安全级别 |
| 获取文档内容 | 🟢 只读 |
| 获取文档元信息 | 🟢 只读 |
| 搜索文档 | 🟢 只读 |
| 获取群聊消息 | 🟢 只读 |
| 发送消息 | 🔴 需关闭只读 |
| 获取日历列表 | 🟢 只读 |
| 获取日程 | 🟢 只读 |
| 获取Sheet列表 | 🟢 只读 |
| 获取表格数据 | 🟢 只读 |
MIT License
获取飞书文档的原始内容
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | 飞书文档ID（从URL中获取） |
| Name | Required | Description |
|---|---|---|
| result | 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 only states 'get original content' without detailing format, size limits, error handling, or permissions. The output schema exists but its info is not leveraged in the description.
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 a single, brief sentence with no redundant information. It is concise and front-loaded.
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) and the presence of an output schema, the description is nearly sufficient. However, it could mention the output type (e.g., raw text) to further help the agent.
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 sole parameter 'document_id' has a clear description in the schema ('from URL'), and the schema coverage is 100%. The description adds no extra semantic value beyond what the schema already provides.
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 the tool retrieves the original content of a Feishu document. It specifies the verb 'get' and the resource 'original content', distinguishing it from sibling tools like get_doc_meta (metadata) and search_docs (search).
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 when raw document content is needed, but it does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites or exclusions. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取飞书文档的元信息（标题、所有者等）
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | 飞书文档ID |
| Name | Required | Description |
|---|---|---|
| result | 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 explicitly states the tool returns metadata (title, owner, etc.), implying a read-only operation. While it doesn't explicitly declare safety or side effects, the simple nature of the tool makes this sufficient.
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 a single, efficient sentence that front-loads the purpose. No 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?
Given the low complexity (1 parameter, output schema exists), the description provides sufficient context: it explains what metadata is retrieved (title, owner, etc.) and covers the essential purpose. No gaps.
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 100% (the only parameter 'document_id' is described in the schema as '飞书文档ID'). The description adds no additional meaning beyond the schema, so baseline score of 3 applies per rules.
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 the tool's function: 'get Feishu document metadata (title, owner, etc.)'. It uses a specific verb ('get') and resource ('doc metadata'), and distinguishes it from siblings like 'get_doc_content' which retrieves content.
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 retrieving metadata but provides no explicit guidance on when to use this tool over alternatives, nor any when-not-to-use or prerequisites. The context is clear but lacks exclusionary details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取飞书电子表格的数据
| Name | Required | Description | Default |
|---|---|---|---|
| spreadsheet_token | Yes | 电子表格Token | |
| range_ | Yes | 数据范围（如 Sheet1!A1:D10） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling, rate limits, or what happens with invalid ranges. The agent lacks crucial context 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 a single phrase, making it too brief and lacking essential information about usage and behavior. It is under-specified rather than concise, as it omits context that would be valuable for the agent.
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?
The tool has two required parameters and an output schema (not shown), so the description does not need to explain return values. However, it lacks context on authentication, error scenarios, and range format expectations. Overall, minimally adequate but not 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 coverage is 100% with Chinese descriptions for both parameters (spreadsheet_token and range_). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema already provides sufficient parameter documentation.
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 '获取飞书电子表格的数据' (Get Feishu spreadsheet data) clearly identifies the tool's action and resource. However, it is somewhat vague as 'data' could encompass many things, and it does not distinguish from sibling tools like list_sheets.
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 usage guidelines are provided. The description does not mention when to use this tool versus alternatives (e.g., list_sheets for sheet metadata), nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取飞书日历的日程列表
| Name | Required | Description | Default |
|---|---|---|---|
| calendar_id | Yes | 日历ID | |
| start_time | Yes | 开始时间（Unix时间戳，秒） | |
| end_time | Yes | 结束时间（Unix时间戳，秒） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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, but it only repeats the tool's purpose. It does not mention authentication, rate limits, or how the results are ordered/paginated, which is insufficient for a list operation.
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 a single, complete phrase with no redundant information. It is front-loaded and immediately conveys the core functionality, achieving maximum conciseness.
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 simple list operation (3 required parameters) and the existence of an output schema, the description is minimally adequate but lacks details on pagination, time zone handling, or recurrence behavior that would make it complete for an AI agent.
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 100% with each parameter described inline, so the baseline is 3. The tool description adds no extra meaning beyond the schema, so it stays at baseline.
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 the action (获取/get) and the resource (飞书日历的日程列表/schedule list of Feishu calendar), making the tool's purpose immediately obvious and distinguishable from siblings like list_calendars.
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 no guidance on when or when not to use this tool, nor does it mention alternatives. It only states the basic functionality, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取飞书日历列表
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | 返回数量（默认20） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'get list' without behavioral details like authentication, rate limits, or data scope.
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?
Single sentence with no wasted words. However, could be slightly more informative without losing conciseness.
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 list operation with one optional parameter and an output schema, the description is minimally adequate. Lacks any detail about the output or usage context.
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 already documents the one parameter (page_size) at 100% coverage. Description adds no extra meaning 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?
The description '获取飞书日历列表' clearly states the action (获取/get) and resource (飞书日历列表/Feishu calendar list). It distinguishes from sibling tools like list_calendar_events and list_sheets.
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 on when to use this tool vs alternatives. Does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取飞书群聊的消息列表
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | 群聊ID | |
| count | No | 获取消息数量（默认20） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, pagination, rate limits, or ordering. It fails to convey essential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, appropriate for a simple tool with two parameters. It is front-loaded and efficient.
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?
Despite having an output schema, the description does not mention return format, pagination, or any other completion detail. Given the tool's simplicity, more context (e.g., message ordering, limits) would be beneficial.
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?
Input schema coverage is 100%, so parameters are already described. The description adds no extra semantic value beyond what the schema provides, meeting the baseline for high coverage.
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 states the verb '获取' (get) and resource '飞书群聊的消息列表' (Feishu group chat message list), clearly indicating the tool retrieves messages. However, it does not differentiate from sibling tools like 'send_message' or specify the scope (e.g., whether it gets all messages or recent ones).
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. The description implies it should be used to retrieve messages, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取飞书电子表格的Sheet列表
| Name | Required | Description | Default |
|---|---|---|---|
| spreadsheet_token | Yes | 电子表格Token（从URL中获取） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits such as read-only nature, permissions, or pagination. The description only states the basic function, omitting any details about expected behavior, limitations, or side effects. 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 a single sentence, highly efficient, and contains no superfluous information. Every word is necessary to convey the core 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, output schema exists), the description is minimally adequate. However, it lacks context about the output format, relationship with sibling tools, and any prerequisites. There is room for improvement to fully guide an AI agent.
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% as the single parameter 'spreadsheet_token' has a description in the schema. The tool description does not add any additional meaning or context beyond what the schema provides, but since schema coverage is high, 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?
The description '获取飞书电子表格的Sheet列表' clearly states the action (get list) and the resource (sheets in a spreadsheet). It distinguishes from sibling tools like get_sheet_values, which retrieves cell values, making the tool's specific function unambiguous.
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 does not provide explicit guidance on when to use this tool versus alternatives. While the context implies it is a prerequisite for accessing sheet values via get_sheet_values, no such relationship is stated. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索飞书文档
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| page_size | No | 返回结果数量（默认10） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral details beyond the basic function. It does not disclose side effects, authentication needs, rate limits, or pagination.
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, using a single phrase. While effective, it is perhaps too minimal for a non-trivial tool, but it avoids verbosity.
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 simple tool (2 parameters) and the presence of an output schema, the description is minimally sufficient but lacks guidance on usage context and return behavior.
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%, with both 'query' and 'page_size' adequately described. The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
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 indicates the tool searches Feishu documents, and the name 'search_docs' aligns with that. It distinguishes from sibling tools like 'get_doc_content' which retrieves specific content.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
发送消息到飞书群聊（需要关闭只读模式）
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | 群聊ID | |
| text | Yes | 消息内容 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions the write operation and a prerequisite, but does not detail other behaviors like rate limits, error handling, or return values. The presence of an output schema partially compensates.
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 a single sentence that conveys purpose and a prerequisite. It is concise and front-loaded with the key information.
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 primitive parameters, output schema present) and the description's clear statement of purpose and a prerequisite, it is mostly complete. A bit more about the expected response could be included, but the output schema likely covers that.
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?
Both parameters are described in the input schema (100% coverage). The description does not add additional meaning to the parameters beyond what the schema provides.
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 the action (send) and the resource (message to Feishu group chat). It also includes a prerequisite. It is easily distinguishable from sibling tools, which are all about getting or listing data.
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 mentions a prerequisite (need to turn off read-only mode), which guides usage. However, it does not compare to alternative tools or explicitly say when not to use it.
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 distinct resource and action: documents (get content, get meta, search), sheets (list sheets, get values), calendars (list calendars, list events), chat (list messages, send message). No overlapping purposes.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_doc_content, list_calendars, send_message), making the naming predictable and clear.
9 tools cover the main domains of Feishu (docs, sheets, calendar, chat) without being excessive. Each tool serves a clear purpose and the count is well-scoped for the server's purpose.
The tool set covers read operations well but lacks write/update/delete capabilities for most resources (no create/update doc, no update sheet, no create/update events, no delete messages). This is a notable gap for a full lifecycle.
GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
Your personal data for AI — Telegram, bank, courses, Zoom & more, scoped to you.
Let AI tools securely access your LinkedIn network and DMs
Shared company knowledge, workflows, and connected apps for the AIs your team already uses.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lm203688/feishu-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
