How do I use feishu-cli-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@feishu-cli-mcp show my calendar agenda" 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.

feishu-cli-mcp

by axunrun

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

feishu-cli-mcp

把官方 lark-cli 暴露成 MCP 服务，让 Agent 通过清晰的上下文协议使用飞书/ Lark CLI 的完整能力。

设计

本项目不重写飞书 API，也不手工封装 200+ CLI 命令。MCP 只做一层受控代理：

lark_cli_run：执行任意 lark-cli 参数数组，覆盖 CLI 全部能力。
lark_cli_schema：查询 API 方法参数、响应、身份和 scopes。
lark_cli_help：查询服务或命令帮助，发现快捷命令。
lark_cli_auth_status：检查登录、scope 和身份状态。

Agent 上下文通过 MCP Resources / Prompts 暴露：

lark://agent-guide：Agent 使用规则。
lark://command-model：快捷命令、API 命令、Raw API 的选择顺序。
lark://skills：官方 CLI 覆盖的业务域。
lark://security：写操作、scope、Docker 和 HTTP 安全规则。
lark://schema/{method}：动态读取某个 API 方法 schema。
lark_plan_command：让 Agent 先规划命令。
lark_safe_write：让 Agent 走 schema、dry-run、用户确认流程。

Related MCP server: mcp-cli-gemini

Agent 协议

Agent 必须按这个顺序使用：

读 lark://agent-guide 和 lark://command-model。
优先查 lark_cli_help，选择 +shortcut。
快捷命令不够时，用 lark_cli_schema 查 API 命令。
API 命令不够时，才用 lark_cli_run 调 raw api METHOD /open-apis/...。
读操作用 intent=read。
写操作用 intent=write，先 help/schema，能 dry-run 就先 dry-run。
intent=write 或 intent=auth_config 必须传 confirm=true，否则服务拒绝执行。
机器读取优先加 --format json。

示例：

{
  "tool": "lark_cli_run",
  "arguments": {
    "args": ["calendar", "+agenda", "--format", "json"],
    "intent": "read"
  }
}

写操作示例：

{
  "tool": "lark_cli_run",
  "arguments": {
    "args": ["im", "+messages-send", "--chat-id", "oc_xxx", "--text", "hello", "--dry-run"],
    "intent": "write",
    "confirm": true
  }
}

本地运行

npm install
npm run build
node dist/index.js --transport stdio

HTTP：

copy .env.example .env
npm run build
node dist/index.js --transport http

MCP URL：

http://127.0.0.1:3333/mcp

如果设置了 MCP_HTTP_TOKEN，客户端需要传：

Authorization: Bearer <token>

Docker / Unraid

cp .env.example .env
docker compose up -d --build

Unraid 模板关键配置：

Repository/Image: feishu-cli-mcp:latest 或你的 GitHub 镜像地址
WebUI / MCP URL: http://<unraid-ip>:3333/mcp
Port: 3333:3333
Volume: /mnt/user/appdata/feishu-cli-mcp/lark-cli:/data/lark-cli
Env:
- MCP_TRANSPORT=http
- MCP_HOST=0.0.0.0
- MCP_PORT=3333
- MCP_HTTP_TOKEN=<强随机 token>
- LARK_CLI_HOME=/data/lark-cli

持久化点是 /data/lark-cli。这里保存 CLI 配置和授权状态。

初始化飞书授权

容器启动后，通过 MCP 执行：

{
  "tool": "lark_cli_run",
  "arguments": {
    "args": ["config", "init", "--new"],
    "intent": "auth_config",
    "confirm": true
  }
}

然后登录：

{
  "tool": "lark_cli_run",
  "arguments": {
    "args": ["auth", "login", "--recommend", "--no-wait"],
    "intent": "auth_config",
    "confirm": true
  }
}

把 CLI 输出里的授权 URL 发给用户完成浏览器授权。

验证

npm run check
docker compose up -d --build
curl http://127.0.0.1:3333/healthz

Available Tools

4 tools

lark_cli_auth_statusCheck lark-cli auth statusA

Read-onlyIdempotent

