[troupo]

> MCP is not just providing an API

It does just provide an API. Your client may have a way to talk to some software via MCP protocol. You know, like a client can talk to a server exposing an endpoint via an API.

> And it does so in a standard way so that my client is available across AI providers.

As in: it's an API on a port with a schema that a certain subset of software understands.

> What’s the alternative? Providing a sandbox to execute arbitrary code and make API calls?

MCP is a protocol. It couldn't care less what you do with your "tool" calls. Vast majority of clients and servers don't run in any sandbox at all. Because MCP is a protocol, not a docker container.

> Having an LLM implement OAuth on the fly when it needs to make an API call?

Yes, MCP has also a bolted-on authorisation that they didn't even think of when they vibe-coded the protocol. And at least finally there was some adult in the room that said "perhaps you should actually use a standardised way to do this". You know, like all other APIs get OAuth (and other types) of authorisations.

[james_marks]

Perhaps confusingly, I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”).

The combination of these things turns into an ecosystem.

[mcpeepants]

MCP is a Protocol. The server and the clients are just that. It truly is a rebranding of “API” seemingly just because it’s for a specific purpose. Not that there’s anything wrong with that… call it whatever. But I don’t understand the need to sell it as something else entirely. It is quite literally a reinvention of RPC.

[troupo]

> I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”).

Why?

Do you refer to REST APIs or GraphQL as a whole? There are servers "adhering to the protocol" and "clients adding support" for these.

These are literally APIs.