wecom-cli: A Rust CLI That Puts WeCom's Business APIs Behind Terminal Commands

The gap wecom-cli fills between the WeCom console and a script

WeCom's open platform exposes a broad set of business APIs, and the README lists the ones this tool covers: messages, mail, documents, document management, online spreadsheets, smart sheets, smart documents, todos, calendars, meetings, WeDrive and contacts. Reaching any of those from a shell normally means obtaining a token, signing requests, handling expiry, and reimplementing the same JSON shapes per endpoint. wecom-cli collapses that into commands such as wecom-cli auth init and wecom-cli auth show, and the README points to docs/cli-reference.md for the full command set. The stated audience is explicit in the repository description: humans and AI agents, both operating WeCom from a terminal. That second audience shapes more of the design than the first. An agent does not read prose documentation well, so the project ships a separate Skill and a docs/skills.md file. The practical consequence is that the command surface, not the library API, is the contract. If you are writing a Rust program that links against WeCom logic, this is not that; the README describes a CLI, and the install path is npm, not cargo.

What the command surface actually covers, category by category

The breadth is the selling point, and the README's table is specific enough to plan against. Messaging is push-only in the described form: the tool sends to single chats or group chats that the bot has recently conversed with, in Markdown, image, file, voice or video form. That qualifier matters. It is not a general broadcast tool, and the README does not describe a way to message arbitrary users who have never interacted with the bot. Mail covers send, reply, forward, search and reading message detail. Documents cover creation, import, reading, append and overwrite, with a separate management category for search, rename, member permissions and join rules across several document types. Spreadsheets and smart sheets get their own rows, including CSV and Excel import, row appends, sub-sheet management, and for smart sheets the field, record, view and chart layers. Todos support create, read, update, delete, assign participants and complete. Calendars include participant management, multi-member free/busy queries, and meeting room lookup and booking. Meetings cover scheduling, cancellation, participant updates, list and detail queries, and reading meeting minutes plus transcription text. WeDrive handles search, metadata, upload and download. Contacts search by name, pinyin or alias and return basic member info. The free/busy and room-booking rows are the ones that suggest this was built against real scheduling workflows rather than a checklist of endpoints.

Two installers, one credential store, and why both steps are marked required

The quick start is four commands and the README labels the second one as required, which is unusual enough to read carefully. First, npm install -g @wecom/cli installs the CLI globally. Then npx skills add WeComTeam/wecom-cli -y -g installs the CLI Skill, also globally. Only after that does wecom-cli auth init configure credentials, interactively, once, defaulting to a QR scan with --manual available for manual entry. wecom-cli auth show reports authorisation status. The prerequisites are Node.js 18 or later, a WeCom account, and optionally a bot ID and secret, with the README linking to WeCom's own help page for obtaining them. The platform list is macOS on x64 and arm64, Linux on x64 and arm64, and Windows on x64. Two details deserve attention. The binary is written in Rust but distributed through npm, so the toolchain you need on the host is Node, not cargo, which is friendlier for agent sandboxes that already have Node. And the Skill is a separate global install from the CLI itself, so a machine can end up with the command present and the agent integration absent, or vice versa. If an agent reports that it cannot find the tool, that split is the first thing to check.

The agent Skill is a second product, and the README treats it that way

Most CLI projects mention agent support in a sentence and move on. Here it gets a top-level section, a dedicated document at docs/skills.md, and a mandatory install step. The reasoning is visible in the repository structure: a Skill is not a man page. It is a description of when and how to invoke commands, written for a model that will decide on its own whether to call them. That decision layer is where the risk sits. A Skill that describes forty commands across twelve categories gives an agent a large action space, and the README's own example of the messaging constraint (recently conversed chats only) is exactly the kind of boundary that has to be encoded in the Skill or the agent will attempt sends that fail. The README does not reproduce the Skill's contents, so the honest position is that the quality of the agent experience cannot be judged from the README alone. You would need to read docs/skills.md before trusting an autonomous caller with write operations such as overwriting a document or cancelling a meeting. The -y and -g flags in the install command mean the add runs without prompting and installs globally, which is convenient in provisioning scripts and worth knowing if you audit what lands on a developer machine.

