MCP (Model Context Protocol) is an open protocol that standardizes how AI applications connect to external tools, data and prompts. It defines a common client-server interface so that one integration, written once as an MCP server, can be used by any compatible assistant or agent host, instead of every application building its own connector for every service.
For AI agents, MCP is the plumbing behind tool access. A model decides which action to take through tool calling, and MCP supplies the standardized description of the available tools, carries the call to the right system and returns the result. It was introduced in late 2024 as an open specification and has since been adopted by many model providers, development environments and software vendors.
How the Model Context Protocol works
MCP uses a host, client and server architecture. The host is the AI application the user works with, such as a chat assistant or an IDE. Inside the host, an MCP client maintains a one-to-one connection with each MCP server, and each server exposes the capabilities of one system, such as a file store, a database, a ticketing tool or a web API.
Messages follow JSON-RPC 2.0. A session begins with an initialization handshake in which client and server exchange protocol versions and declare their capabilities. The client then lists what the server offers, and the host decides what to show to the model and when to execute calls.
| Role | What it does | Typical example |
|---|---|---|
| Host | Runs the model, manages user consent and context | Desktop assistant, code editor, agent runtime |
| Client | Holds one connection to one server, speaks the protocol | Connector component inside the host |
| Server | Exposes tools, resources and prompts of one system | Wrapper around a database, repository or SaaS API |
| Model | Chooses which tools to call based on their descriptions | Language model with tool calling |
The key design point is that the model never talks to the server directly. The host mediates every call, which is where permissions, confirmations and logging are enforced.
Primitives exposed by MCP servers
An MCP server can offer three server-side primitives, each with a different controller. This separation matters because it decides who triggers an action: the model, the application or the user.
| Primitive | Controlled by | Purpose |
|---|---|---|
| Tools | Model | Executable functions with a name, description and JSON Schema input |
| Resources | Application | Readable data identified by URIs, such as files or records |
| Prompts | User | Reusable templates the user selects, often as slash commands |
Clients can also offer capabilities back to servers. Sampling lets a server request a model completion through the host, roots tell a server which directories or locations it may work in, and elicitation lets a server ask the user for missing input in a structured form. Servers can send notifications when their tool list or resources change.
Transports and deployment options
MCP separates the message format from the transport, so the same server logic can run locally or remotely. The choice of transport determines how the server is started, how it is authenticated and who can reach it.
| Transport | How it runs | Typical use |
|---|---|---|
| stdio | Host launches the server as a local process and talks over standard input and output | Local files, developer tools, desktop assistants |
| Streamable HTTP | Server runs as a web service; requests over HTTP POST, optional streaming of responses | Remote and multi-user services |
| HTTP with SSE (legacy) | Earlier remote transport using server-sent events | Older servers kept for compatibility |
Remote servers use OAuth 2.1-based authorization in the current specification, so a user grants a host access to a service without handing over raw credentials. Local stdio servers inherit the permissions of the user account that runs them, which makes careful installation essential.
MCP compared with related approaches
MCP does not replace tool calling or APIs; it standardizes the layer between them. Tool calling is the model’s ability to emit a structured request, while MCP defines how tools are discovered, described and executed across applications.
| Approach | Scope | Main limitation |
|---|---|---|
| Native tool calling | Model emits structured calls defined by one application | Each application defines its own tools |
| Direct API integration | Custom code for each service in each application | Integration effort grows with every pairing |
| Plugin systems | Vendor-specific extension formats | Locked to one platform |
| MCP | Shared protocol for tools, resources and prompts | Security depends on host and server quality |
The benefit is often described as turning an N times M integration problem into N plus M: each host implements the client once, and each service implements the server once. In a multi-agent system, MCP can give every agent the same consistent tool layer, while agent-to-agent coordination is handled by separate protocols.
Security risks and good practice
Because MCP gives models the ability to act, its main risks are unintended actions and data leakage. Tool descriptions and tool results enter the model’s context, so they can carry prompt injection that tries to redirect the agent.
- Tool poisoning: a malicious server hides instructions in a tool description.
- Over-broad permissions: a server with full account access lets one mistaken call cause wide damage.
- Confused deputy problems: a server acts with its own privileges on behalf of the wrong user.
- Untrusted local servers: installing an unknown package runs arbitrary code on the machine.
- Data exfiltration: content read through one server is sent out through another.
Sound practice is to install servers only from trusted sources, grant the minimum scopes needed, require human confirmation for destructive actions, log all tool calls and treat every tool result as untrusted data rather than as instructions.
The simple explanation
MCP works like a universal adapter for AI assistants. Before standard chargers, every phone needed its own cable. Before MCP, every AI app needed its own custom connection to each tool, such as a calendar, a database or a code repository.
With MCP, a tool is connected once in a standard way, and any assistant that speaks the protocol can use it. The assistant can then look things up or take actions in that tool, while the app in the middle checks what is allowed and asks you before anything important happens.
How it is used in practice
A support engineering team gives its coding assistant three MCP servers: one for the issue tracker, one for the source repository and one with read-only access to the production logs database. All three run with service accounts limited to the team’s projects.
When an engineer asks the assistant to investigate a reported checkout failure, the agent reads the ticket through the tracker server, queries the logs server for errors in the reported time window and opens the relevant source files through the repository server. It proposes a fix and drafts a comment on the ticket, but the host asks for confirmation before posting anything.
The investigation that previously required switching between three applications takes a single conversation. Because the same servers also work in the team’s chat assistant, the integrations were written once and reused across tools, and every call is recorded in the host’s audit log.