5 ms·

HTTP was never an extraordinarily different protocol, there was really nothing to it from a technical perspective. What was important was it wrapped up a lot of

HTTP was never an extraordinarily different protocol, there was really nothing to it from a technical perspective. What was important was it wrapped up a lot of the concepts from the various hypertext and linking protocols that existed into a standard that was widely supported. The standard and the compatibility across servers and clients made it important. This is generally true for protocols across the board. In fact very few standards protocols are particularly revolutionary from a technical perspective. That’s in many ways very much not the point.

pyuser583 1y ago
The world would be a better place if Gopher had taken off instead.
- EGreg 1y ago
  How about Xanadu LOL The Web was freely available, while Gopher was licensed, making it less accessible and competitive As usual, open beats closed! TimBL actually is on video discussing how CERN didnt care to make money off the protocol, and it was lucky that they let it be freeee. https://youtu.be/GU6fWHHu6Es?si=gCgEQFyvwAZjKmZ9 https://youtu.be/GU6fWHHu6Es?si=gCgEQFyvwAZjKmZ9
_QrE 1y ago
I don't think that this is a fair comparison. HTTP actually has a specification that you need to follow if you need the web to _work_ (or at least, look good). MCP and others on the other hand are just you explaining to the LLM how you want it to format its responses. MCP is barely worth being called a protocol; LLMs are now smart enough to follow instructions however you give them. When I played around with creating my own tool-using agent, I specified the tools in YAML, and asked it to use custom tags to 'call' them. It worked just fine. More critically, there's nothing stopping the LLM from _not_ obeying whatever it is you give it, especially as the context fills up and/or the user trying to break it, except its own training. There is no proper HTTP server that would give you invalid responses 'just because'. Yeah, you could wrap the agent in a function that calls it again and again if the response isn't properly formatted with whatever formatting error happened, but I don't think any sane person would call that 'following the protocol', as the only entity it makes happy is whoever you're buying tokens from.
- namaria 1y ago
  It's all 'clever prompting' all the way down. 'Chain of thought', excuse me, 'reasoning', 'agents'. It's all just prompt scaffolding and language models. There is no way this ends the way the salespeople are saying it will. Indexing over a compressed space and doing search is not the future of computation.
- mindcrime 1y ago
  > MCP and others on the other hand are just you explaining to the LLM how you want it to format its responses. There's a little bit more to MCP than that. Arguably the most useful part of MCP is more on the (MCP) server side, in regards to discoverability of tools. Having a standard protocol for listing tools, resources and prompts means all you need is the endpoint where the server is located, and you can just get the tool list in a couple of lines of code, pass it to the LLM and then invoke the tool(s) without hand-rolling a bunch of code. This is probably more useful if you think in terms of using MCP tool servers written by other people. If you're only using your own stuff, then sure, you only write your own interface code once. But if you want to use tools provided by others, having a standard is handy (albeit certainly not required). I like the way @01100011 phrased it in his analogy with Junit: "I kept thinking it was stupid because in my mind it barely did anything. But then I got it: it did barely do anything, but it did things you'd commonly need to do for testing and it did them in a somewhat standardized way that kept you from having to roll your own every time.".
  - otabdeveloper4 1y ago
    We already had many standard ways to communicate API documentation before. MCP brings nothing new.
    - HumanOstrich 1y ago
      You should probably spend some time understanding what MCP and other protocols do before aggressively trashing the concept everywhere. I suggest reading at least the abstract of the linked paper. > MCP brings nothing new. https://github.com/modelcontextprotocol/servers https://github.com/modelcontextprotocol/servers

pyuser583 1y ago

The world would be a better place if Gopher had taken off instead.

EGreg 1y ago
How about Xanadu LOL The Web was freely available, while Gopher was licensed, making it less accessible and competitive As usual, open beats closed! TimBL actually is on video discussing how CERN didnt care to make money off the protocol, and it was lucky that they let it be freeee. https://youtu.be/GU6fWHHu6Es?si=gCgEQFyvwAZjKmZ9 https://youtu.be/GU6fWHHu6Es?si=gCgEQFyvwAZjKmZ9

_QrE 1y ago

I don't think that this is a fair comparison. HTTP actually has a specification that you need to follow if you need the web to _work_ (or at least, look good). MCP and others on the other hand are just you explaining to the LLM how you want it to format its responses. MCP is barely worth being called a protocol; LLMs are now smart enough to follow instructions however you give them. When I played around with creating my own tool-using agent, I specified the tools in YAML, and asked it to use custom tags to 'call' them. It worked just fine. More critically, there's nothing stopping the LLM from _not_ obeying whatever it is you give it, especially as the context fills up and/or the user trying to break it, except its own training. There is no proper HTTP server that would give you invalid responses 'just because'. Yeah, you could wrap the agent in a function that calls it again and again if the response isn't properly formatted with whatever formatting error happened, but I don't think any sane person would call that 'following the protocol', as the only entity it makes happy is whoever you're buying tokens from.

namaria 1y ago
It's all 'clever prompting' all the way down. 'Chain of thought', excuse me, 'reasoning', 'agents'. It's all just prompt scaffolding and language models. There is no way this ends the way the salespeople are saying it will. Indexing over a compressed space and doing search is not the future of computation.
mindcrime 1y ago
> MCP and others on the other hand are just you explaining to the LLM how you want it to format its responses. There's a little bit more to MCP than that. Arguably the most useful part of MCP is more on the (MCP) server side, in regards to discoverability of tools. Having a standard protocol for listing tools, resources and prompts means all you need is the endpoint where the server is located, and you can just get the tool list in a couple of lines of code, pass it to the LLM and then invoke the tool(s) without hand-rolling a bunch of code. This is probably more useful if you think in terms of using MCP tool servers written by other people. If you're only using your own stuff, then sure, you only write your own interface code once. But if you want to use tools provided by others, having a standard is handy (albeit certainly not required). I like the way @01100011 phrased it in his analogy with Junit: "I kept thinking it was stupid because in my mind it barely did anything. But then I got it: it did barely do anything, but it did things you'd commonly need to do for testing and it did them in a somewhat standardized way that kept you from having to roll your own every time.".
- otabdeveloper4 1y ago
  We already had many standard ways to communicate API documentation before. MCP brings nothing new.
  - HumanOstrich 1y ago
    You should probably spend some time understanding what MCP and other protocols do before aggressively trashing the concept everywhere. I suggest reading at least the abstract of the linked paper. > MCP brings nothing new. https://github.com/modelcontextprotocol/servers https://github.com/modelcontextprotocol/servers