Is MCP Dead? Why CLI + Skills Are Challenging Tool-Server Architectures

The agent worked yesterday. Today it burns forty thousand tokens before it reads your first instruction, and the hook that used to register identity with a coordination server fails silently after a version bump. Nothing in your prompt changed. What changed is the layer you asked to own capability integration.

That is the real shape of the "MCP is dead" argument. It is not a protocol war with a winner. It is a layer confusion, and layer confusions produce exactly this kind of expensive, intermittent failure.

What Actually Changed, and What Did Not

The Model Context Protocol is an open specification introduced by Anthropic in late 2024. It exposes tools, resources, and prompts over a standardized JSON-RPC handshake, with adoption across major clients. Nothing about that has been withdrawn. The protocol is not dying; it is being asked to do a job it was not designed to do alone.

The friction driving the narrative is specific and nameable:

• Per-turn schema re-injection, because chat-completion APIs are stateless and host clients must re-serialize the full tool catalog on every request.
• Auth and session handling, especially around token refresh, idle timeouts, and reconnect behavior.
• Debugging opacity, where a failure surfaces as a JSON-RPC error, a misread schema, or a tool-selection loop rather than a stack trace.

CLI plus skills gained momentum for two reasons. Models got better at driving terminals directly, and skills let capability descriptions load lazily instead of every turn. Neither of those is a refutation of MCP. Both are a relocation of where discovery and context cost live.

The invariant to hold: the debate is about which layer owns capability integration, not about which format wins.

Flag the uncertainty explicitly. Token and cost figures circulating in benchmarks depend on server count, schema size, model, and client implementation. Treat them as directional, not as constants you can budget against.

The Three Architectures, Stated Precisely

Before comparing, define each pattern by its mechanism: state, interface, and control flow. Otherwise the differences read as vibes.

MCP tool server. A long-lived process exposing typed schemas over stdio or streamable HTTP. The client discovers tools, injects schemas into context, and issues deterministic calls. State lives in the server process and the session.

CLI capability. The agent invokes existing binaries in its own shell environment. Discovery happens through --help and --list at the moment of need. Composition happens through pipes and redirection.

Skills. A filesystem-resident bundle of instructions and scripts the agent loads on demand. A skill can wrap a CLI or attach an MCP server to a specific task.

All three ultimately produce a command or call the model can emit, plus a result it can read. The difference is who owns discovery, lifecycle, and permission.

Note that skills are not a transport. They are a packaging and loading convention, which is why they compose with both of the other two.

Discovery and Context Cost: Where the Tax Comes From

This is the strongest concrete argument in the debate, so it deserves the mechanism rather than the slogan.

Chat-completion APIs are stateless. Host clients re-serialize the entire tool catalog on every single request. Published audits place this overhead between roughly fifteen thousand and fifty-five thousand tokens per turn in typical four-to-six-server deployments, with higher numbers under aggressive tool sprawl. The exact figure depends on your setup, but the structure does not: the tax scales with catalog size, not with task difficulty.

That produces three cascading failures.

Economic. Stateless re-injection inflates per-session spend. One published benchmark reports CLI-equivalent workflows at $3.20 versus MCP at $55.20 for the same 10,000 operations. Treat the absolute numbers as directional; the order-of-magnitude gap is the signal.

Cognitive. Once context utilization crosses roughly seventy percent, reasoning quality degrades. Models hallucinate parameters, confuse similar tools, and lose the thread of the task. The tool catalog is competing with the actual work for the same window.

Adversarial. The same schema text that describes a tool also shapes the model's attention. A malicious instruction embedded in a benign-looking tool description can hijack control flow. This is the tool poisoning attack, and it exists because descriptions are instructions.

Lazy discovery is the countermeasure. Expose tools as a CLI and let the model call --list or --help only when needed. Store tool descriptions on the filesystem and surface only short names until the task requires more. Cursor's approach does exactly this: keep descriptions on disk, tell the agent the short names, let it look up the rest.

Retrieval and gating approaches trade a small classification cost for a large schema cost, but they introduce their own failure mode: a tool that is never surfaced cannot be selected. You have moved the failure from "too much context" to "missing capability," and the second one is harder to debug because it looks like the model simply did not try.

Here is the measurable check I would run first:

# Log tokens attributable to tool definitions per turn,
# then compare against tokens spent on the actual task.
# Pseudocode for a single session:
tools_tokens = count_tokens(serialize(tool_catalog))
task_tokens  = count_tokens(user_message + assistant_reasoning + tool_results)
ratio = tools_tokens / (tools_tokens + task_tokens)

If that ratio is above roughly a third, your catalog is the bottleneck, not your model.

Deployment, Lifecycle, and Operational Drag

The operational surface area differs structurally. Use failure evidence, not preference.

MCP adds a process to run, version, authenticate, and monitor. Stateless streamable HTTP servers must handle token refresh and reconnect behavior correctly, and client handling of edge cases has been inconsistent. A documented case: a stateless server returning 405 on GET after long idle, which the spec permits, caused a reconnect loop in one client after its internal session timeout. Short idle worked; long idle broke. That is the class of bug you inherit when you own a protocol boundary.

