Apideck has published a technically detailed critique of the Model Context Protocol, arguing that MCP tool definitions impose severe token overhead on AI agents before a single user message is processed. The post, authored by Apideck product team member Samir Amzani, quantifies the problem in concrete terms: each MCP tool definition consumes 550–1,400 tokens for its name, description, JSON schema, enums, and system instructions. Connecting three modest SaaS integrations — say, GitHub, Slack, and Sentry — can exhaust 55,000 tokens or more of a 200k context window on schema definitions alone, before any actual work begins. Apideck's proposed solution is their own CLI, which replaces the entire schema payload with an approximately 80-token system prompt and uses progressive disclosure through --help flags, so agents only load context relevant to the task at hand. The efficiency argument is supported by benchmark data from authentication startup Scalekit, which ran 75 head-to-head comparisons on Claude Sonnet 4 and found MCP consuming 4 to 32 times more tokens than CLI for identical operations; checking a repository's primary language cost 1,365 tokens via CLI versus 44,026 via MCP.

The article also references David Zhang's account of building Duet, where he described ripping out MCP integrations after encountering what he called a "trilemma": loading all tools up front destroys working memory, limiting integrations defeats the purpose, and dynamic tool loading adds latency and middleware complexity. Apideck frames the CLI approach as a structural escape from this problem — any agent capable of running shell commands can use it without protocol support, and access permissions can be baked into the binary itself. On Hacker News, discussion has centred on a growing practice of using agents like Claude Code to <a href="/news/2026-03-16-cli-skills-mcp-agent-tool-integration-framework">wrap APIs in CLIs and treat them as callable skills</a>.

Two substantive counterarguments in the HN thread complicate the CLI-as-replacement framing. First, MCP's architecture enables deterministic, cross-tool policy enforcement that CLIs cannot replicate programmatically — compound security policies such as "no web search after viewing financial data" can be enforced structurally across an MCP tool chain in ways that shell-invoked binaries cannot guarantee. Second, secret management is harder with CLIs: API credentials passed via environment variables are more exposed to prompt injection attacks, whereas MCP's out-of-process server model can isolate secrets from the agent's process tree. One commenter noted that replicating this isolation securely with a CLI either requires OS-level user permission separation or effectively re-invents a socket-server architecture. That architecture starts to resemble MCP itself.

Apideck's critique omits a material commercial conflict: the CLI is a proprietary binary that routes all calls through Apideck's paid Unified API platform ($599–$1,299/month), which normalizes 190-plus SaaS integrations for a subscription fee. Apideck's core business is directly threatened by vendor-published MCP servers from companies like GitHub and Salesforce, which would allow agents to bypass Apideck's normalization layer entirely. The company's own blog as recently as October 2025 framed MCP as a complementary opportunity; the narrative shift to "MCP destroys your context window" coincides precisely with the Apideck CLI product launch. The Scalekit benchmark cited for empirical credibility was produced by a company that sells MCP OAuth infrastructure, giving it roughly opposite commercial incentives to Apideck's — the technical data is real, but the conclusion Apideck draws from it serves a clear business interest. The token overhead the post documents is a genuine engineering problem; the proposed solution is a product pitch embedded in a legitimate technical critique.