Check current Feishu/Lark login status, granted scopes, and active identity before calls.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`args`	Yes
`json`	No
`risk`	Yes
`stderr`	Yes
`stdout`	Yes
`command`	Yes
`exitCode`	Yes
`timedOut`	Yes
`nextSteps`	Yes
`truncated`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, establishing the safe, non-mutating nature. The description adds specific context by naming what is checked (granted scopes, active identity), which is valuable beyond the annotations. No contradiction detected.

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 conveys the essential purpose and usage context without redundancy. Every word earns its place, and it is appropriately sized for a simple tool.

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?

Given the tool's simplicity (no parameters), the presence of an output schema, and comprehensive annotations, the description is complete. It covers what the tool does and when to use it, while structured data handles return format and safety details.

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 tool has zero parameters, so the schema coverage is trivially 100% and there is no parameter ambiguity. Per guidelines, the baseline for 0 params is 4, and the description need not compensate for missing parameter info. It correctly implies no inputs are required.

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's function with a specific verb ('Check') and resources ('Feishu/Lark login status, granted scopes, and active identity'). It is distinct from sibling tools (run, schema, help), which focus on execution, metadata, and CLI assistance respectively.

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 phrase 'before calls' provides explicit usage context, indicating when to invoke this tool (prior to other operations). However, it does not explicitly mention alternatives or conditions when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lark_cli_helpRead lark-cli helpA

Read-onlyIdempotent

Read help for a service or command. Use before shortcuts because shortcuts are discovered via help.

ParametersJSON Schema

Name	Required	Description	Default
`args`	No	Command path before --help, e.g. ["calendar"] or ["im","+messages-send"].

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`args`	Yes
`json`	No
`risk`	Yes
`stderr`	Yes
`stdout`	Yes
`command`	Yes
`exitCode`	Yes
`timedOut`	Yes
`nextSteps`	Yes
`truncated`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the bar is lower. The description adds a non-obvious behavioral trait: shortcuts are discovered via help, which is useful context for the agent. No contradictions with annotations. Output schema covers return values, so no need to describe them.

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 only two sentences long, front-loaded with the main purpose ('Read help...') and then a concise usage hint. Every sentence earns its place with no wasted words.

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?

For a simple help-retrieval tool with one well-documented parameter and an output schema, the description covers the essential purpose and usage context. The output schema handles return values, so no further explanation is needed. The description is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description covers 100% of the parameter semantics, including examples like ['calendar'] or ['im','+messages-send']. The tool description itself does not mention the 'args' parameter, so it adds no extra semantic value beyond the schema. Baseline 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 explicitly states 'Read help for a service or command,' which is a specific verb+resource action. It distinguishes this tool from siblings (lark_cli_run, lark_cli_schema, lark_cli_auth_status) by focusing on help retrieval. The added note about using before shortcuts clarifies its role in the toolchain.

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 provides a clear when-to-use guideline: 'Use before shortcuts because shortcuts are discovered via help.' This tells the agent when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, but the sibling tool names imply the other use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lark_cli_runRun lark-cli commandA

Destructive

Run the official lark-cli with argv-style arguments. Use schema/help first. Set intent=write or auth_config for side-effect commands; those require confirm=true.

ParametersJSON Schema

