A recent essay argues that the Model Context Protocol was designed for an earlier generation of AI assistants and should now give way to direct HTTP APIs and command-line tools. Its strongest technical observation is that an agent with broad terminal access can inspect documentation, write a script, call several APIs, and orchestrate a workflow without a dedicated MCP server. That is a meaningful capability, but it does not by itself establish that MCP has become unnecessary for every agent or deployment.
The essay being examined argues that MCP was always a bad idea; this image captures that opening position for the article’s counterargument.
The disagreement turns on scope. Anthropic introduced MCP in November 2024 as an open standard for two-way connections between AI applications and external data sources. Its stated purpose was to replace bespoke connectors with a common architecture: servers expose capabilities, while clients discover and invoke them. That description explains why MCP is useful as an integration and governance layer; it does not prove that every implementation is efficient or that the protocol is the best interface for every agent.
The case for direct access is strongest when an agent already has a reliable execution environment, enough context to understand an API, and permission to reach it. A documented REST endpoint or a mature CLI can then be more flexible than a fixed collection of MCP tools. The agent can construct requests, combine services, and adapt when an endpoint changes. However, this comparison assumes capabilities that many production agents deliberately lack. Terminal access is not merely another transport option: it can expose credentials, local files, network resources, and actions beyond the intended service.
That distinction matters for security and operations. A narrowly scoped MCP server can present selected tools instead of unrestricted network or shell access. It can also centralize authentication, authorization, revocation, and audit logging at a boundary controlled by an administrator. Those are potential architectural benefits of MCP, not guarantees that every MCP deployment implements them securely. The evidence supplied does not include a comparative security audit, performance study, or incident data showing that MCP is safer, faster, or cheaper than a proxy-mediated API design.
The essay also identifies a genuine scaling problem: many servers and verbose tool schemas can consume model context and make selection harder. Tool discovery, search, and programmatic calling are responses to that problem. Anthropic reported more than 10,000 active public MCP servers in December 2025 and said its API had added Tool Search and Programmatic Tool Calling to handle large tool sets and reduce latency in complex workflows. Those are Anthropic’s ecosystem and product claims, not independent measurements, but they show that the ecosystem is treating context bloat as an engineering problem rather than simply accepting it.
Direct APIs solve a different part of the problem. They can offer broad functionality without translating every operation into a separate declared tool, and standard content negotiation may let an agent request concise text or Markdown. Yet an API specification still has to be discoverable, understandable, versioned, and compatible with the agent’s runtime. A CLI can provide a stable interface, but only when one exists, is documented, exposes machine-readable output, and is safe to invoke autonomously. The supplied sources do not demonstrate that these conditions hold across the services MCP currently connects.
The governance history complicates the claim that MCP is merely an Anthropic experiment tied to outdated models. Anthropic announced in December 2025 that it was donating MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, while saying that the project’s governance model would remain unchanged. That move may support a case for broader stewardship, but it does not validate the reported adoption figures or settle the technical tradeoffs. It does mean the protocol’s future cannot be assessed only as a feature of one vendor’s assistant.
For builders, the practical choice is therefore conditional. A terminal agent with carefully controlled permissions may need fewer MCP wrappers and benefit from direct API or CLI access. A multi-user application, managed desktop assistant, or enterprise workflow may instead need a constrained capability boundary, delegated credentials, consistent user consent, and centralized logs. MCP can provide a common way to expose that boundary, although a well-designed API gateway or service proxy could provide some of the same controls without using the protocol.
The evidence supports a narrower conclusion than “MCP was always a bad idea.” It supports the observation that direct interfaces can be more expressive for capable agents, and that large MCP deployments create discovery and context-management challenges. It does not establish that terminal-capable agents represent the default production environment, that direct access removes authentication risk, or that MCP lacks value where unrestricted execution would be inappropriate. The useful engineering question is not whether agents can call APIs; it is which interface provides the required capability with the least access, operational complexity, and exposure.