What is the Model Context Protocol?

You can think of the Model Context Protocol (MCP) as USB for large language models (LLMs), allowing an LLM to interact with a variety of external systems in a uniform manner. It was developed by Anthropic to solve the fundamental problem of getting a text generator (LLM) to perform real-world actions on a user’s behalf.

Solving the M x N Problem

With a growing number of powerful LLMs (M) and a vast universe of applications and APIs (N) for them to interact with, one would need to develop M x N custom connections to link every LLM with every application.

By offering a standardized solution, MCP converts the M x N headache into a much more manageable M + N problem. As long as each LLM can use an MCP client, it can communicate with every application for which an MCP server has been created.

The Architecture

At its heart, MCP operates on a client-server architectural model. The main components, connecting an LLM to an external application are:

• MCP Host – The application which communicates with the LLM, such as an AI-chat interface (LM Studio) or a coding assistant (GitHub Copilot).
• MCP Client – A component within the host application which communicates with an MCP server. There’s a one-to-one relationship between a client and a server. A host can run multiple clients to access multiple services (e.g. file system, email, and database).
• MCP Servers – The bridge that translates client requests into actions on the external application. An MCP server exposes a set of “primitives” that categorize the different types of interactions an LLM can have with an external resource.

The Primitives

Exposing server functionality through the standard primitives allows for dynamic interaction. The MCP client is able to query a server to discover the capabilities offered, and then pass this information on to the LLM so it can make requests accordingly.

• Resources – Represent sources of data or content that the LLM can access. Examples include files, database entries, or the content of a webpage. Accessing a resource is a read-only operation.
• Tools – Executable functions that allow an LLM to take action in the external environment. Examples include sending an email, creating a calendar event, or updating a database record.
• Prompts – Pre-defined reusable templates or instructions that can guide the LLM in its interaction with the tools and resources.

The Interactions

The above diagram outlines the high level flow that allows a user to request an LLM to perform an action, in this case sending an email. Let’s walk through the steps:

Step 0: Tool Discovery (Occurs in the Background)

Before any user request, the MCP Client communicates with the MCP Server to learn what tools it offers. The server might respond, “I have a tool named send_email that requires recipient_email, subject, and body”. The MCP Client passes this information to the LLM’s context, making it aware of its email-sending capability.

Step 1: User Initiates a Request

The user tells the LLM, “Hey, can you send an email to Jane Doe and let her know the project proposal has been uploaded to the shared drive?” The LLM reasons about the user’s intent, decides which tool to use, and seeing that the tool requires a “subject” might ask the user for more information.

Step 2: LLM Proposes Tool Call

With all necessary arguments, the LLM generates the JSON required for a structured tool call:

{
  "tool_calls": [
    {
      "name": "send_email",
      "arguments": {
        "recipient": "Jane.Doe@email.com",
        "subject": "Project Proposal Uploaded",
        "body": "Hi Jane, Just letting you know that..."
      }
    }
  ]
}

Step 3: MCP Client Makes JSON-RPC Request

Having detected the structured tool call in the LLM’s output, the host application passes this to the MCP Client, which then:

• Parses the LLM’s output to extract the structured content.
• Validates the extracted data against the tool’s schema.
• Attaches any necessary security/context information (E.g. auth tokens)
• Generates the final JSON-RPC payload and handles network communication to the MCP Server

Step 4: MCP Server Executes Action

The MCP server validates the received request, translates it into the specific API call required by a real email service, and executes the action. The email service’s response is then translated into a standardized MCP response and sent back to the MCP Client.

Step 5: LLM Conveys Status to the User

The MCP client receives the result and passes it to the host application. The host injects this result into the LLM’s context, typically as a new message with a special “tool” role. Finally, the LLM generates a natural language response to inform the user, “The email has been sent to Jane Doe.”

Summary

The Model Context Protocol provides us with a simple yet elegant means for connecting an LLM to an unlimited number of external systems. This converts LLMs from useful but limited chat-bots to truly powerful agents that can act on our behalf. With adoption by major players in the AI field, like Anthropic, OpenAI, Google, and Microsoft it is fast becoming the de-facto standard that all agents will converge upon.

What are some of the most useful MCP servers that you have used?

Source: Read More