4 ms·

To be fair, HTTP adds a layer of friendliness over TCP (POST/GET, paths, query parameters) and the servers can be so simple that it can hardly be considered irr

To be fair, HTTP adds a layer of friendliness over TCP (POST/GET, paths, query parameters) and the servers can be so simple that it can hardly be considered irrelevant baggage. The benefit it brings is that you can add debugging endpoints which you can use directly in a browser, you get networking with hosts and ports instead of local-only exe + stdio.

skeledrew 2y ago
That's just one part of it. Keep in mind MCP supports 3 transport methods: stdio, SSE (which would be your HTTP) and websockets. Irrelevant baggage would be having to consider the workings of any of those (given a decently implemented client+server library), rather than merely declaring the servers, tools, resources and prompts to be accessed. There's also a debug mode I believe.
- Xelynega 2y ago
  This just furthers my theory that people pushing for MCP don't understand how networking and protocols work. stdio is a file that your computer can write to and read from HTTP is a protocol typically used over TCP websockets is a protocol initiated via HTTP, which again is typically over TCP Both HTTP and websockets can be done over stdio instead of TCP. It sounds like MCP has a lot more "irrelevant baggage" I need to learn/consider.
  - skeledrew 2y ago
    The entire point can be summed in the first 5/6s of that. You don't need to know any of it, because it's irrelevant (at that abstraction). Just as it's irrelevant to know how registers work, to allocate and free memory, avoid/handle segfaults, etc if using a high level language like Python, vs Assembly or C.
    - Xelynega 2y ago
      That doesn't sound like the case for MCP though. It sounds like when implementing an MCP server there is a difference between the three transport methods that requires different code on the server. This is a problem solved by other protocols that are just stacked on top of eachother without knowing how eachother work.
      - skeledrew 2y ago
        That depends on the library implementation. A given library can be anywhere on the spectrum from "user knowledge and management of the transport methods required" to "transport method is determined by protocol format or invocation" (eg. "local://..." vs "remote://...").

skeledrew 2y ago

That's just one part of it. Keep in mind MCP supports 3 transport methods: stdio, SSE (which would be your HTTP) and websockets. Irrelevant baggage would be having to consider the workings of any of those (given a decently implemented client+server library), rather than merely declaring the servers, tools, resources and prompts to be accessed. There's also a debug mode I believe.

Xelynega 2y ago
This just furthers my theory that people pushing for MCP don't understand how networking and protocols work. stdio is a file that your computer can write to and read from HTTP is a protocol typically used over TCP websockets is a protocol initiated via HTTP, which again is typically over TCP Both HTTP and websockets can be done over stdio instead of TCP. It sounds like MCP has a lot more "irrelevant baggage" I need to learn/consider.
- skeledrew 2y ago
  The entire point can be summed in the first 5/6s of that. You don't need to know any of it, because it's irrelevant (at that abstraction). Just as it's irrelevant to know how registers work, to allocate and free memory, avoid/handle segfaults, etc if using a high level language like Python, vs Assembly or C.
  - Xelynega 2y ago
    That doesn't sound like the case for MCP though. It sounds like when implementing an MCP server there is a difference between the three transport methods that requires different code on the server. This is a problem solved by other protocols that are just stacked on top of eachother without knowing how eachother work.
    - skeledrew 2y ago
      That depends on the library implementation. A given library can be anywhere on the spectrum from "user knowledge and management of the transport methods required" to "transport method is determined by protocol format or invocation" (eg. "local://..." vs "remote://...").