alt Hacker NewsThis argument always sounds like two crowds shouting past each other.
Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you.
Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you working in a range of environments which need controls and management, do you have a more defensive risk tolerance ... then by the time you wrap CLIs into a form that are suitable you will have reinvented a version of the MCP protocol. You might as well just use MCP in the first place.
Aside - yes, MCP in its current iteration is fairly greedy in its context usage, but that's very obviously going to be fixed with various progressive-disclosure approaches as the spec develops.
Replies
Context usage is a client problem - progressive disclosure can be implemented without any spec changes (Claude/code has this built in for example). That being said the examples for creating a client could be massively expanded to show how to do this well
agree I don't get this discussion anyways Those are two different things, and actually they work well together..
[dead]
In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch.
We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI.
An Agent can delete a thousand items in a second while doing 30 other things.
With bespoke CLI tools we can configure them so that they cannot access anything except specific resources, limiting the possible blast radius considerably.