CLI adds no daemon but inherits the ambient environment. Whatever the shell can reach, the agent can reach, including credentials and destructive commands. The operational drag is not a process; it is blast radius.

Skills add a loading and versioning problem rather than a process problem. Which skill is active, which revision, and what happens when a skill's script changes underneath a running session. That is a real failure mode, but it is a filesystem problem, not a network protocol problem.

Interface stability is the cost people underestimate. Removing a programmatic entry point to MCP tools breaks hooks, CI scripts, and multi-agent coordination that depended on it. One documented regression removed the --mcp-cli flag entirely, silently breaking session-startup hooks, multi-agent backchannel coordination, and automation scripts. There was no drop-in replacement when session identity mattered, because direct HTTP or stdio calls create new sessions with different identity.

Decision rule: count the moving parts you must operate, not the parts you must write.

Security and Permission Boundaries

Neither model is simply safer. They are safe in different places.

MCP's advantage is structural. Scoped permissions, explicit tool surfaces, and an auditable call boundary that a gateway can mediate with role-based access and logging. That is why MCP gateways are now a contested product category, with vendors building routing, per-employee token dashboards, and agent security bundles around the protocol. You do not build a governance market around a dying format.

CLI's advantage is legibility. A human can run the exact same command. Permission can be expressed as a subcommand allowlist rather than a schema, and the agent's action is reproducible in a terminal.

The risks are mirror images.

CLI's risk is blast radius. Direct shell access means destructive commands, credential exposure, and filesystem reach unless wrapped or sandboxed. The agent can rm what you can rm.

MCP's risk is the description channel. Tool descriptions shape model attention, so injected instructions in a benign-looking description can hijack control flow. The attack surface is text the model reads as guidance, not code it executes.

If you run MCP in an enterprise, the gateway is not optional. It is the enforcement point for role-based access, logging, and the boundary between agents and internal systems.

Composability and Debuggability

CLI composes through the shell. Pipes, filters, redirection, and exit codes give the agent a compositional algebra it already understands from training data.

cat server.log | grep ERROR | sort | uniq -c | sort -rn | head

That command is a program. The agent can build it, run it, inspect the output, and revise it. No schema, no handshake, no session.

MCP composes through typed contracts. Deterministic calls, type safety, and cross-client portability, at the cost of an opaque execution path the agent cannot inspect at runtime.

The debugging asymmetry is the practical consequence. A failing CLI command reproduces in a terminal. A failing MCP call often surfaces as a JSON-RPC error, a misread schema, or a tool-selection loop. You are debugging a protocol boundary and a model's interpretation of a schema at the same time.

The boundary where CLI composition stops being exact: when the capability is not a process. Remote services, stateful sessions, and multi-tenant authorization are where the protocol earns its keep. You cannot pipe your way into a governed, audited, role-scoped call to a SaaS system.

Skills can attach an MCP server to a specific task, launching it only when the agent loads that skill. That hybrid is where most teams converge, because it keeps the protocol for the cases that need it and keeps the context cost near zero for the cases that do not.

Choosing a Pattern: A Decision Boundary

Convert the comparison into a rule you can apply to your own runtime.

Default to CLI plus skills when the capability already exists as a binary, the agent runs in a controlled environment, and token budget per turn is the binding constraint. This is the common case for coding agents, and it is why the CLI approach feels faster to build against.

Use MCP when you need cross-client portability, typed contracts, centralized authorization, or a governed boundary between agents and internal systems. Remote services, multi-tenant auth, and audit requirements are the signals.

Use skills as the packaging layer regardless of transport. They are how you control what enters context and when. A skill can wrap a CLI or attach an MCP server; either way, it is the loading convention that keeps the catalog out of the per-turn tax.

Treat MCP as an edge adapter rather than the core runtime contract when the runtime is a long-running coding agent with shell access. The protocol handles the boundary to systems you do not control. The shell handles the work you do.

When not to use any of them: a single fixed capability in a single client is a function call, not an architecture. Do not build a server, a skill, and a permission model for one deterministic operation.

The failure mode is picking one pattern to do the other's job. MCP standardizes the wire between client and capability. CLI and skills standardize the runtime contract. Make the wire do the runtime's work and you pay the tools tax every turn. Make the runtime do the wire's work and you lose the governed boundary the moment you need an audit trail.

The Next Move

Instrument one agent session. Log the tokens attributable to tool definitions per turn, then log the tokens spent on actual task work. Compute the ratio.

Then re-run the same task with a lazy-discovery variant: expose the same capabilities as a CLI, or store the descriptions on the filesystem and surface only short names. Compare the ratio and the task outcome.

If the ratio drops and the task still succeeds, you have your answer for that runtime. If the task fails because a capability was never surfaced, you have found the boundary where retrieval and gating need a fallback. Either way, you are now deciding by what you must operate and what you must govern, not by which pattern is trending.