[SillyUsername]

MCP is flawed but it learnt one thing correctly from years of RPC - complexity is the biggest time sink and holds back adoption in deference to simpler competing standards (cf XML vs JSON)

- SOAP - interop needs support of DOC or RPC based between systems, or a combination, XML and schemas are also horribly verbose.

- CORBA - libraries and framework were complex, modern languages at the time avoided them in deference to simpler standards (e.g. Java's Jini)

- GPRC - designed for speed, not readability, requires mappings.

It's telling that these days REST and JSON (via req/resp, webhooks, or even streaming) are the modern backbone of RPC. The above standards either are shoved aside or for GPRC only used where extreme throughput is needed.

Since REST and JSON are the plat du jour, MCP probably aligns with that design paradigm rather than the dated legacy protocols.

[w10-1]

> these days REST and JSON (via req/resp, webhooks, or even streaming) are the modern backbone of RPC

No, they're the medium of the web.

The author is specifically addressing enterprise integration into business workflows - not showing stuff in a browser.

[SillyUsername]

How is this browser specific or mentioned to be browser? The technologies can be purely "enterprise integration" of backend services. When was swagger (openapi) for example forbidden to be used for RPC? E.g. an endpoint that doesn't just support a crud op but take an event with an operation to execute?