Why replace it at all? Just remove it. I use AI every day and don't use MCP. I've built LLM powered tools that are used daily and don't use MCP. What is the point of this thing in the first place?
It's just a complex abstraction over a fundamentally trivial concept. The only issue it solves is if you want to bring your own tools to an existing chatbot. But I've not had that problem yet.
That solution will not work as well when the interfaces have not been standardized in a way that makes it so easy to import them into a script as a library.
Coding against every subtly different REST API is as annoying with agents as it is for humans. And it is good to force vendors to define which parts of the interface are actually important and clean them up. Or provide higher level tasks. Why would we ask every client to repeat that work?
There are also plenty of environments where having agents dynamically write and execute scripts is neither prudent nor efficient. Local MCP servers strike a governance balance in that scenario, and remote ones eliminate the need entirely.
It's not particularly hard for current models to wire up a http client based on the docs and every major company has well documented APIs for how to do so either with their SDKs or curl.
I don't know that I really agree its as annoying for agents since they don't have the concept of annoyance and can trundle along infinitely fine.
While I appreciate the standardization I've often felt MCPs are a poor solution to a real problem that coincided with a need for good marketing and a desire to own mindspace here from Anthropic.
I've written a lot of agents now and when I've used MCP it has only made them more complicated for not an apparent benefit.
MCP's value lies in the social alignment of people agreeing to use it, it's technical merits seem dubious to me while its community merits seem high.
I can accept the latter and use it because of that while thinking there were other paths we probably should have chosen that make better use of 35 years of existing standards.
Well if everyone was already using Swagger then yes it would be a moot point. It seems you do in fact agree that the standardized manifest is important.
If everyone had a clear spec with high signal to noise and good documentation that explains in an agent-friendly way how to use all the endpoints while still being parsimonious with tokens and not polluting the context, then yes we wouldn't need MCP...
Instructing people how to do that amounts to a standard in any case. Might as well specify the request format and authentication while you're at it.
Yep. And those that did implement the standard did so for a different set of consumers with different needs.
I'm also willing to make an appeal to authority here (or at least competitive markets). If Anthropic was able to get Google and others on board with this thing, it probably does have merit beyond what else is available.
I don’t get your point. Obviously some spec is needed but why does it have to be MCP?
if I want my api to work with an llm id create a spec with swagger. But why do I have to go with mcp? What is it adding additionally that didn’t exist in other spec?
You can ask an AI agent that question and get a very comprehensive answer. It would describe things like the benefits of adding a wire protocol, having persistent connections with SSE, not being coupled to HTTP, dynamic discovery and lazy loading, a simplified schema, less context window consumption, etc.
I thought the whole point of AI was that we wouldn't have to do these things anymore. If we're replacing engineering practice with different yet still basically the same engineering practice, then AI doesn't buy us much. If AI lives up to their marketing hype, then we shouldn't need MCP.
To write code. They still depend on / benefit from abstractions like humans do. But they are (for now) a different user persona with different needs. Turns out you can get better ROI and yield ecosystem benefits if some abstractions are tailored to them.
You could still use AI to implement the MCP server just like humans implemented Open AI for each other. Is it really surprising that we would need to refactor some architecture to work better with LLMs at this point? Clearly some big orgs have decided its worth the investment. You may not agree and that's fine - that happens with every type of new programming thing. But to compare generally against the "marketing hype" is basically just a straw man or nut picking.
My product is "API first". Every UI task has an underlying endpoint which is defined in the OpenAPI spec so we can generate multiple language SDK. The documentation for each endpoint and request/response property is decent enough. Higher level patterns are described elsewhere though.
90% of the endpoints are useless to an AI agent, and within the most important ones only 70% of the fields are relevant. The whole spec would consume a huge fraction of context tokens.
So at a minimum I need a new manifest with a highly pared down index.
I'm not claiming that we're not in this classic XKCD situation, but the point of the cartoon is that that just how it be... https://xkcd.com/927/
Maybe OpenAPI will be able to subsume MCP and those manifests can be generated from the same spec just like the SDKs themselves.
> The only issue it solves is if you want to bring your own tools to an existing chatbot.
That's a phenomenally important problem to solve for Anthropic, OpenAI, Google, and anyone else who wants to build generalized chatbots or assistants for mass consumer adoption. As well as any existing company or brand that owns data assets and wants to participate as an MCP Server. It's a chatbot app store standard. That's a huge market.
Isn't that the way if works, everybody throws their ideas against the wall and sees what sticks? I haven't really seen anyone recommend using xml in a long while...
And isn't this a 'remote' tool protocol? I mean, I've been plugging away at a VM with Claude for a bit and as soon as the repl worked it started using that to debug issues instead of "spray and pray debugging" or, my personal favorite, make the failing tests match the buggy code instead of fixing the code and keeping the correct tests.
I have Linear(mcp) connected to ChatGPT and my Claude Desktop, and I use it daily from both.
For the MCP nay sayers, if I want to connect things like Linear or any service out there to third party agentic platforms (chatgpt, claude desktop), what exactly are you counter proposing?
(I also hate MCP but gets a bit tiresome seeing these conversations without anyone addressing the use case above which is 99% of the use case, consumers)
Easy. Just tell the LLM to use the Linear CLI or hit their API directly. I’m only half-joking. Older models were terrible at doing that reliably, which is exactly why we created MCP.
Our SaaS has a built-in AI assistant that only performs actions for the user through our GraphQL API. We wrapped the API in simple MCP tools that give the model clean introspection and let us inject the user’s authenticated session cookie directly. The LLM never deals with login, tokens, or permissions. It can just act with the full rights of the logged-in user.
MCP still has value today, especially with models that can easily call tools but can’t stick to prompt. From what I’ve seen in Claude’s roadmap, the future may shift toward loading “skills” that describe exactly how to call a GraphQL API (in my case), then letting the model write the code itself. That sounds good on paper, but an LLM generating and running API code on the fly is less consistent and more error-prone than calling pre-built tools.
Yes, let's have the stohastic parrot guessing machine run executables on the project manager's computer - that can only end well, right? =)
But you're right, Skills and hosted scripting environments are the future for agents.
Instead of Claude first getting everything from system A and then system B and then filtering them to feed into system C it can do all that with a script inside a "virtual machine", which optimises the calls so that it doesn't need to waste context and bandwidth shoveling around unnecessary data.
Easy if you ignore the security aspects. You want to hand over your tokens to your LLM so it can script up a tool that can access it? The value I see in MCP is that you can give an LLM access to services via socket without giving it access to the tokens/credentials required to access said service. It provides at least one level of security that way.
So, I've been playing with an mcp server of my own... the api the mcp talks to is something that can create/edit/delete argument structures, like argument graphs - premises, lemmas, and conclusions. The server has a good syntactical understanding of arguments, how to structure syllogisms etc.
But it doesn't have a semantic understanding because it's not an llm.
So connecting an llm with my api via MCP means that I can do things like "can you semantically analyze the argument?" and "can you create any counterpoints you think make sense?" and "I don't think premise P12 is essential for lemma L23, can you remove it?" And it will, and I can watch it on my frontend to see how the argument evolves.
So in that sense - combining semantic understanding with tool use to do something that neither can do alone - I find it very valuable. However, if your point is that something other than MCP can do the same thing, I could probably accept that too (especially if you suggested what that could be :) ). I've considered just having my backend use an api key to call models but it's sort of a different pattern that would require me to write a whole lot more code (and pay more money).
The less context switching LLMs of current day need to do the better they seem to perform. If I’m writing C code using an agent but my spec needs complex SQL to be retried then it’s better to give access to the spec database through MCP to prevent the LLM from going haywire
It's just a complex abstraction over a fundamentally trivial concept. The only issue it solves is if you want to bring your own tools to an existing chatbot. But I've not had that problem yet.