3 ms·

It's a vibe-coded protocol that lets LLM models query external tools. You write a wrapper ("MCP server") over your docs/apis/databases/sites/scripts that expos

by troupo 1y ago

It's a vibe-coded protocol that lets LLM models query external tools. You write a wrapper ("MCP server") over your docs/apis/databases/sites/scripts that exposes certain commands ("tools"), and you can instruct models to query your wrapper with these commands ("calling/invoking tools") and expect responses in a certain format that they can then use. That is it. Why vibe-coded? Because instead of bi-directional websockets the protocol uses unidirectional server-side events, so you need to send requests to a separate endpoint and then listen to the SSE hoping for an answer. There's also non-existent authentication.

nylonstrung 1y ago
I see zero reason they couldn't have used standard websockets and made it simpler and more robust. Awful case of "not invented here" syndrome I'm personally interested in if WebTransport could be the basis for something better
lsaferite 1y ago
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.
- tough 1y ago
  more than vibe coded it feels vibe concieved but that doesnt have to be necessarily negative
- troupo 1y ago
  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. Even reading through explanations on the once again vibe-coded https://modelcontextprotocol.io/ https://modelcontextprotocol.io/ you can't help to wonder why. "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 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. [1] The auth spec is here: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization https://modelcontextprotocol.io/specification/2025-03-26/bas... I don't think anything on the site links to this directly. I found the link from some github discussion. See issues with it here: https://blog.christianposta.com/the-updated-mcp-oauth-spec-is-a-mess/ https://blog.christianposta.com/the-updated-mcp-oauth-spec-i...
  - lsaferite 1y ago
    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.

by troupo 1y ago

nylonstrung 1y ago

I see zero reason they couldn't have used standard websockets and made it simpler and more robust. Awful case of "not invented here" syndrome I'm personally interested in if WebTransport could be the basis for something better

lsaferite 1y ago

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.

tough 1y ago
more than vibe coded it feels vibe concieved but that doesnt have to be necessarily negative
troupo 1y ago
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. Even reading through explanations on the once again vibe-coded https://modelcontextprotocol.io/ https://modelcontextprotocol.io/ you can't help to wonder why. "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 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. [1] The auth spec is here: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization https://modelcontextprotocol.io/specification/2025-03-26/bas... I don't think anything on the site links to this directly. I found the link from some github discussion. See issues with it here: https://blog.christianposta.com/the-updated-mcp-oauth-spec-is-a-mess/ https://blog.christianposta.com/the-updated-mcp-oauth-spec-i...
- lsaferite 1y ago
  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.