MONA explainer 9 min read May 25, 2026

What Is the Model Context Protocol and How It Connects AI Assistants to External Tools

Model Context Protocol linking one AI model to external tools, data sources, and APIs through a single standard interface

Table of Contents

ELI5

The Model Context Protocol (MCP) is an open standard that lets an AI application talk to external tools, data, and APIs through one shared language, so a model can read files or call services it never saw during training.

A trained LLM is frozen. Once pre-training ends, its weights stop moving; it cannot learn your filenames, open your database, or discover an API that shipped last week. And yet Claude can read a local file, query a live system, and invoke a service it never encountered in training.

Not retraining. A connection.

The thing standing between a static model and a living world is not a bigger model. It is a protocol, and the shape of that protocol explains both why AI assistants suddenly got useful and where they quietly became fragile.

One Adapter Instead of a Thousand Cables

Before any standard existed, every AI application that wanted to reach an external tool needed a bespoke integration: custom code to talk to Slack, more custom code for GitHub, more for Postgres. Multiply that by every model and every host application, and you get an integration matrix that grows multiplicatively. Engineers called it the M×N problem, where M applications each need wiring to N tools.

What is the Model Context Protocol (MCP)?

The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that defines how an AI application discovers and uses external capabilities (Anthropic Blog). Its central trick is combinatorial: by agreeing on one shared interface, an M×N integration matrix collapses into M+N. Build one connector per tool, build one client per application, and any application speaks to any tool that follows the spec.

The design is not new in spirit. MCP borrows its core idea from the Language Server Protocol, which solved the same explosion for code editors and programming languages a decade earlier (MCP Specification). One editor speaking LSP can talk to any language server; one host speaking MCP can talk to any tool server.

This is where the common mental model goes wrong. People hear “connect AI to tools” and picture a plugin marketplace, a catalogue of features bolted onto a model.

Not a plugin marketplace. A protocol.

The distinction matters mechanically. A plugin is a feature you install into one product. A protocol is a contract two independent programs agree to honor, which is why an MCP server written for Claude Desktop also works inside an unrelated editor or agent that never knew it existed. Underneath, every message is plain JSON-RPC 2.0, the same request-response format used across much of the tooling world (MCP Specification). The connection is stateful: when a host and a server first meet, they negotiate capabilities, each declaring what it supports before any real work begins.

The standard’s reach is now structural rather than vendor-specific. In December 2025, Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation, with OpenAI, Google, Microsoft, and AWS among its backers (Anthropic Blog). An official registry launched in September 2025, indexing a sprawling ecosystem of community servers (MCP Blog). The protocol stopped being one company’s idea and became shared infrastructure.

What Actually Travels Across the Wire

A protocol is only as clear as the roles it defines. MCP splits the world into three parts, and understanding the split is the whole game: it tells you exactly where the model sits, where your tools sit, and what passes between them.

How does the Model Context Protocol connect AI models to external tools, data, and APIs?

Three roles do the work (MCP Docs). The MCP Host is the AI application itself, the program running the model and initiating connections. Inside the host runs one MCP Client per connection, a dedicated connector that maintains a single link to a single server. At the far end sits an MCP Server, a separate program that wraps a real capability: your filesystem, a database, a ticketing API.

The crucial point is that the model never touches the tool directly. The host asks the client; the client speaks the protocol to the server; the server does the work and returns a structured result. The model only ever sees clean, described capabilities, never raw network plumbing.

Each server exposes up to three kinds of primitive (MCP Specification):

Primitive	What it provides	Who decides to use it
Resources	Data and context (files, records, documents)	Application or model selects
Prompts	Templated, reusable workflows	Usually user-triggered
Tools	Functions the model can execute	Model chooses during reasoning

The flow runs the other way too. A server can reach back toward the client through three client-side features: sampling, where the server requests an LLM completion from the host; elicitation, where the server pauses to request missing information from the user; and logging, where the server streams diagnostic messages back to the host (MCP Docs). The connection is a two-way conversation, not a one-way remote call.

Two transports carry these messages. For a server running locally on your machine, MCP uses stdio, piping JSON-RPC over the process’s standard input and output. For a remote server reached over the network, it uses Streamable HTTP, an HTTP POST channel with an optional Server-Sent Events stream for messages the server pushes back (MCP Docs). Streamable HTTP replaced an earlier, more brittle HTTP-plus-SSE design, so a current implementation should target Streamable HTTP rather than the superseded transport.

