What is it?
The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in late 2024, that defines a standard way for AI applications to connect to external systems: files, databases, SaaS apps, developer tools and more.
Before such a standard, connecting M AI applications to N tools meant building up to M × N custom integrations. With MCP, a tool provider builds one server, an AI application implements one client, and any compliant pair can work together. People often compare it to a universal connector: an analogy for the idea, not a literal description of the wiring.
Details of the specification evolve; always check the current specification and documentation at modelcontextprotocol.io before building.
Why does it matter?
- Less glue code: write the integration once, reuse it across compatible applications.
- Discoverability: a client can ask a server what it offers, instead of hard-coding it.
- Ecosystem: many ready-made servers exist for common systems, and you can build your own.
- Clear separation: the AI application handles the model and user experience; the server handles access to the underlying system.
It also concentrates security responsibility: a connected server can read data or act on your behalf, so what you connect — and what you approve — matters (AI Privacy and Security: What to Know Before You Paste Data).
How does it work?
Roles, in brief (full detail in MCP Servers and Clients: Roles, Transports and Setup):
- Host: the AI application the user interacts with (a chat app, IDE assistant, agent).
- Client: a component inside the host that maintains a connection to one server.
- Server: a program exposing capabilities.
A server can offer three main kinds of capability:
- Tools — actions the model can invoke (like Function Calling (Tool Calling) Explained functions): "create issue", "run query".
- Resources — data the application can read, such as files or records, for context.
- Prompts — reusable prompt templates users can select.
Messages use JSON-RPC 2.0. Servers can run locally (the client launches them and talks over standard input/output) or remotely over HTTP. In specification revisions up to 2025-11-25, a connection begins with an initialisation handshake in which both sides declare what they support. Revision 2026-07-28 removed that handshake and protocol-level sessions: every request now carries the protocol version and client capabilities, and servers advertise theirs through a server/discover call. Which model your SDK implements depends on its version, so check (MCP Servers and Clients: Roles, Transports and Setup). Either way, the client then lists and calls tools, reads resources and so on.
// Client asks a server what tools it has
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }
// Client calls one
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
"params": { "name": "search_issues", "arguments": { "query": "login bug" } } }(Simplified; consult the specification revision your SDK implements for the exact fields and the connection sequence. For protecting remote servers, see MCP Authorization (OAuth for MCP Servers).)
Example
A developer connects their IDE assistant to a Git hosting MCP server and a database MCP server. The assistant can now list open issues, read a failing test, query a staging database (read-only credentials), and propose a fix — all through the same protocol. Swapping to a different MCP-compatible assistant later does not require rewriting those two integrations.
When should I use it?
MCP makes sense when you want tools reusable across applications, when you consume third-party integrations, or when building an ecosystem where many clients should reach your service. For a single application calling a couple of internal functions, plain Function Calling (Tool Calling) Explained may be simpler. See Function Calling vs MCP and MCP vs API: What's the Difference?.
Common mistakes
- Thinking MCP replaces APIs. MCP servers usually wrap APIs (MCP vs API: What's the Difference?).
- Installing unvetted servers. They run code and can reach your data.
- Granting broad credentials instead of least privilege.
- Assuming MCP makes a model smarter. It provides access, not capability.
- Skipping approval prompts for sensitive actions.
- Treating server-provided text (tool descriptions, results) as trusted (What is Prompt Injection?).