Discussion

lanyard-textile: 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.

paulirwin: 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.

jzymbaluk: 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.

_andrei_: 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.

tcoff91: A lot of people want to move away from them because they bloat the context a lot more than Skills do.

rvz: 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.