What sort of structure would you propose to replace it?
What bodies or demographics could be influential enough to carry your proposal to standardization?
Not busting your balls - this is what it takes.
What bodies or demographics could be influential enough to carry your proposal to standardization?
Not busting your balls - this is what it takes.
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.
It's easier for end users to wire up than to try to wire up individual APIs.
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.
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.
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).
There is huge value in having vendors standardize and simplifying their APIs instead of having agent users fix each one individually.
Have the agents write code to use APIs? Code based tool calling has literally become a first party way to do tool calling.
We have a bunch of code accessible endpoints and tools with years of authentication handling etc built in.
https://www.anthropic.com/engineering/advanced-tool-use#:~:t...
Feels like this obviates the need for MCP if this is becoming common.
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.
On runtime problems yes maybe we need standardisation.
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.
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?
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 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.
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.
Yes, and it's called OpenAPI.
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.
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)
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.
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.
I wrote a bit on the topic here: https://tombedor.dev/make-it-easy-for-humans/
This kind of LLM’s non-determinism is something you have to live with. And it’s the reason why I personally think the whole agents thing is way over-hyped - who need systems that only work 2 times out of 3, lol.
Needs a sandbox, otherwise blindly executing generated code is not acceptable
Also, the new foundation isn't called "The MCP Foundation", but the "Agentic AI Foundation". Clearly a buzzword-compliant name, but also hedging the bet that MCP will be the long-term central story.
Anthropic themselves support this style of tool calling with code first party now too.
If for nothing else than pure human empathy.