4 ms·

> MCP thinks it's for giving context to AI models. But really? It's just a really good protocol for making things talk to other things. MCP has very little uti

by 827a 1y ago

> MCP thinks it's for giving context to AI models. But really? It's just a really good protocol for making things talk to other things. MCP has very little utility outside of LLMs. The article begins by saying "but what if we remove the AI", then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system". Which is true, but its missing the critical bit: The AI itself is the universal plugin system, not MCP. And, beyond that, its not even the AI: Its natural language. Language is the universal plugin system. Its not unbelievable that there exists an alternate reality where the Anthropic researchers that invented MCP instead simply leveraged a slightly extended form of OpenAPI specs. The only functional difference is that MCP was a stdin/stdout format first, and added HTTPS later, but sister problems in this domain like LSP just skipped stdin/stdout and went straight to locally-hosted HTTPS anyway. What matters isn't MCP, OpenAPI, or anything like that; what matters is the LLM itself, its tool calling capability, and the tool calling harness. The catalogue of available tools can be in any format; and, truly, the LLM does not care what format its in.

ethan_smith 1y ago
MCP's key innovation isn't the format but its unidirectional, stateless design pattern that makes it fundamentally easier to implement than bidirectional protocols like OpenAPI, which is why it's gaining traction as a universal connector beyond just LLM contexts.
- 827a 1y ago
  I really don't know where you're coming from with that statement. 1. No one asserted that MCP's key innovation was its format. In fact, what I strongly, almost explicitly implied with my previous comment is that MCP has made no key innovations beyond its marketing system (which does matter and has forced a lot of companies who would never have operated in this space to make an MCP system, and that is good. I like MCP.). 2. MCP is fundamentally bidirectional, not unidirectional. Its a schematized request-response protocol that defines a ton of the same primitives that OpenAPI defines, like available RPC methods, authorization, request parameters, and response schemas [1]. Of course, OpenAPI goes beyond that into HTTP-specific characteristics like status codes, and MCP goes beyond that into LLM-specific characteristics like a prompt catalogue. 3. I'm not aware of any problem domain outside of LLMs that is adopting MCP. In fact, its adoption even within the world of LLMs has been lackluster at best [2]. [1] https://modelcontextprotocol.io/docs/learn/architecture#data-layer-2 https://modelcontextprotocol.io/docs/learn/architecture#data... [2] https://modelcontextprotocol.io/clients https://modelcontextprotocol.io/clients
radixdiaboli 1y ago
> but if there was an AI between these things, then it becomes a universal plugin system I've reread the article a couple times and I can't see where it says that you need to use an LLM to make it universal. I'm going to go so far as to say that it doesn't say that.
- 827a 1y ago
  I agree, the article does explicitly say that; the thesis of the article and the information it presents to support that thesis are entirely at odds. That's what I'd argue this is a poor article, just an advertisement for the world's eighty-sixth todo app; yet it keeps getting re-posted here.
  - radixdiaboli 1y ago
    I honestly feel like we're not even reading the same article. His contention is that MCP, while created for AI, can serve as a universal plugin system. He's writing software that... does that. Not seeing the contradiction.
moduspol 1y ago
And even then: the key value of MCP is that it's "simplified." Few servers are implementing anything you couldn't already do for years with their REST APIs. And why? Because it dumbs it down to the point that the LLM can understand it (often, in part, by removing security concerns). But these are LLMs! They're supposed to be smart! Isn't it a supposedly temporary failure that I can't just point the LLM at an OpenAPI spec (or use HATEOAS) and be good to go? Will this be doable in the next few months with better models? If so, why bother with MCP? If this won't be doable in the next few months / years, then how smart do we really expect these LLMs to be?
- 827a 1y ago
  I think that's an extreme characterization. Existing AIs are intelligent enough to be able to form immediately executable API requests based on the content of an OpenAPI schema. OpenAPI defines everything they need; endpoint names, human descriptions, arguments, authorization, etc. With proper prompting and a well designed harness, which MCP also needs, it would have solved the problem. Conversely: MCP doesn't really have much over OpenAPI in the domain of helping LLMs identify which tools to call; it has tool names, tool descriptions, input parameters, and that's basically it. OpenAPI has all that. The reason why MCP was invented is hard to reverse-engineer, but from what I've seen I suspect its mostly: it was stdio/stdout first, and there isn't really a great standard like OpenAPI in the local-first stdio/stdout world. Interesting, LSP (Microsoft) took the opposite approach; despite having far less reason to be hosted on the web, LSP is just localhost http calls. MCP could have done that, but they didn't, without good reason, which leads me to the second reason why I suspect it was invented: they didn't know, and thus couldn't learn from prior art that they didn't know. Most of these AI labs are not rigorous engineering shops, they're better characterized as: a bunch of kids with infinite money trying to reignite the spirit of the early internet startup boom. Many believe that what they're building will replace everything, so why even try to build on what already exists? But why it was invented doesn't matter, because anyone can invent anything. The reason why MCP has gotten popular is because its AI. That's it. Its a marketing and SEO system that enables companies who are otherwise struggling to find a way to prioritize AI use-cases for their apps to say "look, we're AI now". You don't get the same market impact if all you need is that boring old OpenAPI schema you already have. And again: I like MCP. What I stated sounds pessimistic, but its only intended to be realistic. There is almost zero technical reason for MCP to exist beyond that.
