3 ms·

It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different port

It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.

ihuman 2mo ago
Is stdio being deprecated? I couldn't tell from this page
- amluto 2mo ago
  The prose on the page is very unclear. My best interpretation is that they want to continue supporting stdio but that they don’t want it to be its own special protocol. The obvious way to do that would be to speak ordinary HTTP (version 1.1? 2?) over stdio and to use the MCP-over-HTTP protocol over the resulting HTTP transport. This would be more complex to implement for a simple server, but it’s not exactly difficult.
  - Gormo 2mo ago
    Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.
    - intrasight 2mo ago
      Count me as not on board
    - pstuart 2mo ago
      Would you prefer gRPC, thrift, avro, etc... ?
      - amluto 2mo ago
        Those are mostly at a different layer. You can speak Thrift or Avro or Protobuf over stdio or HTTP or TCP or carrier pigeon. gRPC spans layers, and it uses HTTP in a more intrusive way than even MCP does — it expects to own the entire URL space at the IP/port in question. Using gRPC in a nontrivial way for MCP would be fairly heavy-weight: you would probably need to set up reflection and figure out how to bind all the MCP calls to it unless you just use it as a tunnel.
        arccy 2mo ago
        grpc mcp is a thing... https://cloud.google.com/blog/products/networking/grpc-as-a-native-transport-for-mcp https://cloud.google.com/blog/products/networking/grpc-as-a-...
        amluto 2mo ago
        Wow, that looks like a huge mess.
      - jcmfernandes 2mo ago
        I would prefer a core transport agnostic protocol, and then see MCP-over-HTTP being a spec on top of that.
      - jauntywundrkind 2mo ago
        I'm pretty ok with http, but, I'd throw https://varlink.org https://varlink.org in as my second pick.
    - amluto 2mo ago
      I’m not really a fan. But if you’re building a protocol that needs to map to HTTP anyway, then maybe using the HTTP binding everywhere is not totally awful. In the flip side: I’m currently designing an AI-adjacent protocol, and it will be able to map to WebTransport, but I don’t plan to define non-WebTransport HTTP bindings unless a very compelling reason appears. The main implementations will not use HTTP at all :)
      - ranger_danger 2mo ago
        > if you’re building a protocol that needs to map to HTTP anyway I don't think there is any guarantee that HTTP will always be involved. For example I might be calling a local LLM via CLI/script on a server with a stdio MCP connector that just runs other CLI commands, and never sends any HTTP traffic.
        amluto 2mo ago
        Right. But there is a lot of real-world usage of MCP-over-HTTP-over-the-Internet, and a lot of “harnesses” want to support that use case, so they’re stuck either implementing the HTTP-based protocol or using a shim.
    - oblio 2mo ago
      What's the disadvantage? MCP doesn't strike me as a high performance protocol.
    - cryptonector 2mo ago
      Pros for HTTP for IPC: 1. We already use it plenty, so we have lots of implementations, 2. it's good enough. Cons: a. what shall be the form of HTTP IPC URIs? hostnames for http: and https: scheme URIs are kinda out of place in IPC applications (we need something like sys.ipc.arpa, d-bus.arpa, etc), b. the overhead of HTTP is annoying -- any decent RPC can be significantly more efficient, unless one uses HTTP/2, and maybe even then. (a) makes me want to write and submit an I-D for HTTP over IPC by using such names as in the parenthetical above. (b) is a non-issue once H2 is widely adopted. So IMO HTTP is pretty good for IPC.
nprateem 2mo ago
The real disaster was making it stateful. Need to get some adults in the room.
- nostrebored 2mo ago
  Your stateful remote execution needs a stateful tool middleware for your stateful agent, just to make sure that it’s impossible to test or evaluate
- otabdeveloper4 2mo ago
  Don't worry about it, the very best Claude tokens designed, implemented and tested it. What are you, some sort of luddite?
tarun_anand 2mo ago
Wrote about this last year and wanted to unify it... at that time the community was so excited about MCP being the best thing since sliced bread https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1145 https://github.com/modelcontextprotocol/modelcontextprotocol... https://news.ycombinator.com/item?id=43959474 https://news.ycombinator.com/item?id=43959474

