↓Skip to main content

The model context protocol

·4 mins
Artificial Intelligence (AI) Large Language Models (LLMs)
Table of Contents

In the AI world, there’s been a lot of buzz around the Model Context Protocol (MCP). Lots of excitement is gathering around how this is a significant step for building AI systems.

Things are moving so fast that the Model Context Protocol won’t necessarily be the same in a few months as it is today. In the near future, the MCP might not even exist in the same way.

But right now, it’s intriguing and worth talking about!

What is it? Where did this come from? #

Anthropic released the Model Context Protocol in November 2024. They had been working on it for a bit before than, but this was when it became available to the public.

The Model Context Protocol is basically a specification for integrating LLM applications with external data sources or tools. For example, if you want to use an LLM to query a real database or make an API call to an external service, the MCP helps with that.

Key components #

graph LR Host[Host
LLM application/IDE] Client1[Client 1] Client2[Client 2] Client3[Client 3] Server1[Server 1] Server2[Server 2] Server3[Server 3] ExternalData1[External Data Source 1] ExternalData2[External Tool 1] ExternalData3[External Data Source 2] Host -- Manages --> Client1 Host -- Manages --> Client2 Host -- Manages --> Client3 Client1 -- Connects to --> Server1 Client2 -- Connects to --> Server2 Client3 -- Connects to --> Server3 Server1 -- Accesses --> ExternalData1 Server2 -- Accesses --> ExternalData2 Server3 -- Accesses --> ExternalData3

Host #

The host is the main coordinator that handles connections between the client and server. In practice, this is the LLM application that’s being used – could be an IDE, etc.

Client #

A client provides the host a way to connect with a server and is responsible for the back-and-forth messaging.

Server #

The server is probably the most interesting part of the protocol. It bridges external data and tools with the clients.

What are the mechanisms? #

The client-server connection is one-to-one.

Any of four different message types may be sent over this connection:

  • Requests: one side expects a response from the other side
  • Results: a successful outcome corresponding to a request
  • Errors: a failed outcome corresponding to a request
  • Notifications: one side sends this without an expectation of a response

All messages are formatted and transmitted using the JSON-RPC approach, over a transport method. The built-in transport methods are (although custom transports can be defined):

  1. Stdio: stdin and stdout, better for local integrations
  2. Server-sent events: over HTTP, better for streaming

Which building blocks does the protocol provide? #

Servers may surface various things via a few different primitives.

Resources #

These provide the client application a way to access data. Most commonly resources will be text or binary data like files, code, logs, images, video, and a lot more.

Prompts #

Prompts are for the user’s benefit. Servers can define reusable prompt templates that can accept arguments or context. For example, there may be different prompts templates for linting code vs. writing tests for code.

Tools #

Tools are how LLMs can interact with the outside world. In the Model Context Protocol, servers can expose tools so that the models themselves can invoke them. The tool definition includes what the tool does and inputs it accepts to perform its work. Consider something like a database query that needs a table, columns, and operation type.

So how can I use the protocol? #

There’s a whole separate discussion to be had about developing things that conform to the protocol. For now, let’s focus on how you might use elements that have already been built using the protocol.

Getting an LLM application #

For an LLM application that supports MCP, something like Claude for Desktop or Cursor is a good starting point.

Finding a server #

Because this is a protocol, the idea of a server is abstracted away from implementations of servers. That said, there are some helpful reference implementations here. You’ll notice some common software like Postgres, Google Drive, and Github.

Companies and the larger community are also implementing servers. Those can be found here – Stripe, Cloudflare, Discord, and a bunch more are available already.

The work in this space is rapid, so the ecosystem is still growing and tools not available today may soon become available!

Ok, is there a reason this is all significant? #

In short: AI agents. We talked previously about how AI agents work.

Where the Model Context Protocol comes into play is defining how the agent interacts with the environment. The agent uses tools to understand or act upon its environment. Adding that capability for agents becomes a lot easier and more consistent with this protocol.

Also, the MCP may have a side benefit of encouraging more companies or tool providers to surface ways for LLMs to harness that functionality.

As the AI ecosystem solidifies, builders converge on patterns. This is how RAG happened, and now with agents, it looks like something similar is happening.

Will this be the final standard or even the final iteration? No one knows, but it’s interesting to see how it plays out.