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., "@Lark MCP Custom Send a message to the project group saying meeting at 3pm"
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.
lark-mcp-custom/
├── src/
│ ├── index.ts # 入口：初始化 MCP Server + 注册工具
│ ├── lark-client.ts # 飞书 SDK 客户端封装
│ └── tools/
│ ├── im-tools.ts # 消息工具（发消息、群列表、消息历史）
│ ├── calendar-tools.ts # 日历工具（查询事件、创建事件）
│ └── docs-tools.ts # 文档工具（搜索文档、多维表格读写）
├── .env.example
├── package.json
├── tsconfig.json
└── claude_desktop_config.example.jsonRelated MCP server: Feishu MCP Server
工具名 | 功能 |
| 发送文本消息到群或用户 |
| 获取机器人所在群列表 |
| 获取群内最近消息 |
| 查询日历事件 |
| 创建日历事件 |
| 搜索云空间文档 |
| 读取多维表格记录 |
| 向多维表格写入记录 |
Node.js >= 20
飞书企业自建应用（App ID + App Secret）
安装依赖
npm install配置环境变量
cp .env.example .env
# 编辑 .env，填入 FEISHU_APP_ID 和 FEISHU_APP_SECRET构建
npm run build测试运行
FEISHU_APP_ID=cli_xxx FEISHU_APP_SECRET=xxx node dist/index.js配置 Claude 桌面版（见下方）
编辑 Claude 配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"lark-mcp-custom": {
"command": "node",
"args": ["/你的绝对路径/lark-mcp-custom/dist/index.js"],
"env": {
"FEISHU_APP_ID": "cli_你的AppID",
"FEISHU_APP_SECRET": "你的AppSecret"
}
}
}
}重启 Claude 桌面版后即可使用。
在飞书开放平台（https://open.feishu.cn/app）为应用开启以下权限：
IM（消息）
im:message 读写消息
im:chat:readonly 查看群信息
日历
calendar:calendar 读写日历
云文档 & 多维表格
drive:drive:readonly 搜索文档
bitable:app 多维表格读写
新增工具只需两步：
在 src/tools/ 下创建新文件，导出 registerXxxTools(server, client) 函数
在 src/index.ts 中 import 并调用
工具定义格式：
server.tool(
"工具唯一名称",
"工具功能描述（Claude 会看这个来决定何时调用）",
{ 参数: z.string().describe("参数说明") },
async (params) => {
// 调用飞书 API
return { content: [{ type: "text", text: "返回结果" }] };
}
);向飞书多维表格写入一条新记录
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | 多维表格的 app_token | |
| table_id | Yes | 数据表 ID | |
| fields | 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 only mentions 'write a new record' without disclosing behavior such as idempotency, duplicate handling, or requirements (e.g., existence of app_token and table_id). This is insufficient for a write 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 sentence, highly concise and front-loaded. It contains no filler, but its brevity sacrifices detail that could be expected for a create operation.
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 three required parameters, no output schema, and no annotations, the description is incomplete. It omits return values (e.g., created record ID), error scenarios, and prerequisites, making it insufficient for confident agent invocation.
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 descriptions for all three parameters. The fields parameter includes an example, adding value beyond the schema. However, the descriptions are basic and do not explain constraints like formatting or allowed characters, so baseline 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 '向飞书多维表格写入一条新记录' clearly states the action (write/create) and resource (Feishu bitable), making it distinct from sibling tools like lark_bitable_list_records. However, it could be slightly more specific (e.g., 'insert a new row') and does not explicitly differentiate itself.
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?
There is no guidance on when to use this tool versus alternatives (e.g., lark_bitable_list_records for reading). The description only states the action, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取飞书多维表格（Bitable）中指定数据表的记录
| Name | Required | Description | Default |
|---|---|---|---|
| app_token | Yes | 多维表格的 app_token（URL 中的 base 部分） | |
| table_id | Yes | 数据表 ID（tbl 开头） | |
| page_size | No | 每页条数，最大 500 | |
| filter | No | 过滤条件，格式参考飞书文档 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It only states 'read records' without mentioning pagination, rate limits, error handling, or effects like read-only nature. This is insufficient.
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 is concise and front-loaded. Every word serves a purpose, with no fluff or redundancy.
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 no output schema and no annotations, the description is too brief. It omits important contextual details such as return format, pagination behavior, or usage notes for the filter parameter. The tool complexity (4 parameters, list operation) demands more 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 coverage is 100% with descriptions for all 4 parameters. The tool description does not add additional meaning beyond what the schema provides, so baseline 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 clearly states the tool reads records from a specified data table in Lark Bitable, using a specific verb ('读取' - read) and resource ('多维表格中指定数据表'). It is distinct from the sibling tool lark_bitable_create_record, which creates records.
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, such as when to use lark_bitable_create_record or other tools. There is no explanation of prerequisites or context.
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，通常为 'primary' 代表主日历 | |
| start_time | Yes | 开始时间，Unix 时间戳（秒），例如今天 0 点 | |
| end_time | Yes | 结束时间，Unix 时间戳（秒） | |
| page_size | No | 返回条数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it retrieves events; no mention of read-only nature, limitations (e.g., past vs future events), or pagination behavior. Lacks behavioral 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?
Single sentence is concise but lacks structure. It omits important details like pagination, making it underspecified.
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?
With 4 parameters and no output schema, the description is insufficient. It does not explain return format, pagination mechanisms, or error handling.
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 parameter descriptions. The tool description adds no extra meaning 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 action (get), resource (calendar events), and scope (specified time range). It distinguishes from sibling 'lark_create_event' which is for creating events.
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 like 'lark_create_event'. The description does not mention any prerequisites or scenarios.
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，通常为 'primary' | |
| summary | Yes | 事件标题 | |
| start_timestamp | Yes | 开始时间 Unix 时间戳（秒） | |
| end_timestamp | Yes | 结束时间 Unix 时间戳（秒） | |
| description | No | 事件描述 | |
| location | No | 事件地点 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but only states basic action. Lacks details on idempotency, permission requirements, error handling, or conflict behavior.
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, concise and front-loaded. No unnecessary 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?
With 6 parameters and no output schema, the description is minimal. Does not explain return values, errors, or usage context among siblings.
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 parameters are fully documented in the schema. The description adds no extra meaning beyond the basic action.
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 verb 'create' and resource 'new event in Feishu calendar'. It effectively distinguishes from sibling tools like lark_calendar_events (list events) and others.
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 versus alternatives, such as comparing with lark_calendar_events. No prerequisites or context provided.
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 |
|---|---|---|---|
| container_id | Yes | 群 chat_id | |
| container_id_type | No | 容器类型，固定为 chat | chat |
| page_size | No | 获取条数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description holds full burden. It does not disclose pagination behavior, default page size, ordering, or error conditions. Only states it retrieves recent messages, lacks detail on what 'recent' means or data format.
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, concise and to the point. No wasted words, but lacks structure like bullet points. Appropriate for a simple tool.
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?
No output schema, so description should explain return values. It does not. Also missing details on pagination, error handling, or rate limits. For a tool with 3 parameters, it is incomplete.
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 has 100% description coverage for all parameters. Description adds no additional meaning beyond schema. Baseline score of 3 is appropriate because schema already documents parameters adequately.
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 states verb 'get' and resource 'recent messages of specified group chat'. It distinguishes from siblings like lark_send_message (send) and lark_list_chats (list chats). However, it could be more specific about pagination or that it returns a fixed number of recent messages.
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 explicit guidance on when to use this tool versus alternatives. Lacks context about when to use lark_get_messages vs other chat tools. Does not mention limitations or 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 |
|---|---|---|---|
| page_size | No | 每页数量，最大 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states the basic function, omitting details like pagination behavior, rate limits, or that only chats the bot has joined are listed. The page_size parameter implies pagination but is not explained.
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 waste. It is appropriately front-loaded but could be slightly more structured.
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 tool with one parameter and no output schema, the description is minimal. It lacks details about response format or what the list contains, which could hinder an agent's understanding of return values.
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 one parameter (page_size) already described. The description adds no extra meaning beyond the schema, so 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 '获取机器人加入的所有群聊列表' clearly states the tool retrieves all group chats the bot has joined. It specifies the resource (group chats) and action (list), and distinguishes from sibling tools which focus on records, events, messages, or docs.
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. There is no mention of prerequisites, limitations, or 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.
在飞书云空间中搜索文档、表格、多维表格等
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| count | No | 返回数量 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that the tool searches in 'cloud space' and for certain file types, but does not disclose whether it is read-only, any rate limits, pagination behavior, or what exactly is returned in the response.
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 that gets straight to the point. It is front-loaded with the action and scope, though it could benefit from more structure (e.g., listing searchable file types).
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 simplicity of two parameters and no output schema, the description is still incomplete. It does not explain what fields are searched (title, content, etc.), how results are sorted, or whether there are limitations (e.g., only accessible documents). More context would help agents use it effectively.
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 both parameters have basic descriptions ('search keyword' and 'number of returns'). The tool description adds no additional meaning beyond the schema, so baseline 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 clearly states that the tool searches for documents, spreadsheets, and multi-dimensional tables in Feishu cloud space. It distinguishes itself from sibling tools (e.g., bitable, calendar) by focusing on general search across multiple file types, though it does not explicitly differentiate from each sibling.
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 versus alternatives. There is no mention of prerequisites, when not to use it, or which other tools might be more appropriate for specific search needs (e.g., lark_bitable_list_records for structured data).
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 |
|---|---|---|---|
| receive_id_type | Yes | 接收者 ID 类型 | |
| receive_id | Yes | 接收者 ID（群 ID 或用户 ID） | |
| content | Yes | 消息内容（纯文本） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解提供，描述仅说明基本功能，未揭示任何行为特性如权限要求、错误处理或副作用（如是否幂等）。对于无注解的工具，描述应承担更多责任，但此处未做到。
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?
一句话简洁明了，没有冗余，但稍显简短。不过简洁性良好。
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?
在无输出模式和无注解的情况下，描述未提及返回值、错误或确认信息。对于发送消息工具，应至少说明是否返回消息ID。完整性不足。
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?
输入模式已覆盖100%参数且有描述，描述本身未添加超出模式的新语义。基线为3，合理。
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?
描述明确指定了动词'发送'和资源'文本消息到飞书群聊或指定用户'，与兄弟工具如lark_get_messages（获取消息）和lark_list_chats（列出群聊）有明显区分。
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?
描述未提供任何关于何时使用该工具、何时不使用或与其他工具比较的指导。缺少使用场景说明。
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: bitable records, calendar events, chats/messages, and document search. No overlapping purposes.
Most tools follow a lark_<domain>_<verb>_<noun> pattern, but lark_calendar_events deviates by lacking a verb (should be lark_list_calendar_events). Otherwise consistent.
8 tools is well-scoped for a Lark integration covering bitable, calendar, messaging, and docs. Each tool adds distinct value.
Notable gaps: bitable lacks update/delete, calendar lacks update/delete, messaging lacks delete, and docs only have search. Core workflows covered but lifecycle incomplete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Let AI agents query data and act across all your business apps via MCP.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/venchuian/lark-custom-mcp-ts'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
