lark-cli: The Official Lark CLI That Treats AI Agents as First-Class Users

What lark-cli Solves and Who It Is For

lark-cli addresses a real pain: interacting with Lark's sprawling API surface from a terminal or an AI agent without writing bespoke HTTP calls. The README lists 18 business domains, including Messenger, Docs, Base, Sheets, Calendar, Mail, Tasks, and Meetings, and claims 200+ curated commands plus 26 AI Agent Skills. That is a lot of surface area. The intended audience is twofold: human developers who want a quick way to script Lark actions, and AI agents that need a reliable, structured interface to operate Lark on behalf of a user. The 'Agent-Native Design' bullet is not marketing fluff; the entire tool is shaped around agent call success rates, with concise parameters and structured output. If you are a developer who only needs one or two APIs, this might be overkill, but if you juggle multiple Lark products, it consolidates them into a single command set.

The Three-Layer Architecture: Shortcuts, API Commands, Raw API

The README describes a three-layer command system: Shortcuts, API Commands, and Raw API. Shortcuts are human- and agent-friendly, like `lark-cli calendar +agenda`, which presumably gives a quick agenda view. API Commands are 'platform-synced', meaning they track the official API surface and expose each endpoint as a command with parameters. Raw API gives full coverage, likely for endpoints that do not have dedicated commands yet. This layering is a sensible design: it lets a human type a natural shortcut, an agent call a structured API command, and a power user fall back to raw requests. The trade-off is that you have to learn which layer to use for which task. The README does not give a full command list, so you will need to explore the help output after install. The existence of three layers also suggests that the 200+ commands are not all equally polished; shortcuts are curated, while raw API commands are likely generated and less forgiving.

Installation and Quick Start: npm, Source, and the Skills Step

The recommended install is `npx @larksuite/cli@latest install`, which pulls the npm package. That is the fastest path and does not require Go or Python. If you build from source, you need Go v1.23+ and Python 3, then `git clone`, `make install`, and crucially `npx skills add larksuite/cli -y -g` to install the CLI SKILL, which the README marks as required. After install, configuration is interactive: `lark-cli config init` sets up app credentials, and `lark-cli auth login --recommend` logs in with auto-selected scopes. The quick start ends with `lark-cli calendar +agenda`, which is a concrete example of a shortcut. The source build adds friction, but the npm path is genuinely three steps. One notable gap: the README does not explain what the SKILL installation actually does beyond being required, so you are trusting that it wires the commands into your agent environment correctly.

AI Agent Skills: Structured for Machines, but What Is the Format?

The README claims 26 AI Agent Skills, and the table says they are 'compatible with popular AI tools'. The Skills live in a `skills/` directory in the repo. The idea is that an agent can load a Skill definition, which likely describes commands, parameters, and output schemas, and then call lark-cli without extra setup. This is a concrete mechanism: instead of an agent guessing at API endpoints, it gets a curated set of callable commands. The README also mentions that appending `.md` to any Open Platform doc URL fetches raw Markdown, which helps agents read documentation. However, the README does not specify the Skill format (e.g., is it a JSON schema, a Markdown file, or a function-calling spec?). That is a real gap for an evaluator. You will need to inspect the `skills/` directory yourself. The claim that every command is 'tested with real Agents' is an assertion, not something you can verify from the README alone, so treat it as a marketing statement until you see evidence.

Security Features: Injection Protection and Keychain Storage

The README lists three security features: input injection protection, terminal output sanitization, and OS-native keychain credential storage. Input injection protection is relevant for agents because a user might paste untrusted text into a command, and an agent could be tricked into executing malicious instructions. Terminal output sanitization likely prevents terminal escape sequences from being rendered, which is a known attack vector. Keychain storage avoids putting tokens in plaintext config files. These are sensible defaults, but the README gives no details on how the injection protection works or what it covers. It also does not mention whether the sanitization applies to all output or only certain commands. For an enterprise, the README points to an 'Embed lark-cli in your Agent' document and `extension/` packages, which allow a wrapper `main` to centralize credentials and audit logging. That is a separate path, not the default, so individual users get the keychain, but enterprises need to build their own wrapper.

Limitations and Failure Modes: Coverage vs. Depth

The biggest limitation is that the README is a promise of breadth, not a proof of depth. With 200+ commands across 18 domains, each domain likely has shallow coverage. For example, the Meetings domain mentions 'analyze transcripts' and 'manage Minutes', which are complex features, but you have no idea how reliable they are. The README itself warns about security risks in a section titled 'Security & Risk Warnings Read Before Use', but the cleaned text does not include that content, so you are left without specifics. Another failure mode: the tool depends on your Lark tenant's app scopes. If you run `auth login --recommend`, it auto-selects scopes, but you might not get the permissions you need for a specific command, leading to confusing API errors. The README also notes that Project (Meegle) is a separate CLI (`meegle-cli`), so the 18 domains are not all in one binary. That fragmentation is a real limitation if you need cross-domain workflows involving Meegle.

Alternatives: MCP Servers and Custom Scripts

The main alternative is to use Lark's official MCP (Model Context Protocol) server, which the README references indirectly through the 'embed-feishu-cli-in-agent' document. MCP servers give AI agents a standardized way to call tools, and Lark likely offers one. The difference in approach is that MCP is a protocol for agent-tool communication, while lark-cli is a CLI that an agent can shell out to. With MCP, the agent gets a native tool interface with schema validation; with lark-cli, you get a command-line process with text output. For human use, the alternative is writing your own scripts against the Lark Open API using a language of your choice. That gives you full control but requires you to handle auth, pagination, and error handling yourself. lark-cli abstracts those away, but you are locked into its command structure. If you only need one domain, a custom script might be simpler. If you need many domains and agent compatibility, lark-cli is more attractive.

Maintenance, License, and Upgrade Considerations

The project is under the MIT license, which is permissive and allows commercial use and modification. The repository is actively maintained, with releases v1.0.90, v1.0.91, and v1.0.92 pushed within days of each other in late August 2026. That cadence suggests rapid iteration, but it also means you should expect frequent updates. The install method via `npx @larksuite/cli@latest install` implies you can re-run it to get updates, but the README does not describe an upgrade command. If you build from source, you will need to `git pull` and `make install` again. The `npx skills add` step also needs to be re-run if Skills change. There is no mention of a changelog or migration guide, so upgrading between minor versions might introduce breaking changes without notice. The extension packages for enterprise embedding suggest a path for long-term maintenance, but they add complexity. For an individual, the npm install is low-friction, but you should pin a version if you rely on it in scripts, because the rapid release cycle could change behavior unexpectedly.

Editorial conclusion

Adopt lark-cli if you are an individual developer or an AI agent builder who needs direct, scriptable access to Lark's core domains without writing custom API wrappers. The npm install path and interactive login make it approachable for humans, while the structured output and Skills are clearly aimed at agent workloads. Do not adopt it if you need deep customization of the command surface, or if you operate under strict enterprise security policies that require centralized credential management and audit logging, as the README only hints at an extension path for those cases. Before adopting, verify the exact list of Skills and commands against your Lark tenant's enabled scopes, and confirm that the current release (v1.0.92) supports the specific API versions your workflows depend on. The project is actively maintained with frequent releases, but the documentation is thin on failure modes, so plan to test against your own tenant before committing.

Official sources

1. Official README
2. Project repository
3. Release notes