lark-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: sending, replying, listing chats, getting members, viewing messages, sending cards, user info, and agenda. While send_message and send_card both send to a chat, their descriptions clearly distinguish text from interactive cards, leaving no ambiguity.
Naming Consistency5/5
All tool names follow the same pattern: lark_verb_noun (e.g., lark_send_message, lark_list_chats). The verbs are consistent (send, reply, list, get) and all use snake_case, making the naming uniform and predictable.
Tool Count5/5
With 8 tools, the server is well-scoped for a collaboration platform covering messaging, chat management, user info, and agenda reading. Each tool earns its place without being overwhelming or sparse.
Completeness3/5
The server covers core messaging workflows (send, reply, list history) and read operations for chats and users, but lacks write operations for chats (create/update/delete), message editing/deletion, and calendar management beyond reading. These gaps could cause agents to hit dead ends when trying to manage resources.
Average 3.1/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full responsibility for disclosing side effects and behavior. It only says 'reply,' offering no information about permissions, failure modes, rate limits, notification behavior, or whether it creates a new thread message. The is_thread parameter hints at thread behavior, but the description does not explain it. This is severely under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('回复飞书消息'), which is concise but under-specified. It lacks the necessary elaboration for a tool with four parameters and multiple options. Under-specification is not a virtue; the description should contain enough detail to be useful, and this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, an output schema, and no annotations, the description is far too minimal to provide adequate context. It does not explain thread behavior, message types beyond schema hints, or how it differs from lark_send_message. The presence of an output schema partially mitigates return-value concerns, but the description still lacks critical usage and behavioral context.
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 descriptions cover 100% of parameters, providing baseline meaning for each field. The tool description adds no additional explanation beyond what the schema already states, so the parameter semantics are adequate but not enriched. The schema itself clarifies msg_type options and is_thread default, which is sufficient.
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 (reply) and the resource (Lark message). It is specific enough to convey the core purpose, though it does not explicitly differentiate from the sibling lark_send_message. Since the verb 'reply' implies responding to an existing message, it is reasonably distinct, but could be more explicit about the target being an existing message ID.
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 on when to use this tool versus lark_send_message or other siblings. It does not mention thread behavior, prerequisites, or alternative use cases. The description simply states what it does, leaving the agent to infer usage context from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It simply states 'view chat history messages' without mentioning pagination behavior, ordering, read-only status, rate limits, or any side effects. The schema hints at page_size, but the description does not elaborate on how pagination works or what is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single short phrase—and is front-loaded. However, it essentially restates the tool name without adding informative content, making it under-specified rather than merely concise. It has no wasted words but also fails to provide meaningful guidance.
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?
Despite having a simple schema and an output schema, the description is incomplete. It lacks essential behavioral context such as message ordering, pagination limits, or any constraints. With no annotations to supplement behavioral safety, the description falls short of adequately informing an agent about expected usage and outcomes.
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?
Both parameters (chat_id and page_size) are fully described in the schema with clear descriptions and a default value, giving 100% schema coverage. The description adds no extra parameter semantics, but since the schema already covers them, the baseline score of 3 is appropriate.
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 indicates a message retrieval operation for chat history, using a specific verb ('view') and resource ('chat messages'). It is understandable but does not explicitly distinguish itself from sibling tools like listing chats or sending messages, so it lacks full differentiation.
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 usage guidance is provided. The description does not state when to use this tool versus alternatives such as lark_send_message or lark_list_chats, nor does it mention any exclusions or prerequisites. The intended context must be inferred entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It only says 'view', implying a read operation, but does not mention authentication needs, rate limits, return format, or side effects. This is insufficient for a tool with no safety profile from annotations.
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 a single, short phrase that is direct and free of redundancy. It is appropriately sized for conveying the basic purpose, though it sacrifices completeness for brevity.
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?
While the schema covers parameters and an output schema exists, the description lacks usage guidelines and behavioral disclosure. It does not explain when to use this tool relative to siblings or what to expect from the operation, making the overall context incomplete for an agent.
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 input schema already provides descriptions for all three parameters (start, end, calendar_id) with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, so it does not exceed the baseline.
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 tool's purpose: to view Feishu agenda/schedule. It uses a specific verb (view) and resource (agenda), and it is easily distinguishable from sibling tools focused on messaging and chats. However, it lacks scope details such as date range or calendar behavior, preventing a perfect 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 the sibling alternatives. It does not mention any exclusions, prerequisites, or alternative tools, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool gets a member list, but does not disclose pagination behavior, return format, error handling, authorization requirements, or rate limits. The read-only nature is implied but not elaborated.
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 a single, concise sentence that gets straight to the point. It is front-loaded and contains no unnecessary words. However, it is essentially a restatement of the tool name, providing minimal additional value beyond clarity.
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 the minimal description, the tool is not fully contextualized. The agent learns what it does but not important operational details like how to obtain chat_id, whether member lists are paginated, or if any special permissions are needed. The existence of an output schema mitigates this somewhat, but the description itself is incomplete for seamless invocation.
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 input schema already covers the only parameter chat_id with a description ('群聊 ID'), providing 100% schema description coverage. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate. The parameter is self-explanatory.
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 tool's function: retrieving the member list of a group chat. It uses a specific verb (get) and resource (chat members), and it is distinct from siblings like lark_list_chats (list chats) or lark_list_messages (list messages). However, it lacks scope details such as whether members are returned in pages or if filtering is supported.
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 does not mention prerequisites (e.g., needing a chat_id from lark_list_chats), exclusions, or scenarios where another tool would be more appropriate. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not mention side effects, permissions, error handling, or any other behavioral traits. For a mutation tool, this is a significant omission.
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, front-loaded sentence that wastes no words. It conveys the core purpose efficiently, though it could benefit from more detail in other dimensions.
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 tool is a mutation with no annotations and minimal description, the lack of usage guidance and behavioral transparency makes it incomplete. The schema covers parameters and an output schema exists, but the description does not compensate for the missing behavioral context.
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%, with both chat_id and card_json having descriptions. The tool description itself adds no additional meaning beyond what the schema already provides, so the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '发送交互卡片到飞书聊天' clearly states the tool sends an interactive card to Feishu chat. The resource is specific ('interactive card') and distinguishes it from sibling tools like lark_send_message, which sends regular messages.
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 on when to use this tool versus alternatives (e.g., lark_send_message or lark_reply_message). The description simply states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely states the action without disclosing behavioral details such as authentication requirements, rate limits, message type handling, or what the tool returns on success/failure. This is insufficient for a mutation tool.
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 a single, concise sentence with no wasted words. However, it is so minimal that it under-specifies important context, though this is partly accounted for in other dimensions.
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?
The description is very brief and does not explain message types, chat_id formats, behavior differences from lark_reply_message or lark_send_card, or output details. Even with an output schema, the description lacks the contextual depth needed for effective tool selection and 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 input schema covers 100% of parameters with descriptions for chat_id, content, and msg_type. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '发送消息到飞书聊天' (send message to Feishu chat) clearly states the tool's action and resource. It is specific and distinguishable from sibling tools like lark_reply_message (reply) and lark_send_card (send card).
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?
There is no guidance on when to use this tool relative to alternatives. The description does not mention lark_reply_message, lark_send_card, or any exclusions or prerequisites, leaving the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'list' and provides no information about pagination, result ordering, or scope (e.g., only chats joined by the bot). The schema documents pagination parameters, but the description itself adds no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is slightly redundant ('list...列表') but remains concise and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and an output schema, the minimal description is almost sufficient. However, it lacks any mention of pagination semantics or filtering/scope beyond 'group chats', leaving some gaps for a low-complexity tool.
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 coverage is 100%: both page_size and page_token have detailed descriptions in the schema. The description adds no additional meaning beyond confirming the action, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出飞书群聊列表' clearly states the action (list) and resource (Feishu group chats), distinguishing it from siblings like lark_list_messages and lark_get_chat_members. The slight redundancy in wording does not obscure the intended purpose.
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 usage guidance is provided. The description only states the action, without indicating when to use this tool versus alternatives such as lark_list_messages or lark_get_chat_members. The agent must infer context from the name and sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses an important conditional behavior (no user_id → query self) beyond what the name implies. It doesn't mention permissions or error cases, but the output schema covers return details and this is a simple read operation.
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?
One short, front-loaded sentence conveys the core purpose and the optional-parameter behavior. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description fully covers the tool's purpose and the meaningful behavioral nuance. No additional context is necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents user_id as an optional string. The description adds key semantics: omitting user_id results in querying the caller's own info. This enriches the parameter meaning beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('获取飞书用户信息' = get Lark user info) and adds the scoped behavior of querying self when user_id is omitted. This clearly distinguishes it from sibling tools like lark_get_chat_members and 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: pass user_id to get a specific user, omit it to get your own info. It does not explicitly mention alternative tools or when-not-to-use, but the resource is distinct enough that the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lark-mcp-server MCP server](https://glama.ai/mcp/servers/YuanZhiTech/lark-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/YuanZhiTech/lark-mcp-server)

Score Badge

Copy to your README.md:

[![lark-mcp-server MCP server](https://glama.ai/mcp/servers/YuanZhiTech/lark-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/YuanZhiTech/lark-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/YuanZhiTech/lark-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server