MCP: Same Shit, Different Day

  2. 5-minute read

AI agents are infinitely more useful if they can connect to external systems. In November 2024, Anthropic announced the open-sourcing of the Model Context Protocol. In the MCP architecture, a server describes at runtime how it can be useful and how it can be used. Any MCP-capable agent can connect to any MCP server without a bespoke integration; a shared understanding of the protocol suffices.

Contrast that with the usual approach to client-server integration today. We design clients around a particular API contract, often presented as an OpenAPI Description published to a developer portal or somewhere similar1. Supporting an additional API generally means another integration – the hurdle MCP sought to eliminate2.

Such APIs are often advertised as REST or RESTful, a label that nowadays refers to a resource-oriented architectural style with CRUD operations. I have enough unc status to remember when that label stood for a paradigm far more radical.

illustration of a creature wearing a trench coat and hat, holding a contract

The principles of REST have guided the IETF and the W3C in web standards development since the nineties, and they were formalised in Roy Fielding's doctoral dissertation3 in 2000. In § 5.3.3, he writes:

REST concentrates all of the control state into the representations received in response to interactions. […] The model application is […] an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.

The dissertation is not lightweight reading. If you find the academic prose tough to parse, you are in good company.

Essentially, Fielding describes a client that learns how to interact with a server by interacting with that server. This concept is sometimes referred to as HATEOAS.

HATEOAS has proven incredibly powerful on the web. Imagine for a second a world in which the websites of your bank, your favourite streaming service, and your go-to webshop each have their own OpenAPI Description, and Google has to add support for every individual website to Chrome, and Mozilla to Firefox. Instead, the web merely relies on a shared understanding of HTML and JavaScript (the "media types"). "Representations" – through <a /> and <form /> tags in HTML documents and fetch calls in JS files4 – teach the client (the browser) how to further interact with the server. A browser supports every website, and no website in particular.

When we saw the sheer power of learning how to interact by interacting, we were determined to bring the concept to the programmable web. That ambition spawned a family of media types, most famously Collection+JSON, HAL, Siren, and Hydra. But defining the media types is the easy part. Browsers offload some decision-making to the user. Without a human in the loop, designing a client that can learn at runtime is like teaching a robot to assemble any piece of furniture from instructions. It's much simpler if you know in advance the exact desk it will build.

The dream of a client that could spontaneously interact with any server proved too technically challenging to be practical. We quietly settled for out-of-band API contracts – while keeping the REST label (despite Fielding's plea to "choose some other buzzword"5). We fossilised this decision by embracing automated client code generation from these contracts.

Then came LLMs. A robot interpreting an IKEA manual is much more realistic with AI assistance, and so is an unattended client learning how to interact with a server by interacting with that server. A browser interprets server-provided interaction logic and largely relies on the user to decide how to proceed; an MCP-capable agent similarly interprets server-provided interaction logic and defers the decisions to the model. MCP takes our dream of spontaneous interaction beyond the browser.

So MCP is innovative, but also just a mix of known ingredients. Like most cool things in the roaring twenties, it's made of things that were cool in the nineties.

  1. An OpenAPI Description can be provided in-band. The OpenAPI Initiative's "Best Practices" page reads: "The documents that make up the [OpenAPI Description] can even be made available through the same API to allow runtime discovery." In practice, it is the canonical example of an out-of-band API contract, and the text uses it as such.
  2. The 2024 announcement titled "Introducing the Model Context Protocol" reads: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale. MCP addresses this challenge. It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol."
  3. Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures [Doctoral dissertation, University of California, Irvine]. ics.uci.edu/~fielding/pubs/dissertation/top.htm
  4. A critical reader may argue that a fetch call need not be hypermedia-driven. Regardless, it is an example of server-provided, in-band interaction logic.
  5. In a 2008 article titled "REST APIs must be hypertext-driven", Roy Fielding writes: "[…] the above are the rules related to the hypertext constraint that are most often violated within so-called REST APIs. Please try to adhere to them or choose some other buzzword for your API."