The CLI Will Outlive Your MCP Server

MCP wraps AI-friendly conventions around software that should already have a good API or CLI. Fix the source, put security and policy where they belong, and treat the wrapper as disposable.

Twenty years ago, enterprise software wrapped XML in SOAP envelopes and described services through machine-readable contracts. SOAP solved a real interoperability problem.

Then the machinery became the architecture. The surrounding WS-* family accumulated standards for security, policy, discovery, addressing, transactions and reliable messaging. Each made sense alone. Together they produced an industry of envelopes, generated clients and specialists explaining why those clients had stopped speaking to one another.

I feel a faint memory of SOAP whenever the response to "we need AI to use our system" is "build an MCP server".

The Model Context Protocol (MCP) is lighter and uses JSON-RPC rather than XML. It gives AI hosts a common way to discover and invoke tools. That is convenient. But convenience is becoming confused with architecture, and the protocol is receiving credit for problems that already have better owners.

Every frontier-model release quietly cancels part of this integration roadmap. Models are getting better at reading --help, inspecting schemas, writing small programs, calling APIs and filtering JSON. The half-life of a hand-written wrapper around those capabilities is shrinking.

The source-first rule is simple: improve the authoritative API or command-line interface (CLI) before compensating for it. Generate what can be generated. Add an adapter only for value that remains.

I came to this view through use, not protocol design. Across strategy work and substantial changes to TypeScript, .NET, iOS, Android, Kotlin and Java, frontier coding agents relied mainly on files, build tools, documentation and ordinary command lines. MCP was rarely central.

Remote systems have not required custom MCP servers either. I use Cloudflare, GitLab, Jira, Confluence and Slack through their APIs. GitLab already publishes an API and glab; every capable coding agent with shell access can use them. Adding an MCP server does not create access to GitLab. It creates another way to perform the same operations.

Chrome complicated the argument. Access to a real browser, rendered pages, console output, network traffic and performance traces changed what an agent could verify. Its experimental CLI exposes those tools through ordinary commands and JSON, although it is generated from the MCP definitions and talks to a background MCP daemon. The valuable asset is the browser capability and its authoritative schema. The CLI demonstrates that MCP need not be the model-facing interface.

The Wrapper Is Not the Capability

An MCP tool has a name, description and input schema. It has the same semantic problem as any interface: somebody must explain what the operation does, what its fields mean and what happens when it fails.

Wrapping a poor API and poor documentation in MCP does not repair the underlying system. It creates a second API and documentation surface. The new layer may have nicer names, but somebody must keep them aligned with the old ones.

A hand-written wrapper also creates another versioned contract. Changes to the underlying API, MCP software development kit or client behaviour can require translation work that adds no product capability. What a bore.

Several independently built wrappers around the same product are not evidence that the organisation needs several MCP servers. They are product feedback. If each adapter adds its own search, discovery, comparison, caching, recent-change queries or authentication workarounds, those capabilities belong upstream. The best wrapper may be a useful prototype and an excellent requirements document. Consolidating the wrappers into another wrapper merely preserves the wrong ownership.

This duplication made more sense when models could not explore software reliably. In February 2026, Nx explained why it deleted most of its MCP tools. A capable agent could call nx show project, process the result with jq and retain only the facts it needed. Passing a large project graph through a dedicated tool added tokens without adding capability.

Anthropic reached a related conclusion from inside the MCP ecosystem. In its illustrative code execution with MCP workflow, loading definitions on demand and filtering results in code reduced tool-related context from 150,000 tokens to 2,000. MCP remained underneath. The gain came from letting the model use ordinary software techniques rather than making every intermediate result part of the conversation.

For local software, the CLI is the durable default. It offers discovery through --help, composition through pipes, exit codes, operating-system permissions and decades of tooling. Add non-interactive operation, structured errors and optional JSON output, and humans, continuous integration and agents can use the same interface.

