I just view it as a relative minor convenience, but it's not some game-changer IMO.

The tool use / function calling thing far predates Anthropic releasing the MCP specification and it really wasn't that onerous to do before either. You could provide a json schema spec and tell the model to generate compliant json to pass to the API in question. MCP doesn't inherently solve any of the problems that come up in that sort of workflow, but it does provide an idiomatic approach for it (so there's a non-zero value there, but not much).

It seems the benefit of MCP is for Anthropic to enlist the community in building integrations for Claude desktop, no?

And if other vendors sign on to support MCP, then it becomes a self reinforcing cycle of adoption.

Yea it certainly does benefit Claude Desktop to some degree, but most MCP servers are a few hundred SLOC and the protocol schema itself is only ~400 SLOC. If that was the only major obstacle standing in the way of adoption, I'd be very surprised.

Coupled with the fact that any LLM trained for tool use can utilize the protocol, it doesn't feel like much of a moat that uniquely positions Claude Desktop in a meaningful way.

> And if other vendors sign on to support MCP, then it becomes a self reinforcing cycle of adoption

This is exactly what's happening now. A good portion of applications, frameworks and actors are starting to support it.

I've been reluctant on adopting MCP in applications until there was enough adoption.

However, depending on your use case it may also be too complex for your use case.

MCP is useful because anthropic has a disproportionate share of API traffic relative to its valuation and a tiny share of first-party client traffic. The best way around this is to shift as much traffic to API as possible.

First party client , meaning browser? User agent or … Electron app, or , any mobile app?

first party client as in a claude subscription will give you access (mostly app + web)

The interesting thing about MCP as a tool use protocol is the traction that it has garnered in terms of clients and servers supporting it.

I would probably call it shipping containers for LLM tool integrations.

Containers are not a big deal when viewed in isolation. But when its common size/standard for all kinds of ships, cranes and trucks, it is a big deal then.

In that sense its more about gathering community around one way to do things.

In theory there are REST APIs and OpenAPI standard, but those were not made for LLMs but code. So you usually need some kind of friendly wrapper(like for candy) on top of REST API.

It really starts to feel like a a big deal when you work in integrating LLMs with tools.

I'm a bit stuck on this, maybe you can explain why an LLM would have any difficulty writing REST API calls? Seems like it should be no problem.

No, since MCP is just an interface layer it is to AI what REST API is to DPA and COM/App DLLs are to RPA.

APA (Agentic Process Automation) is the new RPA, and this is definitely one example of it.

But AI already supported function calling, and you could describe them in various ways. Isn't this just a different way to define function calling?