MCP (Model Context Protocol) Explained
What MCP is, why it exists, and how it changes the way AI applications connect to tools and data.
The problem MCP solves
Before MCP, every AI application that wanted to connect to an external tool or data source (a calendar, a ticketing system, a database, a file store) needed custom integration code written specifically for that pairing. With N AI applications and M external tools, that's up to N × M separate integrations — each one built, maintained, and secured independently. This is sometimes called the "M×N integration problem," and it's the same class of problem that motivated standards like USB or ODBC in earlier eras of computing.
What MCP is
The Model Context Protocol is an open, standardized protocol for connecting AI applications to external tools, data sources, and predefined prompts. Instead of bespoke integration code per pairing, a tool provider builds one MCP server, and any MCP-compatible AI application can connect to it. This turns the M×N integration problem into roughly N + M: build the connector once per side, and it works with everything else that speaks the same protocol.
Core architecture
| Component | Role |
|---|---|
| Host | The AI application the person actually uses (a chat app, an IDE plugin, an agent framework). It coordinates one or more MCP clients. |
| Client | Maintains a 1:1 connection to a single MCP server, handling the protocol-level communication. |
| Server | Exposes a specific tool or data source (e.g. a ticketing system, a codebase, a database) through the standardized protocol, independent of which AI application connects to it. |
Key concepts exposed by a server
- Tools — functions the model can actively invoke to take an action or fetch information (e.g. "create a ticket," "search the knowledge base").
- Resources — data the host application can read and include as context (e.g. a file, a database record) without necessarily invoking a function.
- Prompts — reusable, parameterized prompt templates a server can offer to standardize common interactions.
How it compares to plain function calling
Function/tool calling (see the glossary) is the underlying model capability that lets an LLM decide to invoke a function and use its result. MCP sits a layer above that: it standardizes how tools are discovered, described, and connected across different AI applications, so the same tool integration can be reused everywhere instead of being re-implemented for each app's own plugin format. Function calling is "the model can call a function"; MCP is "here's a standard way for any compliant app to find out what functions are available and call them consistently."
Why it matters
- Reusability — a tool builder writes one MCP server and it works across every compatible AI application, rather than maintaining separate plugins per platform.
- A growing ecosystem — because the protocol is open, a shared library of MCP servers exists for common systems, reducing custom integration work.
- Consistency — users get a similar experience connecting tools regardless of which AI application they're using.
- Separation of concerns — tool builders focus on their domain (e.g. a great ticketing integration); AI application builders focus on the host experience, without needing deep knowledge of every possible external system.
A common shorthand for this idea: MCP aims to be something like "USB-C for AI applications" — one standard connector instead of a different cable for every device.
Security considerations
Connecting an AI application to external tools widens its capabilities — and its attack surface. Treat MCP servers with the same caution you'd apply to any third-party integration:
- Tool output is data, not instructions. A compromised or malicious MCP server could return content designed to look like a command; a well-built host treats everything a server returns as untrusted data (see AI Security).
- Least privilege — only enable the specific servers and tools a given task actually needs, not everything available.
- Vet the source — only connect to MCP servers from providers you trust, the same way you'd vet any code or API you integrate with.
- Review sensitive actions — tools that send messages, modify data, or spend money should typically require explicit user confirmation before executing.