4 ms·

> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload Good. Introducing a bespoke new protocol was one of the mor

• Jhater 1mo ago
  [dead]
• colingauvin 1mo ago
  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 1mo ago
    Is stdio being deprecated? I couldn't tell from this page
    • amluto 1mo 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 1mo ago
        Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.
        • intrasight 1mo ago
          Count me as not on board
        • pstuart 1mo ago
          Would you prefer gRPC, thrift, avro, etc... ?
          • amluto 1mo 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 1mo 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 1mo ago
                Wow, that looks like a huge mess.
          • jcmfernandes 1mo ago
            I would prefer a core transport agnostic protocol, and then see MCP-over-HTTP being a spec on top of that.
          • jauntywundrkind 1mo ago
            I'm pretty ok with http, but, I'd throw https://varlink.org https://varlink.org in as my second pick.
        • 1mo ago
  • nprateem 1mo ago
    The real disaster was making it stateful. Need to get some adults in the room.
    • nostrebored 1mo 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 1mo 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 1mo 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
• activeing123 26d ago
  [flagged]