It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.

ihuman 2mo ago

Is stdio being deprecated? I couldn't tell from this page

amluto 2mo ago
The prose on the page is very unclear. My best interpretation is that they want to continue supporting stdio but that they don’t want it to be its own special protocol. The obvious way to do that would be to speak ordinary HTTP (version 1.1? 2?) over stdio and to use the MCP-over-HTTP protocol over the resulting HTTP transport. This would be more complex to implement for a simple server, but it’s not exactly difficult.
- Gormo 2mo ago
  Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.
  - intrasight 2mo ago
    Count me as not on board
  - pstuart 2mo ago
    Would you prefer gRPC, thrift, avro, etc... ?
    - amluto 2mo ago
      Those are mostly at a different layer. You can speak Thrift or Avro or Protobuf over stdio or HTTP or TCP or carrier pigeon. gRPC spans layers, and it uses HTTP in a more intrusive way than even MCP does — it expects to own the entire URL space at the IP/port in question. Using gRPC in a nontrivial way for MCP would be fairly heavy-weight: you would probably need to set up reflection and figure out how to bind all the MCP calls to it unless you just use it as a tunnel.
      - arccy 2mo ago
        grpc mcp is a thing... https://cloud.google.com/blog/products/networking/grpc-as-a-native-transport-for-mcp https://cloud.google.com/blog/products/networking/grpc-as-a-...
        amluto 2mo ago
        Wow, that looks like a huge mess.
    - jcmfernandes 2mo ago
      I would prefer a core transport agnostic protocol, and then see MCP-over-HTTP being a spec on top of that.
    - jauntywundrkind 2mo ago
      I'm pretty ok with http, but, I'd throw https://varlink.org https://varlink.org in as my second pick.
  - amluto 2mo ago
    I’m not really a fan. But if you’re building a protocol that needs to map to HTTP anyway, then maybe using the HTTP binding everywhere is not totally awful. In the flip side: I’m currently designing an AI-adjacent protocol, and it will be able to map to WebTransport, but I don’t plan to define non-WebTransport HTTP bindings unless a very compelling reason appears. The main implementations will not use HTTP at all :)
    - ranger_danger 2mo ago
      > if you’re building a protocol that needs to map to HTTP anyway I don't think there is any guarantee that HTTP will always be involved. For example I might be calling a local LLM via CLI/script on a server with a stdio MCP connector that just runs other CLI commands, and never sends any HTTP traffic.
      - amluto 2mo ago
        Right. But there is a lot of real-world usage of MCP-over-HTTP-over-the-Internet, and a lot of “harnesses” want to support that use case, so they’re stuck either implementing the HTTP-based protocol or using a shim.
  - oblio 2mo ago
    What's the disadvantage? MCP doesn't strike me as a high performance protocol.
  - cryptonector 2mo ago
    Pros for HTTP for IPC: 1. We already use it plenty, so we have lots of implementations, 2. it's good enough. Cons: a. what shall be the form of HTTP IPC URIs? hostnames for http: and https: scheme URIs are kinda out of place in IPC applications (we need something like sys.ipc.arpa, d-bus.arpa, etc), b. the overhead of HTTP is annoying -- any decent RPC can be significantly more efficient, unless one uses HTTP/2, and maybe even then. (a) makes me want to write and submit an I-D for HTTP over IPC by using such names as in the parenthetical above. (b) is a non-issue once H2 is widely adopted. So IMO HTTP is pretty good for IPC.

nprateem 2mo ago

The real disaster was making it stateful. Need to get some adults in the room.

nostrebored 2mo ago
Your stateful remote execution needs a stateful tool middleware for your stateful agent, just to make sure that it’s impossible to test or evaluate
otabdeveloper4 2mo ago
Don't worry about it, the very best Claude tokens designed, implemented and tested it. What are you, some sort of luddite?

tarun_anand 2mo ago

Wrote about this last year and wanted to unify it... at that time the community was so excited about MCP being the best thing since sliced bread https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1145 https://github.com/modelcontextprotocol/modelcontextprotocol... https://news.ycombinator.com/item?id=43959474 https://news.ycombinator.com/item?id=43959474