This MCP server lets you operate Feishu/Lark as your own user identity (not a bot), providing tools for messaging, document management, and Bitable operations.
Messaging (IM)
Send text or Markdown messages to group chats or individual users
Read recent message history from group chats or private conversations
Reply to specific messages, with optional thread support
Search messages across chats by keyword, with optional time range and group filters
List and search group chats by keyword to retrieve chat_id
Find users by name or email to get their open_id
View full thread discussions for a given message
Docs, Wiki, and Drive
Search documents, Wiki pages, and sheets
Read, create, and update documents (Markdown)
Search Drive files with type filters
List and retrieve Wiki nodes (supports URL)
Bitable (multi-dimensional tables)
List tables and fields within a Bitable base
List, filter, sort, and search records
Create or update records (upsert)
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-cli-mcp show recent messages in the project group"
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.
One-line
npxMCP server that lets AI clients (Amazon Quick Desktop, Claude Desktop, …) operate Feishu / Lark as your own user identity — send, read, reply, and search messages.
It wraps the official lark-cli (bundled as a dependency, no separate install) and exposes 19 tools over MCP stdio — messaging, cloud docs, Wiki, Drive, and Bitable. Because every call runs with --as user, the sender/creator shown in Feishu is you, not a bot.
# Bind the shared Feishu app (scan the QR code)
npx -y @yoreland/lark-cli-mcp -- config init --new
# OAuth device-flow login as yourself
npx -y @yoreland/lark-cli-mcp auth
# Sanity check (should report logged-in)
npx -y @yoreland/lark-cli-mcp doctorGo to Settings → Capabilities → MCP → + Add MCP:
In the dialog, use Paste JSON config and paste:
{
"command": "npx",
"args": ["-y", "@yoreland/lark-cli-mcp"]
}
Click Apply → Save. The server should show 19 tools · Connected ✅
Manual form instead of JSON? Connection type =
Local, Command =npx, Arguments =-y @yoreland/lark-cli-mcp. Arguments are space-split (no spaces inside the package name, so this is safe).
Settings → Capabilities → Skills → Upload, then select skill/feishu-lark/SKILL.md. Toggle it Active.
The skill teaches Quick when and how to use the 19 tools (resolve chat_id/open_id first, confirm before sending, Bitable field handling, etc.) — the MCP provides the tools, the skill makes Quick use them well.
"看看 XX 群最近聊了什么"
"帮我找一下某人"
"搜一下我的飞书文档里有没有 …"
"列一下这个多维表格 <URL> 的记录"
Related MCP server: feishu-mcp-server
Node.js v18+ (node -v)
An MCP client (Amazon Quick Desktop / Claude Desktop / etc.)
A Feishu/Lark account in the org running the workshop
Network access to npm registry and Feishu OAuth
The Feishu App ID / Secret is provided centrally by the workshop host and baked into the shared lark-cli config — attendees only do the OAuth login step. (See Host setup.)
Behind the Great Firewall? Use a mirror:
npm config set registry https://registry.npmmirror.com
npx -y @yoreland/lark-cli-mcp # start MCP server (stdio) — what the client runs
npx -y @yoreland/lark-cli-mcp auth # OAuth device-flow login (user identity)
npx -y @yoreland/lark-cli-mcp status # show auth status
npx -y @yoreland/lark-cli-mcp logout # clear token
npx -y @yoreland/lark-cli-mcp doctor # environment + login self-check
npx -y @yoreland/lark-cli-mcp -- <args> # passthrough to bundled lark-cliTool | What it does |
| Send a message |
| Read recent messages |
| Reply (thread optional) |
| Search messages |
| Find group chats |
| Find a user (→ open_id) |
| View a thread |
Tool | What it does |
| Search docs / wiki / sheets |
| Read a document |
| Create a document (markdown) |
| Update a document |
| Search Drive files (type filters) |
| List wiki nodes |
| Get a wiki node (accepts URL) |
Tool | What it does |
| List tables in a base |
| List fields of a table |
| List records (filter/sort) |
| Search records |
| Create/update a record |
Goal | Say to your assistant |
Read a group | "看看 XX 群最近聊了什么" |
Send | "在 XX 群说：明天会议改到 3 点" |
Reply | "回复那条消息：收到，我来跟进" |
Search | "搜一下谁提过客户报价" |
Find someone | "帮我找一下张三的 open_id" |
View a thread | "看看那条消息下面的讨论" |
The workshop host creates one Feishu custom app and configures it so attendees share the same App ID/Secret but each authorize their own account.
Feishu Open Platform → create an internal custom app → note App ID / App Secret.
Enable User token scopes matching the im, contact, search domains (message read/write, reply, chat read, user search, message search).
Distribute the App ID/Secret to attendees via lark-cli config (or a pre-bound config). The login step requests scopes via --domain im,contact,docs,wiki,drive,base.
auth uses OAuth Device Flow, so no redirect URL / localhost:3000 callback configuration is required.
missing required scope(s) — re-login with the needed domain:
npx -y @yoreland/lark-cli-mcp auth --domain im,contact,docs,wiki,drive,baseClient shows "No tools loaded" — run npx -y @yoreland/lark-cli-mcp doctor; confirm Node ≥18 and that auth status is OK.
Token expired — just re-run auth.
No image/file attachment sending (text + markdown only)
No interactive cards
No group creation
Tokens expire; re-run auth when they do
MCP client (Quick Desktop / Claude Desktop)
│ stdio (MCP / JSON-RPC)
▼
@yoreland/lark-cli-mcp (server.mjs)
│ child_process.execFile (no shell → injection-safe)
▼
lark-cli --as user (bundled dependency)
│ OAuth user_access_token (device flow)
▼
Feishu / Lark Open APIMIT
查看群聊或私聊的最近消息记录
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | No | 群聊 ID（oc_xxx） | |
| user_id | No | 用户 open_id（查私聊） | |
| count | No | 消息数量，默认 20 | |
| start_time | No | 起始时间（Unix 秒） | |
| end_time | No | 结束时间（Unix 秒） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description does not disclose behavioral traits like default message ordering, pagination behavior, rate limits, or whether all messages are retrieved. 'Recent' is vague.
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, no wasted words. Front-loaded with key information (what tool does). Appropriate for the content.
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; description does not explain return format, whether response includes full message content or just metadata, or how to handle pagination. For a tool with 5 parameters and no annotations, description is too brief.
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%; each parameter has a clear description in the schema. Description adds no additional semantics beyond the schema, meeting 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?
Description specifies verb '查看' (view), resource '最近消息记录' (recent messages), and context '群聊或私聊' (group chats or private chats). Clearly distinguishes from sibling tools like feishu_search_messages (search) and feishu_get_thread (thread 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 guidance on when to use this tool vs alternatives such as feishu_search_messages or feishu_get_thread. Does not mention prerequisites or suitable 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 |
|---|---|---|---|
| message_id | Yes | 消息/线程 ID（om_/omt_） | |
| count | No | 回复数量，默认 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not mention pagination, permission requirements, or the meaning of the count parameter (e.g., max replies returned).
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, front-loading the core purpose. It could benefit from more structure but is not verbose.
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 lack of output schema and annotations, the description should explain return format, count parameter behavior, and thread structure. It is insufficient for complex selection.
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 baseline is 3. The description adds no additional semantics beyond what the schema already states for message_id and count.
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 (view) and resource (complete thread discussion of a message), effectively distinguishing it from siblings like feishu_get_messages or feishu_reply_message.
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 like feishu_get_messages or feishu_reply_message. The description omits context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索飞书群聊列表（按关键词找 chat_id）
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | 搜索关键词（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'search by keyword' without explaining pagination, result limits, or behavior when no keyword is given. This is insufficient for an agent to predict tool 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?
The description is a single, efficient sentence with no wasted words. It clearly communicates the core function in a front-loaded manner.
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 or annotations, the description is too minimal. It does not explain return format, error conditions, or behavior when using no keyword. An agent would lack enough context for reliable 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 description coverage is 100%, and the description adds 'find chat_id' which confirms the parameter's purpose. However, it does not add meaning beyond what the schema already provides, hence baseline 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?
The description clearly states the action (search/list) and resource (group chats) with the specific goal of finding chat_id by keyword. It distinguishes itself from sibling tools that focus on messages, threads, users, etc.
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. While the purpose implies it for finding chat_id, there is no mention of prerequisites, exclusions, or alternative tools.
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 |
|---|---|---|---|
| message_id | Yes | 消息 ID（om_xxx） | |
| text | Yes | 回复内容 | |
| in_thread | No | 是否线程回复 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It only states it replies and supports threads, omitting side effects, permissions, error handling, or whether the reply is appended to the original message.
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?
Extremely concise single sentence that front-loads the core action and key feature. 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?
For a mutation tool with 3 parameters and no output schema, the description lacks context on return behavior, success/failure signals, or rate limits. Agents may miss important invocation details.
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 the schema already explains each parameter. The description adds no extra semantics beyond confirming thread support, meeting the 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 (reply) and resource (Feishu message), and includes a key differentiator (thread support) that distinguishes it from siblings like feishu_send_message.
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 (e.g., feishu_send_message) or prerequisites (e.g., message_id must exist). The thread support mention is helpful but not sufficient.
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 |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| chat_id | No | 限定群（可选） | |
| start_time | No | 起始时间（Unix 秒） | |
| end_time | No | 结束时间（Unix 秒） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It mentions '用户身份' (user identity) but does not clarify authentication requirements, rate limits, result scoping, or handling of empty results. The behavioral information is minimal.
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: a single Chinese sentence. It is front-loaded with the core purpose but lacks structure. While efficient, it sacrifices helpful details that could fit without becoming verbose.
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 complexity (search with multiple optional filters, no output schema), the description is insufficient. It does not explain return format, pagination, or behavior when no results. Complete documentation would require more detail about expected output and edge cases.
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 (e.g., '搜索关键词'). However, the parameter descriptions are basic and add no additional semantic context beyond the schema fields. The tool description does not elaborate on parameter usage or constraints.
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 it searches Feishu messages across groups with user identity. It distinguishes from sibling tools like 'feishu_search_user' (user search) and 'feishu_get_messages' (likely single-chat retrieval), but does not explicitly specify whether it searches all accessible groups or requires chat_id.
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. Sibling tools are listed but not compared. The optional chat_id parameter implies scope flexibility, but no advice is given on when to search all vs. specific groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按名字/邮箱搜索飞书用户，拿到 open_id
| Name | Required | Description | Default |
|---|---|---|---|
| query | 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 states that the tool searches by name/email and returns open_id, but does not disclose behavioral traits such as authentication requirements, rate limits, or behavior on multiple matches.
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 short sentence, which is concise. It conveys the core purpose without verbosity, though it could add minor details 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 tool with one parameter and no output schema, the description adequately conveys the functionality. It states what the tool does and what it returns, which is sufficient for basic usage.
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 schema already describes the 'query' parameter as '用户名字或邮箱'. The description adds the same information without further detail, so it does not significantly augment the schema. Given 100% schema coverage, 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 (search), resource (Feishu users), and expected outcome (get open_id). It distinguishes itself from sibling tools like feishu_search_messages by targeting users specifically.
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 sibling tools are about messages, threads, and chats, making the purpose relatively clear, there is no mention of prerequisites 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.
以用户身份发送飞书/Lark 消息到群聊或个人（支持纯文本与 Markdown）
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | No | 群聊 ID（oc_xxx） | |
| user_id | No | 用户 open_id（ou_xxx），发私聊 | |
| text | No | 纯文本消息内容 | |
| markdown | No | Markdown 消息内容（与 text 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states '以用户身份发送', but does not disclose authentication needs, rate limits, success/failure indications, or behavior when both text and markdown are supplied. Lacks details on whether this creates a new message vs replying.
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 and covers purpose and supported formats. However, it omits essential behavioral details that could be included without length increase.
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, description is incomplete. It lacks guidance on valid parameter combinations, error handling, and authentication. For a 4-parameter tool with all optional, more context is needed for correct usage.
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 baseline is 3. Description adds no extra meaning beyond schema; it mentions support for plain text and Markdown, but schema already has separate parameters with descriptions. No clarification on mutual exclusivity of chat_id and user_id.
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 uses the specific verb '发送' (send) and resource '飞书/Lark 消息到群聊或个人', clearly indicating the action and target. It supports both plain text and Markdown, and distinguishes from sibling tools like feishu_get_messages (retrieval) and feishu_reply_message (reply).
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 feishu_reply_message. Misses context for choice between chat_id and user_id or text vs markdown. No prerequisites or limitations mentioned.
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 action: sending, replying, retrieving messages, listing chats, searching messages, searching users, and viewing threads. No two tools have overlapping purposes, making it easy for an agent to select the correct one.
All tools follow a consistent 'feishu_verb_noun' pattern (e.g., feishu_send_message, feishu_list_chats). This uniform convention aids predictability and reduces cognitive load.
With 7 tools, the server is well-scoped for a messaging-focused MCP server. Each tool addresses a core function without redundancy, and the count is right-sized for the domain.
The set covers essential messaging operations: send, reply, retrieve messages, search, and list chats. Minor gaps exist (e.g., creating chats, marking messages as read), but the core workflow is fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Unified inbox MCP for WhatsApp, Telegram, Email, voice — read/send messages, search, AI agents.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yoreland/lark-cli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