For a remote service, the equivalent investment is a well-designed API with a machine-readable contract. Improve the interface every consumer can use before funding one only AI clients need.

Documentation changes shape in the same way. A model can generate a tour of an API when needed. It cannot reliably infer whether pending means awaiting approval, awaiting settlement or merely stuck. Tool descriptions and JSON schemas are documentation in another format. Explanatory prose is becoming cheap; names, contracts, invariants and error semantics are becoming more valuable. As I argued in The Code Is No Longer the Scarce Part, producing prose is cheap; maintaining truth is not.

MCP Is the Wrong Layer

The standard defences of MCP sound persuasive because they name real problems: credentials, restricted network access, consent, audit, state and communication with live processes. The mistake is assigning those problems to MCP.

Credentials belong in identity infrastructure, workload identity or a credential broker. Authorisation belongs in the service and may be enforced through an API gateway. Network restrictions belong in egress policy, proxies and firewalls. Rate limits and request policy belong in the gateway. Audit belongs in gateway, service and host telemetry. Human consent belongs in the host or an approval workflow. Business state belongs in the authoritative service.

If an agent must not reach an administrative API, expose a narrow operation behind a gateway. If its process must not see a token, let a credential broker or trusted service perform the call. If an action needs approval, make the host ask. An MCP server can sit somewhere in each design, but the security comes from those controls, not from MCP.

The live-process argument is no stronger. Chrome has the Chrome DevTools Protocol. Debuggers, databases, build systems and integrated development environments have native protocols, sockets, APIs and CLIs. MCP can wrap them. It does not create the connection or own the state.

Nor does the absence of a shell establish a need for MCP. If a host can call an MCP server, it can call a constrained HTTP API. Choosing one sanctioned integration surface may improve the product experience, but it is a packaging decision.

The LSP Defence Is Weaker Than It Looks

The strongest case for MCP is the Language Server Protocol (LSP). Before LSP, support for each programming language had to be rebuilt for each editor. A shared protocol let one language server work with many tools.

But LSP did more than standardise an envelope. It defined shared semantics for documents, diagnostics, symbols, completions and edits. Editors could not inspect an arbitrary language service and improvise those behaviours.

Frontier agents can improvise. They can all call the same documented CLI. The shared integration already exists; adding MCP changes the route rather than the destination.

MCP standardises how a host lists and invokes GitLab-specific tools. It does not standardise what a GitLab merge request and a GitHub pull request mean. The model supplies much of that semantic adaptation by reading the interfaces.

This changes the old many-to-many arithmetic. A common protocol reduces integrations only when every client would otherwise require bespoke code. If every capable agent can use the same API or CLI, the common integration was already there.

MCP may still win distribution. Hosts may build marketplaces, vendors may publish adapters and customers may ask for the familiar checkbox. Standards acquire network effects. That is a commercial reason to offer MCP, not an architectural reason to put product meaning, security policy or business logic inside it. Generate the adapter from the authoritative interface and keep it disposable.

Fix the Source Before Adding the Overlay

Before funding an MCP server, ask a frontier model to use the existing interface. Give it the CLI, API documentation, examples and a safe execution environment. Watch where it fails.

If the failure is ambiguous names, inconsistent errors, missing schema, unsafe retries or awkward authentication, fix the product interface. Humans and every form of automation benefit. An MCP wrapper over the same defect merely makes the defect less visible.

Harvest useful semantics from the adapters, move them into the authoritative API or client, and generate whatever compatibility layer remains.

This is the same source-first discipline I argued for in A Monorepo Is a Knowledge Graph. Start with authoritative source and build relationships, then add a graph for runtime and human knowledge that does not exist there. An overlay earns its place by answering a residual question, not by concealing a foundation we declined to fix.

MCP may survive as a compatibility format. SOAP survived too. Survival does not make a protocol the right centre of gravity.

The CLI will outlive your MCP server. Build the durable interface first, then generate the envelope if the market still wants one.