Remote servers also need a trust boundary, and here MCP leans on an established standard rather than inventing one. Authorization uses OAuth 2.1: the server acts as an OAuth resource server, the client as an OAuth client, and the server publishes protected resource metadata so the client can discover where to obtain a token (MCP Specification). The model never handles credentials; the protocol layer does.

As of the 2025-11-25 specification, these connections remain stateful and begin with an explicit capability handshake. That detail is worth pinning down, because the spec moves quickly. It has been revised four times in roughly its first year, so a serious implementation should target a dated revision, not “the latest MCP” in the abstract.

Diagram of MCP host, client, and server roles exchanging JSON-RPC messages, with tools, resources, and prompts flowing from server to model — MCP routes every request through a host, a per-connection client, and a capability server, so the model never touches a tool directly.

What Standardization Buys, and What It Exposes

Once you see the architecture, its consequences become predictable rather than surprising.

If you add a new tool to your stack, you write one server and every MCP-aware host can use it without changes on their side.
If a tool returns a structured result instead of free text, expect more reliable model behavior, because the model reasons over typed capabilities rather than guessing at an API’s shape.
If a remote server is scoped through OAuth authorization, expect the model’s reach to stay bounded by the token rather than by hoping the model behaves, since the limit is enforced at the protocol layer.

The same standardization that makes integration cheap also widens the attack surface, and this is the part that gets underweighted. Because tools advertise themselves through text descriptions, and because the model reads those descriptions to decide what to call, a description is also an input the model trusts. Security researchers have shown that tools can smuggle malicious instructions inside their own descriptions, and that a server can mutate its behavior after a user has already approved it (arXiv). The current spec does not require clients to validate any of this.

Rule of thumb: treat every connected MCP server as code you are running with the model’s full attention, not as a passive data source.

When it breaks: the failure mode is tool poisoning. Because every connected server is part of the model’s trust boundary, a single compromised or malicious server in the chain can inject instructions the model will follow, and the protocol provides no built-in mechanism that forces the client to catch it. Standardizing the interface did not standardize trust.

The Data Says

MCP works because it moves the hard problem out of the model and into a protocol: a stateful, JSON-RPC contract between a host, a client, and a capability server. That design turned a multiplicative integration burden into an additive one and spread fast enough to become a shared, foundation-governed standard within a year. The unsolved half is trust. The interface is standardized; verifying what flows across it is still left to whoever builds the host.

Aha Moments

MAX

Mona framed this as a contract, and that is exactly why I trust it more than the plugin chaos it replaced. A protocol gives you a spec: capability negotiation up front, typed primitives, declared boundaries. That means failure modes become inspectable instead of mysterious. When a tool returns structured output instead of free text, I can write a validator against it; when a server declares its roots, I can audit what it should never touch. The architecture pushes ambiguity to the edges where I can actually catch it. My one caution: a clean interface tempts teams into assuming the thing behind it is also clean. The contract describes the shape of the conversation. It says nothing about whether the other party is honest.

DAN

Picking up where Max left off, the spec discipline is also why this won the market so fast. A protocol that any host can speak and any tool can serve creates exactly the network effect that decides standards wars. Once the major labs and cloud providers lined up behind a single foundation-governed standard, the question stopped being which integration format to back. The connector you build once now reaches every compliant host, so the incentive to build on the standard compounds with every new adopter. For anyone shipping AI tooling, the strategic read is simple: you are either speaking this protocol or you are building integrations nobody else can reuse. The ecosystem already chose. Fighting that choice is a losing position.

ALAN

Max wants inspectable contracts, Dan wants the winning standard, and both are right, which is what worries me. We have agreed, at industry scale, on how a model reaches into our systems before we agreed on how to verify what it finds there. Mona named the gap precisely: the interface is standardized, the trust is not. A poisoned description, a server that turns hostile after approval, and the model dutifully follows instructions nobody audited. The convenience is real and the adoption is irreversible. So the uncomfortable question is not whether MCP will spread further, because it already has. The question is this: when a tool we invited in betrays the model’s trust, who is accountable for the instructions nobody chose to read?

AI-assisted content, human-reviewed. Images AI-generated. Editorial Standards · Our Editors