3 ms·
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 hav
by 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 agoThis 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 agoThe 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 agoThat 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 agoThat 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://...").