MCP Servers: Understanding the Model Context Protocol
Posted on June 3, 2026 • 6 min read • 1,137 wordsThe Model Context Protocol (MCP) is an open standard that connects language models to tools and data. This first article explains, in plain terms, what an MCP server is, its architecture, and why it's a game changer for AI agents.
Language models are brilliant at reasoning over text, but by nature they are cut off from the world. A model cannot read your files, query your database, or call an API unless it is explicitly given the means to do so. The Model Context Protocol (MCP) is the standard that solves this problem in a generic way. This first article lays the groundwork; the next ones will dive into building a server and integrating it into an ecosystem.
I. The problem: connecting LLMs to the real world
A language model, on its own, can do only one thing: produce text from text. As soon as you want it to perform a useful action — check a calendar, read a Git repository, send a message — you have to plug an external tool into it.
Historically, every application reinvented this plumbing. To connect M models to N tools, you ended up writing M × N custom integrations: one for Claude + GitHub, another for a different model + GitHub, yet another for Claude + Slack, and so on. Each connection had its own format, its own authentication, its own logic. That work was costly, fragile, and impossible to share.
MCP’s idea is to replace this M × N with an M + N: a common protocol that every model speaks on one side and every tool exposes on the other.
II. What is the Model Context Protocol?
The Model Context Protocol is an open standard, released by Anthropic in late 2024, that defines how an AI application communicates with external data sources and tools.
Concretely, MCP standardizes three things:
- The message format: MCP relies on JSON-RPC 2.0, a simple and battle-tested remote procedure call protocol.
- The vocabulary: what a tool can offer a model is described with common concepts (tools, resources, prompts — see section IV).
- The transport: how messages travel (locally or remotely).
Because it is an open standard, anyone can write an MCP server, and it will work with any compatible client — without any prior agreement between the two sides.
III. The architecture: host, client, server
MCP is built on three clearly distinct roles:
- The host: the application the user interacts with and that embeds the model. For example Claude Desktop, an IDE, or Claude Code.
- The client: a component that lives inside the host and maintains a one-to-one connection with a server. A host talking to three servers therefore manages three clients.
- The server: a lightweight program that exposes specific capabilities (access to a filesystem, a PostgreSQL database, the GitHub API…).
┌─────────────────────────────┐
│ HOST │ (Claude Desktop, IDE, Claude Code…)
│ ┌─────────┐ ┌─────────┐ │
│ │ Client A│ │ Client B│ │
│ └────┬────┘ └────┬────┘ │
└────────┼───────────┼────────┘
│ │
┌─────▼────┐ ┌───▼──────┐
│ Server │ │ Server │
│ GitHub │ │ Postgres │
└──────────┘ └──────────┘This separation is essential: the host knows nothing about a server’s internals, it only knows how to talk to it through the protocol. You can add, remove, or replace a server without touching the host.
IV. What an MCP server exposes: tools, resources, prompts
An MCP server provides three types of primitives. This is the heart of the protocol:
| Primitive | Role | Controlled by |
|---|---|---|
| Tools | Functions the model can call to act (create a ticket, run a query). | The model |
| Resources | Read-only data that enriches the context (a file, a database row, a page). | The application |
| Prompts | Reusable request templates, triggered by the user (a typical workflow). | The user |
The most important distinction is between tools and resources. A tool does something and may have side effects; it’s the model that decides to invoke it. A resource only provides information; it is generally chosen by the application or the user. This separation helps reason about security: you know precisely what can change the state of the world.
V. Why MCP instead of a homemade function-calling setup?
Models already know how to call functions (function calling). So why an extra protocol?
Because raw function calling solves “how to call a function” but not “how to standardize and share these functions.” Without a standard, every team redefines its schemas, its authentication, and its transport. MCP provides the missing layer.
Anthropic sums MCP up with an analogy that has become famous: “a USB-C port for AI applications.” Before USB-C, every device had its own proprietary connector; you needed one cable per peripheral. USB-C imposed a universal plug. MCP plays the same role: a single connector between models and anything you want to plug into them.
The concrete benefits:
- Reusability: a server written once works with every compatible client.
- Decoupling: you swap the model or the tool without rewriting the plumbing.
- Ecosystem: you benefit from servers the community has already written.
VI. Concrete use cases
MCP comes into its own as soon as an assistant has to touch a real system:
- Development: a server exposing a Git repository, the filesystem, or a terminal lets an assistant read code, propose changes, and run tests.
- Data: a PostgreSQL server or a connector to a data warehouse lets the model answer questions based on your real figures.
- Productivity: servers for Slack, a calendar, or an issue tracker turn the assistant into a genuine operational copilot.
- Documentation: a server that indexes a knowledge base gives the model up-to-date context instead of letting it hallucinate.
In each of these cases, the business logic lives in the server, not in the model — which makes it testable, versionable, and reusable.
VII. The ecosystem and where to start
An ecosystem has quickly formed around MCP:
- Official SDKs (Python, TypeScript, and other languages) to write a server in a few dozen lines.
- Ready-to-use servers for the most common services (filesystem, GitHub, databases, etc.).
- Adoption beyond Anthropic, with several major AI players rallying around the standard during 2025.
To get started, the simplest path is to connect an existing server to a compatible host and watch the model use it. The two next steps — building your own server and integrating it cleanly into an ecosystem (security, remote transports, best practices) — will be the subject of the upcoming articles in this series.
Conclusion
The Model Context Protocol does not invent the idea of giving tools to a model; it standardizes it. By turning a tangle of custom integrations (M × N) into a universal plug (M + N), MCP does for AI assistants what USB-C did for our devices: a common, open, reusable connector.
In this article, we laid the foundations: the problem it solves, the host/client/server architecture, the three primitives (tools, resources, prompts), and the value compared to a homemade integration. The next articles will move to practice by building a server end to end.