What Is MCP? The Model Context Protocol Explained
What the Model Context Protocol is, one request traced end to end, and the three problems people expect MCP to solve that it explicitly does not.
The Model Context Protocol, or MCP, is an open standard for connecting AI applications to outside systems: your files, a database, a search index, a calendar, an internal API. Instead of every AI tool inventing its own way to plug into every service, a service exposes one MCP server and any MCP compatible application can use it.
It is a plumbing standard. That sounds unexciting and is the entire point, because the thing standing between a capable model and a useful one is almost always access rather than intelligence.
The problem it solves
Before a standard existed, connecting five AI applications to five internal systems meant twenty five separate integrations, each written and maintained by hand, each breaking independently. Every new AI tool started that work from zero.
With a shared protocol, each system is wrapped once and each application speaks the protocol once. Five plus five instead of five times five. That is the whole economic argument, and it is why adoption moved quickly across a range of clients including Claude, ChatGPT, Visual Studio Code and Cursor.
The three pieces
The host is the AI application you actually use. A chat client, an IDE, a coding agent.
The client is the connector inside the host, one per server, that handles the conversation with that server.
The server is the small program wrapping a system, offering a defined set of things it can do.
A server is usually far smaller than people expect. Wrapping an internal API might be a few hundred lines whose only job is to describe what is available and pass requests through.
What a server exposes
Three kinds of thing, and the distinction matters more than it first appears.
Primitive | What it is | Who decides to use it |
|---|---|---|
Tools | Actions the model can take, such as run a query or create a record | The model, during its turn |
Resources | Data that can be read into context, such as a file or a record | The application, often chosen by the user |
Prompts | Prepared instruction templates for a common task | The user, usually explicitly |
Tools get the attention because they are the ones that let a model act rather than answer. Resources are the quieter half and often the more useful one, because pulling in exactly the right document beats a clever tool call.
One request, end to end
Concrete beats abstract here. Suppose your host is connected to an MCP server wrapping your company support database, and you ask: how many tickets did we open last week?
On connecting, the client asks the server what it offers. The server replies with its list, including a tool that runs a read only query, described in plain terms with the arguments it accepts.
Your question goes to the model along with those descriptions, so the model now knows this capability exists.
The model decides the question needs data it does not have, and emits a request to call that tool with a date range.
The host checks permission. Depending on configuration this is an approval prompt, a pre-approved rule, or a refusal.
The client sends the call to the server. The server runs the query against the real database and returns rows.
The rows go back into the conversation as context, and the model writes the answer using them.
Step four is the one to remember. The protocol carries the request, the host decides whether it happens. The model asking for something is not the same as the model getting it.
Three things MCP does not do
Most confusion about MCP comes from expecting it to solve problems it deliberately leaves alone.
It does not decide when a tool should be used. That judgment belongs to the model and the host. A perfectly written server attached to a model that reaches for the wrong tool produces confidently wrong answers, and no amount of protocol fixes that.
It does not secure anything on your behalf. A server exposes exactly what you build into it, to whoever the host lets connect. If you wrap a database with a tool that runs arbitrary queries, you have built a tool that runs arbitrary queries. The recent reminder of why this matters came when Anthropic disclosed that Claude models reached real systems during security testing, where the failure was in what the environment permitted rather than in any protocol.
The same reasoning applies to letting a coding agent's MCP-connected tools touch your terminal or file system. The protocol will happily carry the request either way; whether it is safe to grant comes down to how you give an AI coding agent safe terminal access in the first place, not anything the protocol enforces for you.
It does not save you context. Every tool description sits in the window, and every result returned lands in it too. Connecting a dozen servers with fifty tools between them can consume a serious share of your budget before you have asked anything, which is a real cost once you understand how context windows behave. Connect what you need.
Does this matter if you are not a developer?
Indirectly, and increasingly. You will not write a server. You will notice the difference between an AI tool that can reach your actual data and one that can only talk about it, and MCP is a large part of why more tools now can.
It also explains a behaviour you may already have seen. When a coding tool reads your files, checks a live API and runs a command rather than guessing, that is this kind of connection at work. It is the mechanical difference underneath what makes something an AI coding agent rather than a chat window, and the same access question shapes what you can realistically build with AI.
MCP standardizes how a model fetches live data on demand. The older, still common approach to a related problem is retrieval-augmented generation, which works differently and is worth knowing as a contrast.
MCP connects a model to tools and data, but the model on the other end of that connection does not have to be a frontier model. Small language models are increasingly the right choice for narrow, high-volume, tool-connected tasks, where speed and cost matter more than broad reasoning.
Frequently asked questions
Is MCP the same as an API?
No. An API is the interface to one service. MCP is a standard way to describe any service to a model, including what it offers and how to call it. Servers commonly sit in front of ordinary APIs and translate.
Who controls MCP?
It is published as an open standard with public documentation and specification revisions, and it is implemented by multiple independent vendors rather than being tied to a single product.
The most recent revision, dated 2026-07-28, was the largest change to the spec since launch. The protocol core moved to a stateless model that scales on ordinary load-balanced HTTP infrastructure, added Multi Round-Trip Requests and header-based routing, and introduced a formal extensions framework covering things like MCP Apps and a dedicated Tasks extension. It also deprecated Dynamic Client Registration in favor of Client ID Metadata Documents (CIMD) for authorization. None of that changes what MCP is for day to day, but it is worth knowing if you are reading documentation or example servers written before mid-2026.
Do I need MCP to use AI at work?
No. It matters when you want AI to reach systems that hold your own data. For general assistance it is invisible and irrelevant.
Can an MCP server change my data?
Only if it was built with tools that write, and only if the host permits the call. Read only servers are common and are the sensible default when you are starting.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
