You are complaining about the transport aspect of the specification.
The protocol could easily be transported over websockets. Heck, since stdio is one transport, you could simply pipe that over websockets. Of course, that leaves a massive gap around authn and authz.
The Streamable HTTP transport includes an authentication workflow using OAuth. Of course, that only addresses part of the issue.
There are many flaws that need improvement in MCP, but railing against the current transports by using a presumably denigratory term ("vibe-coded") isn't helpful.
Your "that is it" stops at talking about one single aspect of the protocol. On the server side you left out resources and prompts. On the client side you left out sampling, which I find to be a very interesting possibility.
I think MCP has many warts that need addressing. I also think it's a good start on a way to standardize connections between tools and agents.
The choice of transport is just one, quite telling, aspect of this mess.
Could these commands be executed over websockets? Yes, they could. Will they? No, because the specification literally only defines two transports, and all of the clients only support those.
As with any hype, the authors drink their own coolaid, invent their own terminology, and ignore literally everything that came before them.
"tools" are nothing but RPC calls (that's why the base of this is JSON RPC)
"resources"? PHP could do an fopen on remote URLs in the 90s. It literally is just that: "Each resource is identified by a unique URI and can contain either text or binary data." You don't say.
"sampling"? It literally is just bi-directional communication. "servers request data from the client by sending commands". What a novel idea, must have a new name and marketing blurb about "powerful MCP feature, enabling sophisticated agentic behaviors while maintaining security and privacy."
As for auth, again, MCP doesn't have it, and expects you to just figure it out yourself. The entirety of the "spec" on it is just "MCP provides an Authorization framework for use with HTTP and your expected to conform to this spec". There's no spec. Edit: to be clear. At the point of writing all mentions of "MCP Auth Spec" on the internet link to https://modelcontextprotocol.io/specification/2025-03-26 which at the time of writing contains zero mentions of OAuth and says nothing about auth (and is not a spec to begin with) [1]
And so on.
It's hype-driven vibe-coded development at its finest.
Maybe calmly look at the spec and notice that the site does actually have a clear navigation to authorization (2025-03-26 > Base Protocol > Authorization).
You clearly have no desire to objectively evaluate what the specification is trying to do and are simply disregarding all aspects of the specification as trite or pointless. As such, this will be my last response of the subject.
I encourage you to take a breath and maybe try to understand why the specification was created in the first place before dismissing it fully.
> Maybe calmly look at the spec and notice that the site does actually have a clear navigation to authorization (2025-03-26 > Base Protocol > Authorization).
Not on mobile. At least I couldn't see any obvious link to a very important part of the spec. There are circular links everywhere, none to auth.
> You clearly have no desire to objectively evaluate what the specification is trying to
I'm not questioning what it is trying to do. I'm questioning how it's doing that.
> try to understand why the specification was created in the first place before dismissing it fully.
I'm not questioning why it is trying to do. I'm questioning how it's doing that.
Stop buying into hype and marketing wholesale, and actually read what it is, and actually understand what your opponents are talking about.
The protocol could easily be transported over websockets. Heck, since stdio is one transport, you could simply pipe that over websockets. Of course, that leaves a massive gap around authn and authz.
The Streamable HTTP transport includes an authentication workflow using OAuth. Of course, that only addresses part of the issue.
There are many flaws that need improvement in MCP, but railing against the current transports by using a presumably denigratory term ("vibe-coded") isn't helpful.
Your "that is it" stops at talking about one single aspect of the protocol. On the server side you left out resources and prompts. On the client side you left out sampling, which I find to be a very interesting possibility.
I think MCP has many warts that need addressing. I also think it's a good start on a way to standardize connections between tools and agents.