MCP (Model Context Protocol): A Common Language for AI Tooling
MCP gives models a standard interface to tools and data sources. The client-server model, the N-times-M problem, security boundaries and practical use.
Every time you want to connect a model to your own data, you do the same work: you write a connector. Decide to use a different model, and you write it again. The Model Context Protocol is a shared interface aimed at removing that repetition.
2026-07-28 revision removed sessions, the Mcp-Session-Id header and the initialize handshake. The concepts on this page still hold; for the transport-layer changes read MCP 2026: why the protocol went stateless.The problem it solves
This is the N-times-M problem: with N models and M data sources, the number of connectors you need is their product. Every new tool must be wired to every model separately. A shared protocol turns that product into a sum: each source is written once as a server, and each model becomes a client once.
How it works
The architecture rests on a client-server split. An MCP server exposes a specific capability — a filesystem, a database, an API. The application hosting the model acts as a client, connects to that server, discovers which capabilities exist, and invokes them when needed.
Discoverability is the key point: the client learns at runtime which tools a server offers and which parameters they expect. Adding a new capability therefore does not require changing client code.
What it exposes
- Tools: actions the model can invoke — run a query, read a file, create a record.
- Resources: data the model can read — documents, schemas, configuration.
- Prompts: reusable, prepared instructions.
Security boundaries
Giving a model tools means giving it authority. Three rules matter most in practice: servers should run with the narrowest permission that actually works, irreversible actions should require approval, and tool output must never be treated as trusted instruction.
That last point matters: a document arriving from outside can carry text that looks like an instruction to the model. This is precisely the surface for an indirect prompt injection attack.
When to use it
| Situation | MCP |
|---|---|
| One model, one tool | An extra layer |
| Several sources, one application | Brings order |
| Sharing tools with other teams | The real payoff |
| Possibility of switching models | Reduces lock-in |
Frequently asked questions
How does it differ from function calling?
Function calling is how a model requests a tool. MCP is how that tool is defined and served. They complement rather than replace each other.
Is there a performance cost?
It adds a network hop. Negligible in most scenarios, though direct integration is faster for very high-frequency calls.
How many tools should I define?
Few. Dozens of tool definitions fill the context window and make selection harder for the model. Expose only the tools that task needs.
MCP is a practical standard that removes repeated integration work from the agent ecosystem. For more, see function calling and autonomous agent architectures.
