Most agent frontends I've used like Claude Code only give you one level deep of CLI commands to authorize, which works fine for allowing commands like `docker build:*`. But for complex CLIs like GitHub, Azure, etc. it just doesn't scale well. It is absurd to grant Claude Code permission to `az vm:*` when that includes everything from `az vm show` to `az vm delete`. Likewise, the argument that says that you should just let your LLM call APIs directly via curl or whatever, does not hold up well when Claude Code just wants raw access to all of `curl:*`.
Meanwhile, MCP tools are (currently, at least in CC) managed at the individual tool level, which is very convenient for managing granular permissions.
Perhaps there could be some "CTCP" (CLI tool context protocol; the CCP acronym does not work well) where CLI apps could expose their available tools to the LLM, and it could then be dynamically loaded and managed at a granular level. But until then, I'm going to keep using MCP.
then we can have "b az vm delete test123" be run via these agents but then b checks if az vm delete command itself is allowed or not, and if it finds that its denied then it gives an error: This command isn't allowed to run.
but if something like b az vm create test123 is done, then the command is allowed to run
Someone must have made an utility similar to b, perhaps someone can share the links of things like this, but what are your thoughts on something like this paul? I definitely feel like convenience can be wrapped around something like this rather than continue to use MCP protocol.
Access control and permissions should be handled on the backend by enforcing IAM on well-defined principals, not with MCP middleware. Claude can already bypass MCP and call APIs or use CLIs if it runs into blockers using MCP, so it’s not an effective point to implement the control.
For power users or technical users that want agents to compose data or use tools programmatically, that's less valuable, but for most people, a one-size-fits-all MCP service that is easy to use is probably best
There's the issues of dumping a bunch of tool definitions into context and eating a ton of tokens as well, but that seems more solvable
If anything, MCP needs to evolve or MCP client tooling to improve, and I could see the debate going away
You will continue to hear repeated claims of MCPs being the next internet, the real "Web 3.0" or it will be the new way we will be interacting with the web - Nope, Never and Not a chance.
People talking about MCPs don't know that they are in a bubble.
lanyard-textile•2h ago
You can provide JSON schemas to LLMs about functions it can call, and they're trained to request executions. That's the game changing technology. That's the future here.
That's what makes claude code actually work, that's what makes a good chatbot useful, and that's what makes "AI" the most interesting right now.
MCP is many things, but one very good thing is that it's merely a way to bring tools to your client easily -- and gate data by the correct level of authorization, etc.
That is useful. We will likely have that in some form forever on. It may not be called MCP though.