Model Context Protocol (MCP)
The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems such as files, databases, business tools and workflows. Introduced by Anthropic in November 2024, it gives an AI application one common way to discover and use the tools, data and prompt templates that a server exposes, instead of a custom integration for every pairing.
How MCP Works
MCP uses a client-server architecture with three participants:
- Host: the AI application the user works in, such as a chat assistant, an IDE or a coding agent.
- Client: a component inside the host that holds a dedicated connection to one server. A host creates one client per server it connects to.
- Server: a program that provides context and capabilities. It can run locally on the same machine or remotely as a hosted service.
The protocol has two layers. The data layer uses JSON-RPC 2.0 messages to define what clients and servers can say to each other, including capability discovery. The transport layer carries those messages, either over standard input and output for local servers or over Streamable HTTP for remote ones, where the documentation recommends OAuth for authorization.
Servers offer three core primitives:
- Tools: executable functions the AI application can invoke, such as running a query or creating an issue.
- Resources: data that provides context, such as file contents or a database schema.
- Prompts: reusable templates that help structure interactions with the model.
A client lists what a server offers (for example with tools/list) and then uses it (for example with tools/call). Clients can also offer capabilities back, such as elicitation, which lets a server ask the user for input or confirmation. The protocol deliberately says nothing about how the host uses its model or manages context; it only standardizes the exchange.
Why MCP Matters
Before a shared protocol, every AI application needed its own connector for every system, so integration work grew with each new pairing. With MCP, a team builds a server once and any compatible client can use it. The official documentation compares MCP to a USB-C port for AI applications for this reason.
Adoption spread beyond Anthropic. The protocol's documentation lists support in assistants such as Claude and ChatGPT and in development tools such as Visual Studio Code and Cursor. For product and engineering teams, this is what lets an AI coding agent read an issue tracker, query a database or pull a design file without bespoke glue code, and it is a practical building block of context engineering.
Connecting a server also extends what an agent can do, so trust matters. Teams should decide which servers to allow, what permissions each tool gets and which actions require user confirmation.
MCP Example
A product team connects its coding agent to two MCP servers: one for the issue tracker and a read-only server for the staging database. A developer asks the agent to implement a ticket. The host's clients have already listed both servers' tools. The model calls the tracker's tool to fetch the ticket, reads the database schema as a resource, writes the code, runs the tests and then calls the tracker again to post a summary on the ticket. The agent itself contains no tracker-specific or database-specific integration code.
MCP vs. Tool Calling
Tool calling is the model capability: given a list of tool definitions, the model returns a structured request to call one. MCP is the protocol for where those tools come from and how they are reached. In a typical setup the host collects tool definitions from its MCP servers, passes them to the model as tools, and routes the model's tool calls back through the right MCP client to the server that runs them. The two work together; neither replaces the other. Both are core plumbing for any AI agent that needs to act outside its own conversation.