What Is MCP? Understanding the Model Context Protocol

Published in November 2024, the Model Context Protocol (MCP) is one of the more significant developments in how we interact with AI systems. Designed to standardize communication between Large Language Models (LLMs) and the context they’re given, MCP helps users get more consistent, useful results, especially when using LLM clients or calling models directly via API.

But before we dive into what makes MCP a breakthrough, we need to pause and ask: What actually is it, and what makes it different from something like an API or REST?

To answer that, let’s take a step back and look at how computers (and by extension, AI systems) talk to one another in the first place.

MCP as a Communication Protocol: How It Works

Let’s start small.

MCP is, in its simplest form, a communication protocol.

And a protocol? That’s not a single tool or technology, it’s a shared rulebook. A protocol defines how two pieces of software are supposed to exchange information, ensuring that when one side sends something, the other knows exactly how to interpret it.

In fact, much of the internet runs on protocols. You send an email using SMTP. The person on the other end reads it thanks to IMAP. You connect securely via SSH. You visit websites over HTTP (or more securely, HTTPS).

But rarely does a single protocol work alone. Most online interactions involve stacks of protocols, working together in layers to make complex communication feel seamless.

How Protocols Work Together

Picture yourself reading your favorite blog.

Behind the scenes, the server, which is software on the specific machine hosting the website, and the client, which is usually your web browser.

The visible part of this exchange is handled by HTTPS. But under the hood, several other protocols do their part:

• TLS secures the connection through encryption
• TCP breaks the data into packets and reassembles them in the right order
• IP routes those packets across the internet to reach your device

Each layer of this communication follows its own set of rules, but they all work together. That’s the power of protocols: they’re not programs, but standards, and both sides (client and server) need to follow those standards precisely.

MCP, Interfaces and API Integration

Before we go deeper into MCP, it’s important to understand how it relates to another foundational concept: the interface.

An interface is not the same thing as a protocol. While protocols focus on the how (the transport and format of data), interfaces focus on what operations can be performed with that data.

An API (Application Programming Interface) is one type of interface. APIs don’t dictate the rules of data transport. Instead, they define the set of operations available to a developer or system.

In practice, APIs and protocols often appear side by side. Especially in regulated environments like healthcare, where data flow needs to be both safe and predictable, combining interfaces with well-defined communication rules is essential.

Different Interface Types Used with MCP

We use interfaces constantly, whether we realize it or not.

A graphical user interface (GUI) is what you see on your screen. Buttons, icons, dropdowns - that’s one kind of interface.

A command-line interface (CLI) is another. Think shells like Bash, PowerShell, or Python’s interpreter.

There’s also the TUI (Text-based User Interface), which is a more interactive variation of the CLI - still text-based, but with formatting, colors, and prompts that make it easier to use.

But for our purposes, the most relevant interface is the API.

Application Programming Interface (API)

An API defines what functions are available; what inputs they accept, what outputs they return. If you’ve worked with a framework or a software library, you’ve almost certainly used an API.

APIs are not limited to textual formats. There are also binary interfaces, like ABIs (Application Binary Interfaces), which serve similar purposes but operate at a lower, compiled-code level.

In web contexts, an API often becomes the engine for one or multiple endpoints. The URL paths a client uses to request specific data or trigger operations. While one endpoint is usually tied to a single function, the reverse is not always true; a single function might be accessible through several endpoints.

MCP Architecture and API Design

Here’s where things get more layered.

An API alone doesn’t handle communication. It only defines what can be done, not how the information travels.

That’s why APIs are almost always used alongside protocols. For instance, HTTP is the standard for most web APIs. But when we need real-time data - say, in a multiplayer game or collaborative editor - we switch to something like WebSockets.

If communication involves both an API and a protocol, the API’s design must account for the protocol’s characteristics. This is where API architectures come into play: design paradigms that define how APIs handle data, operations, and errors.

Common API Architectures Supporting MCP

You’ve probably heard of these already:

• REST – The most common architecture. It’s resource-centric and typically uses JSON or other textual formats.‍
• gRPC – Optimized for binary data and high-performance applications.‍
• GraphQL – Shifts focus from multiple resource-based endpoints to the structure of the returned data.

While REST is by far the most common with MCP, other architectures might also be used.

Frameworks and MCP Implementations

Eventually, these concepts need to be implemented in code.

Frameworks handle this by providing ready-made structures for communication and logic.

For example:

• To use a protocol like HTTP, Python developers might reach for uvicorn, a high-performance ASGI server.
• To implement MCP itself, there’s FastMCP, a Python framework designed specifically to support the protocol.
• To expose an API architecture, developers use FastAPI, which supports REST and is often paired with uvicorn.

The distinction is crucial: an API is implemented inside the server. It’s how the server presents its operations. A protocol governs the entire exchange. MCP belongs to the latter category.

Model Context Protocol (MCP) for AI Systems

Just like HTTP, MCP is a communication protocol. But its purpose is highly specific: it provides structured, real-time context to an AI model.

That context might come:

• Directly, from a database, document, or data file.
• Indirectly, from an API endpoint that exposes structured information.

MCP can still rely on HTTP to transport data - as we saw earlier, protocols can be stacked to work together. The difference is in the client. Instead of a browser, the client becomes an LLM-enabled application; something capable of consuming, interpreting, and reasoning over the provided context.

In the future, protocols like WebSockets may become more prominent in MCP implementations so that LLM clients can maintain continuous context without constant refreshes. Ultimately, the direction this takes will depend on the tools and frameworks that emerge.

Advantages of MCP

Let’s talk benefits.

How MCP Overcomes LLM Training Data Limitations

One of the core issues with LLMs is that their training data is always outdated. There’s no such thing as a model trained on this morning’s patient record or the current weather report.

And training LLMs on sensitive or private data (like health records) isn’t just expensive, it’s risky.

MCP sidesteps this by fetching context live on request. Instead of relying solely on what the model already knows, you enrich it with data drawn directly from secure, up-to-date sources.

Why Not Just Use APIs?

Couldn’t someone just call an API directly?

Technically yes. But in practice, it's not that simple.

Navigating API documentation, authentication, endpoints - it’s a developer’s task. Most end users can’t or won’t go that far. By contrast, MCP allows users to simply ask a question and the LLM, equipped with MCP context, figures out how to fetch the right data.

Trial and Error Method

In our own testing, especially with our FHIR MCP Server and Apple Health MCP Server, we saw something fascinating.

LLMs don’t always get it right on the first try. But they adapt. They use trial and error, refining their requests, adjusting queries, and finding more accurate answers with each iteration.

In healthcare, where data is highly structured (and mistakes can have consequences), this kind of adaptive querying makes a real difference. It allows LLMs to work effectively with standards like FHIR and HL7, while still responding to natural language input from users.

{{lead-magnet}}

Final Thoughts

The Model Context Protocol doesn’t replace APIs, interfaces, or frameworks. It weaves them together in a way that feels cohesive, natural, and scalable.

It’s not a magic fix. But it solves a specific, increasingly important problem: how to make AI systems more aware of their environment without retraining them every time your data changes.

And that’s not just relevant to developers. It’s a step toward AI that’s genuinely useful in healthcare, where context isn’t just nice to have - it’s critical.