Hacker News Reader

Comment by shaolinspirit | Hacker News Reader

mcp's are barely needed, good cli's are usually better

For coding agents I agree with you, but people are building for more than just developers now. The idea that a user facing service would give their agents shell access is kind of horrifying, as you then make it possible for prompt injection to mean a system take over.

MCP has its place. It should not be the default for many use cases, but if you need to expose specific tools in a secure way to agents that are not trusted to run shell commands then MCP is great. Developers need to think beyond their own use cases and consider architecture patterns if they're going to build, not just consume, AI systems.

100% agree. I've been building MCPs that enable Claude (my agent of choice to have voice conversations with). These hook into my home maintenance system (https://homemaintlist.com) and workout tracking system (https://tallyup.codewalkers.net) plus several private mcp servers I've made to expose Claude to specific services. These all allow me to just have conversations with Claude and have all these very specific things available and take action on them.

Curious how you talk to Claude? I have some automations set up but I feel locked into Gemini on android if I want to be able to use a wakeword (e.g. while driving). I use Claude for non-voice but haven't found a convenient way to start up a chat with Claude.

I looked into this a bit yesterday and had similar issues. One hacky option on Mac could be to [1] use BlackHole virtual audio device as the system default input (which Claude expects), [2] vibe code some app that can pick your actual mic as the input device (browser engines seem to have a pretty good support for this stuff), [3] stab a speech-to-text model there (whisper or lighter) that detects the wake word from a stream and [4] proxies the audio after that to the output side of BlackHole. I did not try it myself yet, though.

You could make a push-to-speak-hardware-button and talk like walkie-talkies. If you have an existing device and you only want to do it in software, there's usually extra buttons you can bind to, like the "AI" button, or volume button.

Yeah...wish there was a better way than just opening the app and clicking the voice button. I haven't found one. My talking is usually in the car, so it's not too inconvenient for me to do that.

I see, yeah that works when I know I'll be in a situation for a while where I may want the option to say something or going over something like verbal brainstorming but I find I am much more often having a random thought and want to capture it right away without pulling out my phone or interrupting what I'm doing.

Can only hope google relaxes their limitations on choice of ai assistant. In the meantime I'm setting up a raspi with openwakeword to just act as an interface for voice to voice interactions for while I'm home.

Excellent points. We still need to employ good cybersecurity principles when granting AI access to tools and resources. Let’s not throw out everything learned in the last three decades. Keep the access narrow in scope and targeted.

Completely agree, MCP is going to be a continuing topic for providing capabilities to LLMs for non-technical users. If you're in a tightly regulated enterprise environment asking your IT admin to enable CompanyX's MCP Connector in Claude is much more palatable than asking for a CLI tool to be installed as well.

It's about where the agent runs more than the users - hooking e.g. Datadog's Bits AI up with access to relevant repos in my company's GitHub org to find out what's driving the metrics its looking at likely wouldn't be a thing if not for GitHub's MCP server and OAuth, I doubt whoever admins that would bother if Datadog had to set up some completely custom thing.

fwiw, I’ve only done cli tools for agents to install in their own sandboxes, not access on remote machines.

This was just to avoid MCP infra, but the newer stateless protocol makes that much more trivial.

I do agree with you and was not aware of those reasons before, thanks for clarifying.

I agree. MCPs have the massive problem of not being composable, which is a big strength of shells/CLIs allow.

People make the argument that it doesn't matter for non-programmers. I use Bluebeam (a pdf editor which is standard in the construction industry) daily, and it has an MCP, but a big problem is that if the agent wants to import or export a large amount of data from a document, then it has to regurgitate a bunch of tokens into or out of the MCP. If it were a CLI, then it would just pipe things in and out as it needs.

I ended up just having the agent make a script that wraps the MCP so it can use it as a CLI instead.

> MCPs have the massive problem of not being composable, which is a big strength of shells/CLIs allow

Tool calls being composable or not are a property of the harness being used, not of MCP servers

As a trivial counterpoint, streaming outputs and proper signaling support is required for being able to compose efficiently under any setup/harness. The more layers of abstractions you add, the more likely it is your MCP server didn't support the usecase that some later agent came up with and so you can't stop your stream when you find your top 3 hits. If you don't even own the server, you can't even modify the source and restart it to fix it.

There are usecases of MCPs (e.g. serving outside customers via proprietary tools), but composability has not been in the minds of the early users of MCP and it is one of the hundreds of little practical drawbacks they have when used in house.

It just removes the need to install a cli tool on your local machine. I in general are sceptical before I install some external 3rd party software. With MCP over HTTP transport, the MCP might still talk to your agent and tell the agent to do XYZ, but your agent can still treat that command as malicious and refuse to execute. While not perfect, it is just another layer of security.

It is the same with a wepapp: You could argue you don't neex browser apps if the user just install a software on their computer, but we feel better using the sandboxing environment of your browser.

I find it depends a lot on the model used and what the MCP does. I have agents trawl research papers, and just giving the raw API to DeepSeek leads to lots of wasted tokens and bad use of the API options. Here, wrapping the API to minimize the available options and providing sane defaults fixes that. Perhaps a frontier model can use the API directly without issues, but for DeepSeek a good MCP wrapper is very useful. Besides that, having control and limits in the MCP is very useful for some ratelimited APIs

Depending on use case, would start with just solid HTTP APIs, then a simple CLI to consume them, then add MCP using the new spec. Build slowly only adding new access protocols as needed.

Be surprised how far apps can get with just solid & well documented APIs. Modern agents are smart!

My suggestion is to just let the HTTP client itself be the MCP server.

Then you don't need an MCP server per service anymore, you just need one and a whitelist of authorized services.

MCPs with oauth have a better security story

not this tired discusssion again

Reply on news.ycombinator.com