# Do we really need MCP? Before anything else, one clarification, because without it this whole post turns into a strawman: I'm talking only about MCP servers that run **locally**, on the same machine as the agent. The `npx whatever-mcp` kind that talks to your database, your files, your infrastructure. Remote MCP servers in the cloud, the kind that give a browser agent OAuth access to some SaaS, solve a different problem, and I have no argument with them. If that's your use case, this post is not about you. Ok. So here is what keeps bugging me. I want my coding agent to send a Slack message when a long build finishes. The standard 2026 answer: find a Slack MCP server, add it to a JSON config, paste the webhook into an env var, restart the client. If I use three different agent tools, I do this three times, in three different config formats. And the whole time there's a quiet voice in my head saying: the agent already has a shell. Why am I installing a server? Because look at what a local MCP server actually is. It's a long-running process, on my machine, running as my user, with my credentials in its environment, speaking JSON-RPC over stdin to an agent that can also run arbitrary shell commands in the same session, or make API calls — again with my credentials (agents acting on a user's credentials is a whole problem by itself, more on that at the end). There is no security boundary here. The agent could bypass the server and do the thing directly. The server is purely an interface. So the real question is narrower than it first looks: for an agent that already has shell access, is a JSON-RPC server a better interface than a good CLI? Maybe. It was designed agents-first, with well-defined input schemas, and it usually returns well-structured, predictable JSON. But... We already know agents are good with CLIs. They use `gh`, `docker`, `kubectl`, `stripe` — and the best-in-class harnesses lean on `cat`, `grep`, `curl`, `ssh` — fluently, today, with no protocol layer and no per-client config. Nobody wrote an MCP server for git. Nobody felt the need. What I discovered, by actually building this and using it on a daily basis, is that the answer can be a good old CLI tool (in my case a single binary) installed with a simple curl command, like thousands of other CLI tools out there: 1. Install the CLI: `curl https://whatever.com/my-cli/install.sh | sh` 2. During install it asks: do you want to install the `my-cli` SKILL.md? The skill can explain the CLI to agents and expose some of the commands, but really you can just instruct the agent to call `--help` — and there you go: your agent knows the input structure of every command, and by convention `--json` tells it what output format to expect. **That's the whole idea.** ## Where this might be wrong I'm writing this to find out which counterargument kills it, and I'm sure there could probably be plenty of them, so here are the candidates as I see them. Maybe schemas matter more than I think. I believe that `--json` output plus strict validation plus proper error messages that can correct the agent behavior may close the gap on incorrect invocations, but I haven't measured error rates of agents calling CLIs vs MCP tools. Someone should. I'd genuinely like to see that data. Maybe shell-less hosts are the future. If most agent usage moves into sandboxed environments with no shell, then CLI-first becomes the niche and MCP the default, and my scope of "trusted local dev machines" is less relevant. Maybe I'm underestimating why MCP exists at all. The N×M integration problem was real. A CLI-plus-Skill convention is arguably just another standard, a very thin one, and "very thin standard" is what everyone says right before fragmentation. Maybe persistent connections are the common case rather than the edge case, and everyone building one-shot CLIs ends up writing daemons badly. If you have experience pointing either way, especially on the error rates, that's exactly the reaction I'm hoping for. ## The problem neither side solves — but I think I'm onto something Here's the thing I keep circling back to, and it applies to MCP and to my CLI idea equally: neither one has an answer for trust. Whatever the interface, the end state is the same. Third-party code I didn't read, running with my privileges, holding my credentials, driven by an autonomous agent. JSON-RPC vs argv is almost cosmetic next to that. Today the only ways to know what a tool will actually do are: read the source, scan it, or hope. My implementation, in short: the tool ships with a signed manifest declaring exactly what it needs — which hosts, which paths, which secrets. A human approves that request once. A runtime then enforces the boundary, so the code physically cannot exceed what was approved, no matter what its next action is. The agent can use the granted permission but never expand it. The code can use a secret but never read it. I wrote up some of my thoughts and practical implementation of this in [The attack was authorized: the missing security boundary for AI agents](https://blog.iluxav.com/the-attack-was-authorized-the-missing-security-boundary-for-ai-agents) post, and so far, running my own tools with this approach is holding up. I mention it here because it reframes everything above: the CLI vs MCP thing is about convenience. The conversation we should be having is about authority. ## What I'm actually asking If you've built an MCP server: was it genuinely the best interface for your tool, or just the default thing you build when you want agents to use it? If your tool already existed as a CLI, what did the wrapper add for local use? And if you think I'm wrong, tell me where. That's the point of publishing this.