Search for a command to run...
I've been calling this approach NoMCP in my notes, in the same kinda spirit as NoSQL. NoSQL never meant "SQL is bad". It meant "not only SQL". Same here.
The point that an MCP server is purely an interface, and an agent with shell access can just bypass it, is what most of the MCP hype skips. For local agents I've landed in the same place: a well-shaped CLI is easier to reason about, and the security boundary is imaginary either way. The unsolved part is the one you name, trusting third-party code running with my privileges. Have you found anything that actually constrains that, or is it still read-the-source-yourself?
Yes, actually I have found a solution; at least it works for me. The idea is laid out in detail here: https://blog.iluxav.com/the-attack-was-authorized-the-missing-security-boundary-for-ai-agents
TLDR; User vendor access key with its scopes belongs to the actual user and is hidden from AI agents. Instead, there are cryptographically derived keys that can only narrow down the permissions and ONLY with the user's explicit consent for a short period of time. The approval flow works via OpenAI elicitation protocol that pops the consent in the chat, or it could be done externally via Slack, Teams, emails - whatever
Practical explorations of authorization, delegated authority, human approval, and verifiable audit trails for autonomous software agents.
APIs can verify that an agent has permission. They cannot verify that you intended its action. Here’s how attenuated capabilities and signed receipts can close that gap.
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:
Install the CLI: curl https://whatever.com/my-cli/install.sh | sh
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.
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.
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 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.
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.