Recently, we’ve heard smart people we respect say things like: “There's a lot of buzz around MCP. I'm not convinced it needs to exist.”

This discussion seems to resurface any time a company announces a product that uses or integrates with MCP, as OpenAI did earlier this week as part of their Apps SDK announcement.

While there have been many cogent arguments levied against MCP, we are strong believers in its necessity. Before we argue why, let’s lay out some of our assumptions so we’re all on the same page.

Human-computer interaction is changing

Humans interact with computers in 2025 differently than ever before. Instead of search and websites, we find ourselves engaged in one-on-one “chat” with ChatGPT, Claude, Gemini, etc.

We don’t think this is just because “chat” is an obvious interface for software that generates tokens. “Chat” is how humans communicate with other humans: we have conversations.

It’s thus pretty natural to believe that the best way for humans to interact with other forms of (artificial) intelligence is via “chat”. Maybe this is already obvious to you, maybe not; just as humans today interact with other (intelligent) humans via “chat”, so too will humans predominantly interact with AI through “chat” for the foreseeable future.

LLMs aren’t intelligent enough

Whether or not you believe LLMs really are intelligent, most agree that using them in isolation has proved insufficient for accomplishing many high-value tasks. Today’s LLMs require context and agency through external means to be truly useful. For example, to send a summary of a meeting requires access to the recording/notes (context), and the ability to send an email (agency).

This combination has proven more than “intelligent enough” to accomplish extremely useful things, such as writing code, through conversations.

And just like when chatting with someone intelligent, we expect our conversations to be tolerant of disruptions.

We experience this everyday in our human-to-human conversations: you're on the phone, the call drops, and you dial back. You don’t expect to begin your conversation all over again. Instead, you'd anticipate resuming from where you left off, or at least very close to it.

Enter the Model Context Protocol (MCP)

Let’s face it, the software providing the context and agency we need is not always going to live on the personal machines and devices where we’re engaged in “chat”. Building that software to be tolerant of disruptions is no easy feat. This is why most software and APIs we build today are designed to be stateless, as advocated and championed by the largest tech outfits and the most seasoned engineers.

But for AI, statefulness is a feature, not a bug, that enables intelligent interactions between humans and computers. Without it, it’ll always feel like talking to, well, a computer.

More so than schemas and a clean separation of prompts, resources, and tools, this is what excites us the most about MCP. This is where we see MCP as a necessary prerequisite for enabling intelligent conversations between humans and computers.

Combining the aspects of MCP that enable tolerance of disruptions with features that have remained relatively obscure like elicitation (which enables the MCP server to ask questions or elicit feedback from humans), and sampling (which enables the MCP server to invoke the LLM itself), MCP is the best option we have today for creating agents we can universally chat with from multiple interfaces, including ChatGPT, Claude, Gemini, VS Code’s CoPilot, etc.

And that universality is important! The fact that MCP has a real chance of becoming a true open standard is vital as it will (1) promote interoperability, allowing different systems and products to work together, (2) accelerate innovation, allowing clients and servers to evolve independently, and (3) reduce vendor lock-in, which is all in all a better outcome for us as end users.

JSON-RPC vs gRPC vs REST?

It’s not MCP vs JSON-RPC vs gRPC vs REST vs …

MCP is built on top of JSON-RPC, and it just as well could have been built on top of gRPC or REST (in fact, there is an open Specification Enhancement Protocol SEP-1597 to do just that). What’s important is the higher-level API that’s part of the MCP specification that enables intelligent communication even in the face of disruptions.

What about just having the LLM use a CLI or call APIs directly? Recently, Cloudflare proposed an alternative to MCP along this line of thinking they called Code Mode which yielded interesting results! For existing, stateless, APIs, this might be a completely viable approach. But for building the kind of agents we want to build, this isn’t enough: we need MCP, or something like it, to account for the statefulness inherent in a conversation. Our MCP servers are not merely adding two numbers together, they’re booking entire vacations, and after we’ve started we don’t want a computer reboot to leave us with a flight but no hotel.

Early days

It’s still early days for this part of MCP. Even though the 2025-03-26 specification version included support for Resumability and Redelivery, empirically it appears that most clients and servers don’t take advantage of it yet.

Those that do, such as VS Code’s Copilot, have a widely different interpretation of the specification than we did, and while we were able to get it to work with our durable-mcp framework, it definitely felt like a hack (we plan to discuss that in more detail in a future blog post).

Thanks to recent announcements like OpenAI’s Apps SDK, however, we expect more and more MCP servers will get built and more and more of them will benefit from taking advantage of the inherent statefulness in the specification to provide intelligent interactions between humans and computers.

This is an exciting time to be a distributed systems nerd! MCP provides a unique opportunity for the industry to standardize on a stateful protocol for the web, ushering in an era of applications that have been difficult to implement in the past. We’re pumped!

Stay tuned for more posts on the intersection of MCP and distributed systems! In upcoming posts we’ll dive into more details about our durable-mcp framework and how it enables building intelligent MCP based agents!

Thanks to Jörg Schad and Chris Riccomini for feedback on this post!