This would be more complex to implement for a simple server, but it’s not exactly difficult.
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 :)
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.
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.
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.