A post came across my feed this week. The claim was hard. MCP will be dead within one or two years. Agents will still need integrations. Command-line interfaces are a stronger base for agent work.
Henrik Hansson wrote the post. He is a founder, and his company builds on CLIs. The post got about 200 reactions and more than 100 comments.
The comments were better than the post.
I read all of the comments. I have experience on both sides. In March I wrote MCP Is Everywhere, But Where Are the .NET Examples?. I have shipped C# MCP servers since then. I also work in a terminal most days. My agents have a shell, a repository, and a test runner. I have seen both models succeed in production on client systems. I have seen both models fail there too.
This is my conclusion. The composability argument is correct. The claim that MCP will die is wrong.
The Part That Is Right
Start with the strongest version of the CLI case. It deserves a fair reading.
An MCP tool call is one action. The agent selects a tool. It calls the tool. It reads the result. Then it decides the next step. MCP has no built-in way to combine those calls into a program. Each step costs one model pass.
A CLI can be composed. You can send the output of one command into the next command. You can put commands in a script. You can name the script, commit it, and run it again next month. The agent does more than call your software. It writes new software on top of your software.
Discovery is also better. An agent does not need every command in its context. It can list the installed programs. It can run --help. It can read the subcommands. It loads only the text for the current task. One program can expose hundreds of operations and stay quiet until you ask.
I measured the other side of this cost. I moved my Claude Code setup from a 564-line memory file to skills that load on demand. The context that loads on every turn dropped by 82 percent. The procedure text did not get smaller. It stopped loading all at once. A long tool list has the same cost. If you connect an agent to 20 servers, you pay for every definition on every turn.
The terminal evidence is strong. Coding agents became good in a shell. They read files. They run commands. They run tests. They read the failure. They try again. The investment went into that loop, and the capability came from that loop. I replaced my 10-agent conversion tool with native subagents. The replacement was files, commands, and one slash-command orchestrator. It works better than the tool it replaced. Some evenings I run it from my phone with Tailscale and tmux.
Composability increases in value as you add more tools. On my machine, the terminal wins.
Now look at the example in the original post.
The Bank Example Shows the Other Side
The argument used a bank. An agent reads an internal database. It reads Outlook. It calculates in Excel. It writes a report. With MCP, the agent makes one call at a time. With CLIs, the agent writes a program, saves the program, and shares it.
I built a system close to that example. I added a natural-language assistant to a live enterprise billing system. The data was operational. The customers were real. The deadline was a trade show.
The calls were the easy part. I connected the assistant to the existing Dapper service layer. The pipeline was ready in a few days. The assistant never runs SQL. It calls the same services as the rest of the application.
The hard part was the control around the calls. Who is asking? What can this user see? What happens if the question means a write? What do you log, and in what form, for the person who asks next quarter? That work took longer than the feature. A write-intent guard runs before the model is called. Each answer is limited to the caller. Each tool call is an event. The event records the caller, the parameters, the duration, and the result.
A shell does not give you that control in the protocol. A shell gives you a process. The process has the rights of the user who started it.
One comment stated this clearly. With the gh CLI, an agent can do every action that the token allows. With a GitHub MCP server that exposes two tools, the same agent can do two actions. That difference is large. Most enterprise systems have coarse permissions. They have no separate policy for each action. The CLI receives all of those permissions. A short tool list is often the only place where a team can enforce least privilege.
The bank example supports the other side. In that example, the bank owns every system. Change one fact. Put the database at a company that has never seen your agent. The script is no longer the important part.
The Question That Settles Most of This
The useful comments in that thread described the same split. Nobody gave it a name. I will.
Whose machine is it?
There are two zones. Each zone needs different controls.
Zone one is the workspace of the agent. This zone is my repository, my container, and my machine. The agent has a shell, a file system, and a test suite. In this zone, composability is the goal. Give the agent real tools. Let it write scripts. Let it keep the scripts that work. Do not put a protocol between an agent and grep.
Zone two is a system of record that another party owns. This zone is production, a client tenant, or a partner API. In this zone, the interface is a contract. The contract needs a caller identity. It needs a limited permission. It needs an approval path for dangerous actions. It needs a record of what happened. You will build that layer. MCP is one wire format for it. If you skip the protocol, you still write one. You write it yourself, on a Thursday.
Use this rule: composability inside the workspace, and contracts at the boundary.
This rule matches my systems today. I did not plan that shape. Production forced it.
What Dies
One part of this debate is dying. The protocol is not that part.
Thin wrappers die. If your MCP server has one tool for each REST endpoint, you built a weaker SDK. The server adds a network hop and a token cost. The model must read each tool definition on every turn. You gain nothing.
Servers that copy an API die. One comment said this clearly. Design an MCP server around what the agent is trying to do. Do not copy a programming interface that was built for people. I agree. Most MCP servers fail here. Forty CRUD tools make a bad server. My billing assistant has four tools. Each tool answers a question that a person actually asks. That small number is the design.
Tool lists that always load die. Do not connect 20 servers at startup. You pay for all of them on every turn. Load a server when the task needs it. A good CLI stays quiet until you run --help. Do the same with MCP.
What remains is a small, controlled surface. Put it at the edge of systems that you will not give to a shell. Most enterprise systems are in that group.
You Can Compose Without a Pipe
The original argument has a technical gap.
The claim says that MCP means one call for each model pass, with no end to that pattern. That claim is already false. Anthropic shipped Programmatic Tool Calling. I wrote about it in Stop Chatting with Your LLM. Start Compiling. The model writes code that calls the tools. Intermediate results stay out of the context window. Token use drops. Accuracy goes up. You can save the program.
That is composability. A pipe is not required. You need a runtime and typed functions.
Compare direct tool calls with composed tool calls. Do not frame the choice as CLI against MCP. Direct calls are the weak part. Harnesses are already replacing them. The integration layer under those calls remains.
The work will feel like a terminal. The connection will stay a protocol.
The Audit Record
One comment belongs on a whiteboard.
A tool call is a record by design. It has a tool name, parameter names, a result, and a time. You get an audit trail even if you did not plan one.
A shell pipeline becomes a record only if someone builds the record. The log then holds a command string and some standard output.
A weekend script does not need that record. A question from a regulator or a supervisor, two years later, does. Do not ask what the agent was able to do. Ask what you can rebuild about what it did, from the record written at the time.
I made the same argument in You Can't Build a World Model on an Illegible System. Records are an architecture choice. If your agents write no records, you cannot read the system later. You only get more throughput.
There is a second trade, and I do not like it. One hundred noisy tool definitions are a problem you can see. One hundred scripts written by an agent, with no owner, are a problem you cannot see. I prefer to debug the problem I can see.
What to Build This Quarter
If you design .NET systems and you must choose this quarter, build this shape.
- Give agents a real terminal in their own workspace. Give them a shell, a repository, tests, and a build. Do not wrap work that the file system already does well.
- Ship a CLI for your internal tools. Include your scripts, your generators, and your migration steps. Composability pays here. The cost is low.
- Keep a protocol at the boundary. If a call touches production, a client tenant, or a partner, use a short tool list. Attach a caller identity.
- Design tools around intent, and count them. If a server has more than a few tools, you published your schema. You did not publish a capability.
- Load servers only when a task needs them. Treat context as a budget.
- Log each tool call as a structured event. Record the caller, the tool, the parameters, the duration, and the result. Remove sensitive fields before you write the log.
- Block write intent in code before the model runs. A prompt is not the guard.
- Return structured errors. Tell the agent whether the cause was permissions, a timeout, or bad input. The agent can then retry or stop. An error with no structure teaches the model nothing.
This list does not depend on which side of the argument wins. You keep this work either way.
My Prediction
MCP will not be dead in two years. It will be ordinary.
People will stop writing about it. It will become infrastructure, as HTTP did. It will sit at the edge of systems that need a caller, a permission, and a log line. Agents will call it from code. They will not call one tool at a time. Most people will stop noticing it.
The terminal will keep winning inside the workspace. Agents learned to work there. A pipe is still the cheapest way to compose commands.
The two-year deadline came from a founder whose product is built on CLIs. I do not blame him. His composability argument is valid, and he wrote it more clearly than most people on the other side. Read the deadline with that fact in view. "The standard my competitor uses will die" is not a neutral forecast.
For more than 30 years, I have watched people announce the death of protocols that were only inconvenient. A protocol dies when it solves no problem. MCP solves identity, scope, and evidence at a boundary. That problem will remain.
Build the CLI. Keep the contract. Ship the audit trail.