Model Context Protocol

An open standard that defines how AI applications connect to external tools, data, and prompt templates through one uniform client-server protocol, so any compliant client can use any compliant server without integration code written for that specific pairing.

How it works

The protocol fixes a client-server shape. A host application runs one or more clients, each connects to a server, and the two exchange structured messages in one defined format to negotiate capabilities and then call them. A server advertises three core kinds of primitive: tools the model can invoke, resources it can read, and prompt templates it can reuse, while the client can expose its own capabilities in turn; the client discovers what a server offers at runtime rather than being compiled against it. Because the message format and the primitive types are fixed by the standard, any client that speaks the protocol can reach any server that speaks it, and the integration to a particular system lives behind the server's advertised primitives rather than inside the client.

Why it matters

Standardizing the connection turns a matrix of bespoke point-to-point integrations into a set of servers any compliant client can reach. The constraint is also the limit: the protocol covers what its primitives can express, and a capability that does not fit the tool, resource, or prompt shapes falls outside the standard, so interoperability holds inside the defined vocabulary and not past it. A second cost is version skew, because a standard evolves through revisions and a client and server targeting different revisions can agree on the protocol in name while differing in what each actually supports.

In practice

A host application runs one client per server: one client connected to a database server, one to a file store, one to a search index. Each server advertises its own tools and resources, and the host reaches all three through the same protocol rather than carrying three hand-written integrations. Swap the database server for a different implementation whose tools match in name, shape, and behavior and its client keeps working, because the client bound to the protocol contract and not to that particular server.

Practical considerations

The standard is versioned by dated revisions, and its governance publishes a current revision that clients and servers target; treating any one revision as permanent is a mistake, because a later revision can change required behavior at the protocol layer. Capability negotiation happens at connection time, so a robust client checks what a server actually advertises rather than assuming a primitive is present because the standard defines it. The standard specifies its transports and an optional authorization layer separately from the message and primitive layers, which is why two compliant servers can still differ sharply in how they authenticate and where they run while interoperating at the protocol level.

Defined by Ready Solutions AI