One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool.
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.
This is solved by the agent having its own identity and credentials. Why would you share your login and identity with your AI agent?
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.
Anti-pattern imho. Agents should operate within granular identity and permission scopes, with audit and log trails for all data operations (read, write, etc).
can something of a cli utility be made which can deny any request from moving on, let's name this cli b which takes a user level configuration at say ~/.config or have a way to enter it via cli too or within the context of the folder which it is running in
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.
The token overhead is something I’ve been feeling lately. It’s annoying to see the context window shrink just from tool definitions that never even get triggered. For me, as a dev, I’d much rather just throw together a quick bash wrapper. But I can see the appeal for the non-technical side of our team who just want to 'plug and play' with AI connections without asking for a PR. It feels like MCP is aiming for that specific market gap.
I don't follow the cutting edge of AI practice super closely and I'm confused. Why are people trying to say MCP is dead? I've set up a few MCP servers (mostly language servers and servers to access my company's Confluence), and they seem genuinely very useful.
I'm not sure if it's irony or what, but I personally realized how absolutely goofy MCP is when I vibecoded with gemini in like 2 seconds a quite reasonable bash agent (for use with my local llama stuff.)
There's really not much of a point in "MCP" and/or formality here when working with LLMs, nothing bash etc can't do. If you want to use them, fine, but understand that at the other end you're always dealing with a nonzero amount of unpredictable vibes.
I don't think MCP is going anywhere, as much as I prefer CLIs or skills generally. Where MCP really shines is reducing friction and footguns for using a service, but at the expense of less versatility and expressiveness. You get a cookie-cutter way of using tools to interact with that service, which is easy to set up, doesn't require the user to download a CLI or have their agent interact with an API
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
There’s nothing stopping agents from composing MCP requests and responses, or from them writing programs to process the responses. MCP tools and resources are just as composable and programmable than any CLI - and more so than most because they are structured data.
I think MCP should not the main discussion point -- it certainly is the acronym that travels the world, but the real underlying features to track the sentiment of are "tools."
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.
It's not going to make sense for every company to release an MCP server. If you count use/integration in their internal workflows and agentic dev as adoption, it's probably near 100%.
What's the purpose of this? There is no replacement for MCP.
We need a protocol for calling tools that works with structured outputs, this is what we have.
The content analysis can be off. The following text has been flagged "negative":
> STOP asking Claude Code to design your apps. It’s great for logic, not design. Google Stitch 2.0 + Claude Code via MCP is the workflow that finally fixes the AI slop problem.
Most of all these sources are on X (low quality garbage engagement bait posts) and SEO spam blogs that repeat the same talking points that we have all heard about MCPs. The other sources like Reddit, LinkedIn are non-existent on this site.
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.
One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool.
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.
This is solved by the agent having its own identity and credentials. Why would you share your login and identity with your AI agent?
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.
IAM is generally binary (allowed yes/no) whereas MCP usually supports more nuance (always allow/ask if risky/always ask/no)
You can have agents that serve multiple different users with varying levels if permission
Anti-pattern imho. Agents should operate within granular identity and permission scopes, with audit and log trails for all data operations (read, write, etc).
Copilot: https://learn.microsoft.com/en-us/entra/agent-id/identity-pl... | https://learn.microsoft.com/en-us/purview/audit-copilot (for example)
TLDR Maintain an identity boundary whenever possible.
[dead]
can something of a cli utility be made which can deny any request from moving on, let's name this cli b which takes a user level configuration at say ~/.config or have a way to enter it via cli too or within the context of the folder which it is running in
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.
Something like this? https://github.com/brycehans/toolgate
The token overhead is something I’ve been feeling lately. It’s annoying to see the context window shrink just from tool definitions that never even get triggered. For me, as a dev, I’d much rather just throw together a quick bash wrapper. But I can see the appeal for the non-technical side of our team who just want to 'plug and play' with AI connections without asking for a PR. It feels like MCP is aiming for that specific market gap.
I don't follow the cutting edge of AI practice super closely and I'm confused. Why are people trying to say MCP is dead? I've set up a few MCP servers (mostly language servers and servers to access my company's Confluence), and they seem genuinely very useful.
Because many people have a very narrow view of what MCP is useful for. For organizational usage there isn't really an alternative.
A lot of people want to move away from them because they bloat the context a lot more than Skills do.
I'm not sure if it's irony or what, but I personally realized how absolutely goofy MCP is when I vibecoded with gemini in like 2 seconds a quite reasonable bash agent (for use with my local llama stuff.)
There's really not much of a point in "MCP" and/or formality here when working with LLMs, nothing bash etc can't do. If you want to use them, fine, but understand that at the other end you're always dealing with a nonzero amount of unpredictable vibes.
I don't think MCP is going anywhere, as much as I prefer CLIs or skills generally. Where MCP really shines is reducing friction and footguns for using a service, but at the expense of less versatility and expressiveness. You get a cookie-cutter way of using tools to interact with that service, which is easy to set up, doesn't require the user to download a CLI or have their agent interact with an API
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
There’s nothing stopping agents from composing MCP requests and responses, or from them writing programs to process the responses. MCP tools and resources are just as composable and programmable than any CLI - and more so than most because they are structured data.
I think MCP should not the main discussion point -- it certainly is the acronym that travels the world, but the real underlying features to track the sentiment of are "tools."
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.
It's not going to make sense for every company to release an MCP server. If you count use/integration in their internal workflows and agentic dev as adoption, it's probably near 100%.
What's the purpose of this? There is no replacement for MCP. We need a protocol for calling tools that works with structured outputs, this is what we have.
in principle you could wrap an mcp's api calls in a trivial curl shell script and turn it into a skill? so are they replaceable? sure.
I thought "who exactly is saying it's dead?" and found your ranking gives it a 94/100 liveliness, so I guess not that many.
The content analysis can be off. The following text has been flagged "negative":
> STOP asking Claude Code to design your apps. It’s great for logic, not design. Google Stitch 2.0 + Claude Code via MCP is the workflow that finally fixes the AI slop problem.
Most of all these sources are on X (low quality garbage engagement bait posts) and SEO spam blogs that repeat the same talking points that we have all heard about MCPs. The other sources like Reddit, LinkedIn are non-existent on this site.
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.
[dead]
[dead]