2026-03-29
In late March 2026, DingTalk and Feishu open sourced their respective command line tools on GitHub within 24 hours of each other. DingTalk opened 10 core capabilities in its first batch, while Feishu covered over 2500 APIs, 11 business domains, and 19 AI Agent Skills. The two largest enterprise collaboration platforms in China pushed CLIs to the front of their product strategy almost simultaneously.
This event answers a question that has been debated over the past year but lacked hard data from platforms: when enterprise collaboration platforms take Agent integration seriously, which path will they choose first? The answer is clear. They will release a set of command line interfaces that current mainstream Agents can consume directly, rather than starting with an MCP server.
This choice, seen against the backdrop of shell-based agent workflows becoming the mainstream development paradigm, constitutes a practical rejection of the MCP-first integration path. What is being rejected is not the potential long-term value of MCP, but its priority as the primary entry point for native Agent integration on these platforms.
To understand why platforms made this choice, we must look at the consumer side. The most active Agent runtimes today, such as Claude Code, Cursor, Codex, and various shell-based coding agents, naturally run in terminal environments. Their most stable and lowest-friction actions are reading files, writing files, and executing commands. For these agents, a CLI is the default interface format and requires no additional adaptation layer.
From the platform side, Feishu and DingTalk already had complete open
platform APIs. Organizing existing APIs into commands, subcommands,
parameters, and help documentation has manageable engineering costs,
high coverage, and fits easily with existing developer habits. The
--help command is naturally a readable index of
capabilities, serving as skill documentation for agents. This path is
much shorter than deploying an MCP server, handling transport layer
configurations, and managing tool schema registration or
authentication.
Feishu’s decision to organize over 2500 APIs into a CLI reflects a straightforward judgment: let Agents use the full capabilities of the platform first before discussing higher-level protocol abstractions.
If MCP simply lost to CLIs in terms of developer adoption speed, the significance would be limited. What is worth discussing are several pressure points already exposed at the protocol level. These pressure points give platforms sufficient reason not to make MCP their preferred path.
The first pressure point is a clash in context philosophy. The core
design assumption of MCP is that all information exchange should flow
through the LLM context window, with the model maintaining full
visibility over tool calls and results. This assumption is reasonable in
Anthropic’s research environment, but it has repeatedly hit walls in
engineering reality. In scenarios like GUI rendering, long structured
data, or deterministic execution, forcing all information through the
context window reduces model intelligence, increases inference costs,
and introduces uncertainty. OpenAI’s use of the _meta field
in the Apps SDK to bypass the context window for passing GUI states
shows that one of the largest MCP users has already rejected this design
assumption in practice.
The second pressure point is dialect drift, which has moved from a
warning to a reality. The story of the _meta field did not
end with the release of the Apps SDK. OpenAI later pushed MCP Apps as a
formal product path, turning _meta and
openai/* extensions from temporary workarounds into de
facto official extension paths that carry nested GUI states, component
declarations, and interaction logic. This means any MCP server written
by a developer using the Apps SDK will not run directly on Anthropic or
other hosts.
Meanwhile, other layers of the protocol are also splitting. The SSE transport was deprecated, and the migration to streamable HTTP introduced breaking changes that required existing servers to rewrite their transport layers. The introduction of OAuth 2.1 was accompanied by a cluster of security vulnerabilities, including multiple CVEs and attack surfaces related to localhost. Subsequent fixes introduced more breaking changes, forcing enterprise customers to bear additional migration costs. At the client level, promises of interoperability have failed in specific scenarios. Kiro CLI experienced compatibility issues when connecting to certain MCP servers, and the authentication mechanism of Websets also broke in cross-host scenarios. These are not theoretical risks but real problems that developers have already encountered.
This follows a path similar to the history of SQL dialects: while a standard exists in name, implementations from different vendors are no longer directly interchangeable. For platforms, choosing a splitting protocol as the primary integration path means taking on the continuous maintenance cost of dialect compatibility.
The third pressure point is the practical burden of discovery. If an MCP server stuffs dozens or hundreds of tool schemas into the context at once, token consumption and tool selection accuracy suffer. Compensatory mechanisms like lazy loading, registry-based dispatch, and skill indexing have emerged to address this, but these are not built-in capabilities of the MCP protocol. They are organizational layers added by the community outside the protocol. While discovery is not the deepest protocol flaw of MCP, context philosophy and dialect drift are. However, the chaos of discovery increases adoption friction, making platforms more likely to choose the CLI path, which has lower organizational costs.
These three pressure points combined are not just about the pace of adoption. They represent a more substantial judgment: at this stage, for Agent integration on enterprise collaboration platforms, the protocol-level friction of the MCP-first path outweighs its standardization benefits.
Feishu and DingTalk represent the Chinese enterprise collaboration
market, but the rise of shell-native agents as a consumer category is
not limited to the Chinese community. A notable signal has also appeared
in the Google Workspace ecosystem: googleworkspace/cli
(gws). This is an experimental CLI project under the Google Workspace
organization, maintained by the DevRel team, providing terminal
interfaces for core Google Workspace services like Gmail, Drive,
Calendar, and Sheets.
To be clear, gws is not a major official product release from Google. It is closer to an experimental sample from the DevRel team and does not carry the same product commitment as the Google Cloud CLI. Therefore, it cannot be used as evidence that Google has officially chosen CLIs over MCP.
However, it still demonstrates something meaningful. Even in an ecosystem like Google Workspace, which already has a complete REST API and SDK system, the terminal environment is considered important enough to warrant a serious CLI. This aligns with the judgment of Feishu and DingTalk: shell-native agents have become a real consumer category, and platforms are starting to provide dedicated interfaces for them.
Notably, gws includes a gws mcp command, meaning the
project does not treat CLIs and MCP as mutually exclusive. This makes it
an even more honest reference. CLIs and MCP can coexist, but when
platforms evaluate priorities, the CLI is built first. In the cases of
Feishu and DingTalk, this priority judgment is even clearer, as they did
not release an MCP server at all.
Two boundaries need to be clarified.
What has been rejected by reality is MCP-first as the preferred path for native Agent integration today, not every possible long-term use of MCP. Once scenarios involve cross-runtime distribution, security isolation, or multi-dialect compatibility, the importance of the protocol layer will rise. The problem with MCP is not that the type of abstraction it seeks to solve is valueless, but that it cannot serve as the primary entry point given its current design maturity and ecosystem state. The pressure of dialect drift has moved from a warning six months ago to a reality with specific CVE numbers, breaking change records, and client interoperability failures. This gives platforms a stronger basis for avoiding the MCP-first path than they had half a year ago.
Regarding the scope of this signal: the clearest signal comes from Chinese enterprise collaboration platforms (Feishu and DingTalk), which skipped MCP to release CLIs. The Google Workspace ecosystem provides a consistent but weaker piece of evidence, as gws includes both a CLI and MCP, and the project itself has limited official status. The pace of other markets and platforms may differ. The judgment in this article is primarily based on facts that have already occurred in the shell-native agent runtime space.
This article is based on the following materials: repository
information for Feishu’s larksuite/cli and DingTalk’s
dingtalk-workspace-cli, the structure and features of
googleworkspace/cli (gws), two previous articles on MCP
(mcp.md, mcp-revisited.md), and external discussions regarding the
official status of MCP Apps, OAuth/CVE clusters, SSE deprecation, and
interoperability failures in Kiro CLI and Websets auth. No end-to-end
testing was performed on the mentioned CLIs.