What is Model Context Protocol (MCP)? A plain-English explainer

TL;DR:

• MCP is an open standard from Anthropic that lets AI applications connect to tools, data, and services through a client-server model.
• It exists to standardise how models get context and call tools, replacing brittle one-off integrations with a single protocol.
• The architecture has hosts, clients, and servers, plus transports and three capability types: tools, resources, and prompts.
• It matters for security because servers can expose powerful tools, raising supply-chain, tool-poisoning, and over-scope risks.
• This article supports the guides library; pair it with MCP security best practices and least-privilege for AI agents.

What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools, data sources, and services through a client-server model. It defines a common language so a model can request context and invoke tools without bespoke integration code for every system. Before MCP, every connection between an AI app and an external system was a custom build; MCP turns that into one reusable protocol that any compliant host and server can share.

The standard was created and open-sourced by Anthropic, with the specification and reference implementations published at the Model Context Protocol site and described in the Anthropic documentation. A useful analogy: MCP is to AI integrations what USB-C is to hardware. One port, many peripherals, no custom cable per device.

Why does MCP exist?

MCP exists to standardise how large language models get context and call tools, so integrations stop being one-off engineering projects. The core problem it solves is the combinatorial explosion of custom connectors: without a standard, every AI app needs bespoke code for every data source, and every data source needs bespoke code for every AI app. That is slow to build and fragile to maintain.

By agreeing on one protocol, MCP lets the work be done once per server and reused across every compliant host. A team that builds an MCP server for its database can expose it to any MCP-aware assistant, IDE, or agent, rather than rewriting the connection for each.

How does MCP work?

MCP works through a client-server architecture where an AI host runs clients that connect to servers, each exposing specific capabilities. The host orchestrates the model; clients manage connections; servers wrap the actual tools and data. The table below breaks down the components.

Component	Role	Example
Host	The AI application the user interacts with; runs the model and manages clients.	A desktop assistant, an IDE, or an agent runtime.
Client	Lives inside the host and holds a one-to-one connection to a single server.	One client per connected server.
Server	An external program exposing capabilities to the host.	A filesystem server, a database server, a web-search server.
Transport	The channel carrying messages between client and server.	Local standard input/output, or remote HTTP-based streaming.
Tools	Functions the model can call to take action.	Send an email, run a query, create a file.
Resources	Read-only data the host can pull as context.	A document, a record, a log file.
Prompts	Reusable, parameterised prompt templates the server offers.	A “summarise this ticket” template.

In practice the flow is simple. The host starts a client, the client connects to a server over a transport, and the server advertises its tools, resources, and prompts. When the model decides to act, the host routes the tool call through the client to the server, which executes it and returns the result.

What are MCP servers?

An MCP server is a small program that exposes tools, resources, and prompts to an AI host over the protocol. Each server typically wraps one system, such as a filesystem, a database, a SaaS API, or a web browser. Servers can run locally as a child process of the host, or remotely as a networked service, and a single host can connect to many servers at once.

This modularity is the point. You compose an agent’s capabilities by attaching the servers it needs, and you remove a capability by detaching its server. It is also where security attention concentrates, because a server is the thing that actually holds the keys and performs the actions.

How does MCP compare to plugins and APIs?

MCP differs from plugins and traditional APIs by being a single open protocol rather than a collection of bespoke, per-vendor integrations. The shift is from many custom connections to one shared standard. The numbered list below captures the practical differences.

1. Reusability. A traditional API is integrated once per app with custom code. An MCP server is built once and reused by any compliant host.
2. Standardised capabilities. Plugins expose ad hoc functions. MCP defines three consistent capability types: tools, resources, and prompts.
3. Discovery. A normal API is documented externally and wired in by hand. An MCP server advertises its capabilities at connection time, so the host can discover them dynamically.
4. Portability. Plugin ecosystems are usually tied to one vendor’s platform. MCP is open, so servers and hosts from different vendors interoperate.

MCP does not replace APIs; servers often wrap existing APIs. It standardises the layer between the model and those APIs.

Why does MCP matter for security?

MCP matters for security because servers can expose powerful tools, and the model decides when to call them based on text it reads. A compromised or malicious server, or a benign server reached through a prompt injection, can turn into real-world actions like deleting data or exfiltrating secrets. The headline risks are worth naming.

• Supply-chain and trust. Installing a third-party server means running its code and granting it access. A poisoned or typo-squatted server is a direct foothold.
• Tool poisoning. A server’s tool descriptions are read by the model. A malicious description can smuggle hidden instructions that hijack the agent, a variant of prompt injection.
• Over-broad scopes. A server granted more permissions than it needs widens the blast radius of any single failure.
• Confused deputy. An agent with legitimate access can be tricked into using it on an attacker’s behalf.

These overlap directly with the OWASP LLM Top 10, particularly excessive agency and improper output handling, catalogued by the OWASP GenAI Security Project. The structural defence is least privilege plus a human gate: scope each server to the minimum it needs, vet servers before installing them, and require approval for irreversible actions.

Where to go next

Use the guides library as your starting point, then read MCP security best practices for the hardening checklist and least-privilege for AI agents for scoping discipline. To understand the attack class behind tool poisoning, see prompt injection explained, and browse the wider tools directory for related coverage.