Where wecom-cli is the wrong choice

Three cases stand out. The first is the messaging constraint already noted: if your use case is notifying employees who have never talked to the bot, the README's description of pushing to recently conversed chats does not cover you, and nothing in the material suggests an alternative path through this tool. The second is credential automation. auth init is interactive by default and the documented non-interactive option is --manual, which still means a human supplying values rather than a token exchanged from a CI secret. For a headless pipeline that provisions a fresh machine per job, that is friction the README does not resolve. The third is scope. If you need a single WeCom API call inside a larger Rust service, pulling in a Node-distributed CLI and a global Skill is a heavy answer to a small question, and the README presents no library interface to link against. There is also a documentation gap worth naming plainly: the README links docs/data-collection.md under a data collection heading but does not summarise it, so anyone evaluating this for a regulated environment has to open that file themselves before drawing conclusions about what leaves the machine.

How this differs from calling the WeCom APIs directly

The obvious alternative is the WeCom open platform SDKs and HTTP APIs themselves, which is what this tool sits on top of. The difference is where the work lives. With direct API calls, your code owns token lifecycle, request signing, retries and the JSON shapes of each endpoint, and in exchange you get full control over concurrency, error handling and which endpoints you touch. With wecom-cli, that work is inside the binary and your interface is a subprocess call with arguments. For a shell script, a cron job, or an agent that reasons over command names, the subprocess interface is a better fit because it is discoverable and the failure modes are exit codes rather than exceptions. For a service that needs to fan out thousands of requests with custom backoff, the CLI boundary adds a process spawn per operation and takes away the control you would want. There is a middle option the README does not discuss: using the CLI interactively to learn the correct request shapes, then calling the underlying APIs directly in production. That is a reasonable path given that docs/cli-reference.md documents the commands, though the README does not present the CLI as a teaching tool.

Licence, maintenance and what to verify before you commit

The licence is MIT, stated in the README badge and in the LICENSE file it links to. MIT is permissive: it allows commercial use, modification and redistribution with the copyright notice and permission notice retained, and it comes with no warranty. That last clause is the one that matters operationally, because this tool holds credentials that can send mail, alter documents and book meeting rooms on behalf of your organisation. Nothing here is legal advice, and if you redistribute a modified build you should read the actual LICENSE text rather than this summary. On maintenance, the repository is not archived and the last push recorded is 2026-09-10, but no releases were retrieved, so there is no published version history to plan upgrades against. The README sets a Rust minimum of 1.75 in its badge, which matters for anyone building from source rather than installing the npm package. The upgrade surface you actually own is three things: the globally installed CLI, the globally installed Skill, and the credential state written by auth init. Because the Skill and the CLI version independently, an upgrade that changes command names could leave the Skill describing commands that no longer exist, and the README offers no versioning guidance for that pairing. Check docs/cli-reference.md and docs/skills.md together after any upgrade, and re-run wecom-cli auth show to confirm the stored authorisation still resolves.

Editorial conclusion

wecom-cli is for teams already on WeCom that want scripted or agent-driven access to messages, docs, mail, calendars, meetings, WeDrive and contacts without writing HTTP client code, and for anyone building a WeCom-facing agent that needs a stable command surface. It is the wrong tool if you only need one narrow API call, if you cannot run Node.js 18 or later on the host, or if you need a fully non-interactive credential flow, since auth init defaults to QR scan and only offers --manual as an alternative. Before adopting, verify three things: whether the bot ID and secret are available for your tenant, what the CLI Skill installs on the machine, and what docs/data-collection.md says about telemetry, because the README links that document without summarising it.

Official sources

1. Issues
2. License: MIT
3. README
4. WecomTeam/wecom-cli on GitHub