dragonwriter 1y ago
> then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system". This is neither an accurate quote of the article, nor an accurate paraphrase of something the article says, nor an accurate description of something subtly implied by the article without directly being said. The article, in fact, gives an example without AI in the middle.

by 827a 1y ago

ethan_smith 1y ago

MCP's key innovation isn't the format but its unidirectional, stateless design pattern that makes it fundamentally easier to implement than bidirectional protocols like OpenAPI, which is why it's gaining traction as a universal connector beyond just LLM contexts.

827a 1y ago
I really don't know where you're coming from with that statement. 1. No one asserted that MCP's key innovation was its format. In fact, what I strongly, almost explicitly implied with my previous comment is that MCP has made no key innovations beyond its marketing system (which does matter and has forced a lot of companies who would never have operated in this space to make an MCP system, and that is good. I like MCP.). 2. MCP is fundamentally bidirectional, not unidirectional. Its a schematized request-response protocol that defines a ton of the same primitives that OpenAPI defines, like available RPC methods, authorization, request parameters, and response schemas [1]. Of course, OpenAPI goes beyond that into HTTP-specific characteristics like status codes, and MCP goes beyond that into LLM-specific characteristics like a prompt catalogue. 3. I'm not aware of any problem domain outside of LLMs that is adopting MCP. In fact, its adoption even within the world of LLMs has been lackluster at best [2]. [1] https://modelcontextprotocol.io/docs/learn/architecture#data-layer-2 https://modelcontextprotocol.io/docs/learn/architecture#data... [2] https://modelcontextprotocol.io/clients https://modelcontextprotocol.io/clients

radixdiaboli 1y ago

> but if there was an AI between these things, then it becomes a universal plugin system I've reread the article a couple times and I can't see where it says that you need to use an LLM to make it universal. I'm going to go so far as to say that it doesn't say that.

827a 1y ago
I agree, the article does explicitly say that; the thesis of the article and the information it presents to support that thesis are entirely at odds. That's what I'd argue this is a poor article, just an advertisement for the world's eighty-sixth todo app; yet it keeps getting re-posted here.
- radixdiaboli 1y ago
  I honestly feel like we're not even reading the same article. His contention is that MCP, while created for AI, can serve as a universal plugin system. He's writing software that... does that. Not seeing the contradiction.

moduspol 1y ago

And even then: the key value of MCP is that it's "simplified." Few servers are implementing anything you couldn't already do for years with their REST APIs. And why? Because it dumbs it down to the point that the LLM can understand it (often, in part, by removing security concerns). But these are LLMs! They're supposed to be smart! Isn't it a supposedly temporary failure that I can't just point the LLM at an OpenAPI spec (or use HATEOAS) and be good to go? Will this be doable in the next few months with better models? If so, why bother with MCP? If this won't be doable in the next few months / years, then how smart do we really expect these LLMs to be?

827a 1y ago
I think that's an extreme characterization. Existing AIs are intelligent enough to be able to form immediately executable API requests based on the content of an OpenAPI schema. OpenAPI defines everything they need; endpoint names, human descriptions, arguments, authorization, etc. With proper prompting and a well designed harness, which MCP also needs, it would have solved the problem. Conversely: MCP doesn't really have much over OpenAPI in the domain of helping LLMs identify which tools to call; it has tool names, tool descriptions, input parameters, and that's basically it. OpenAPI has all that. The reason why MCP was invented is hard to reverse-engineer, but from what I've seen I suspect its mostly: it was stdio/stdout first, and there isn't really a great standard like OpenAPI in the local-first stdio/stdout world. Interesting, LSP (Microsoft) took the opposite approach; despite having far less reason to be hosted on the web, LSP is just localhost http calls. MCP could have done that, but they didn't, without good reason, which leads me to the second reason why I suspect it was invented: they didn't know, and thus couldn't learn from prior art that they didn't know. Most of these AI labs are not rigorous engineering shops, they're better characterized as: a bunch of kids with infinite money trying to reignite the spirit of the early internet startup boom. Many believe that what they're building will replace everything, so why even try to build on what already exists? But why it was invented doesn't matter, because anyone can invent anything. The reason why MCP has gotten popular is because its AI. That's it. Its a marketing and SEO system that enables companies who are otherwise struggling to find a way to prioritize AI use-cases for their apps to say "look, we're AI now". You don't get the same market impact if all you need is that boring old OpenAPI schema you already have. And again: I like MCP. What I stated sounds pessimistic, but its only intended to be realistic. There is almost zero technical reason for MCP to exist beyond that.

dragonwriter 1y ago

> then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system". This is neither an accurate quote of the article, nor an accurate paraphrase of something the article says, nor an accurate description of something subtly implied by the article without directly being said. The article, in fact, gives an example without AI in the middle.