Name	Required	Description
`args`	Yes	Arguments after lark-cli, e.g. ["calendar","+agenda","--format","json"].
`intent`	Yes	Command risk class. read/schema/help are safe; write/auth_config require confirm=true.
`confirm`	No	Required for write/auth_config commands after user approval or dry-run review.
`timeoutMs`	No
`maxOutputBytes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`args`	Yes
`json`	No
`risk`	Yes
`stderr`	Yes
`stdout`	Yes
`command`	Yes
`exitCode`	Yes
`timedOut`	Yes
`nextSteps`	Yes
`truncated`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey destructiveHint=true and readOnlyHint=false; the description adds that side-effect commands require confirm=true, reinforcing safety expectations. It also mentions argv-style execution, implying arbitrary command behavior, which is useful context beyond the structured annotations.

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?

Two sentences front-load the core action and then provide the most critical safety guidance. 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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic command runner with an output schema and safety annotations, the description gives essential first-step guidance (schema/help), risk classification, and the confirm gate. It could mention timeout/output limits, but those are already represented in the input schema, so the description is sufficiently complete.

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 60% and includes useful descriptions for args, intent, and confirm. The description restates the confirm requirement already present in the schema and does not add new parameter-level meaning beyond what the enum and field descriptions already provide.

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?

Description states 'Run the official lark-cli with argv-style arguments' with a specific verb and resource, making the action unmistakable. It is clearly distinct from sibling tools like schema/help/auth_status by positioning itself as the actual command executor.

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?

Explicitly instructs 'Use schema/help first,' which directs the agent to consult sibling tools before running arbitrary commands. It also clarifies that write/auth_config commands require confirm=true, providing meaningful context for side-effect handling, though it doesn't enumerate specific 'when not to use' cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lark_cli_schemaInspect lark-cli API schemaA

Read-onlyIdempotent

Inspect parameters, request body, response shape, supported identities, and scopes. Call this before API commands or risky writes.

ParametersJSON Schema

Name	Required	Description	Default
`method`	No	Optional API method name, e.g. "calendar.events.instance_view". Omit to list schemas.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`args`	Yes
`json`	No
`risk`	Yes
`stderr`	Yes
`stdout`	Yes
`command`	Yes
`exitCode`	Yes
`timedOut`	Yes
`nextSteps`	Yes
`truncated`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by enumerating the schema aspects inspected, which goes beyond the annotation data. No contradictions are present.

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 two sentences, front-loaded with the core purpose, and every clause adds value. There is no filler or redundant information.

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?

With a full output schema available and clear annotations, the description covers the tool's role completely. It mentions the inspection scope and the importance of calling it before commands, which suffices for this simple one-parameter 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 description coverage is 100% because the sole 'method' parameter is documented with an example and the omit-to-list behavior. The description adds no further parameter-specific meaning, so the baseline 3 applies.

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 uses the specific verb 'Inspect' and names the resource (lark-cli API schema) plus the aspects it covers (parameters, request body, response shape, supported identities, scopes). This clearly distinguishes it from sibling tools like lark_cli_run and lark_cli_auth_status.

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?

It explicitly instructs to 'Call this before API commands or risky writes,' providing clear timing and context. It doesn't mention exclusions or alternative tools by name, but the sibling names and the 'before' guidance make the use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 6, 2026
- First observedlark_cli_auth_status
- First observedlark_cli_help
- First observedlark_cli_run
- First observedlark_cli_schema

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: running CLI commands, inspecting schemas, reading help, and checking auth status. No overlap or ambiguity between them.

Naming Consistency5/5

All tools follow the consistent pattern 'lark_cli_' followed by a descriptive action (run, schema, help, auth_status). Perfectly uniform naming convention.

Tool Count5/5

Four tools is well-scoped for a CLI wrapper server, providing essential operations without unnecessary bloat. Each tool earns its place.

Completeness4/5

The surface covers running, schema lookup, help, and auth status, which are the core needs for interacting with lark-cli. A minor gap is lack of explicit logout or config tools, but these are workable via lark_cli_run with appropriate arguments.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202

Related MCP Servers

mcp-cli-catalog
Shell Access
abcpro1
A
license
Not graded
quality
D
maintenance
An MCP server that publishes CLI tools on your machine for discoverability by LLMs
Updated 10 months ago (2025-11-16 20:50 UTC)
14
1
MIT
mcp-cli-gemini
AI & Machine Learning Command Line
rlaksana
F
license
A
quality
D
maintenance
Wraps the Gemini CLI as an MCP server, enabling AI tools to perform Gemini queries, interactive sessions, and extension management via a unified tool.
Updated a year ago (2025-10-13 07:14 UTC)
1
1
-
wrapmcp
Shell Access Command Line
SubZtep
A
license
Not graded
quality
C
maintenance
Universal MCP server that wraps any CLI tool, enabling AI assistants to run commands via natural language.
Updated 3 months ago (2026-06-08 02:02 UTC)
MIT
SmartCLI MCP Server
File Systems Shell Access Knowledge & Memory
jiahuiwu944-hash
A
license
Not graded
quality
B
maintenance
Exposes SmartCLI's built-in agent tools (file operations, code search, shell commands, web search, memory, and snapshots) as MCP endpoints, allowing external clients to leverage them over stdio or HTTP.
Updated 19 days ago (2026-08-18 19:37 UTC)
1
MIT

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/axunrun/feishu-cli-mcp'

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