What Is MCP? Model Context Protocol Explained

The problem MCP solves

Every AI application invents its own way of connecting a model to the outside world. One team writes function-calling schemas by hand. Another builds a bespoke plugin loader. A third hardcodes a list of API endpoints into a prompt template. All three end up doing the same job badly, and none of them can reuse the other's integrations.

MCP — the Model Context Protocol — is an attempt to make that layer standard. The idea is the same one that made HTTP work: agree on a wire format once, and then anyone can build for it.

The three layers

Hosts are the applications people actually use — a chat client, an IDE, an agent runtime. The host owns the conversation and decides which servers to connect to.

Clients live inside the host. There is exactly one client per server connection. Its whole job is to speak MCP on behalf of the host, which keeps protocol handling out of the host's own code.

Servers are the processes that expose capability. A server might wrap a database, a ticket system, or a company's internal API. Each server is independent, and the model can connect to several at once.

That separation is the interesting part. A server does not need to know which host is talking to it, and a host does not need to know how any particular server works internally.

Why not just use an API

APIs are not going away and MCP does not replace them. The difference is that an API is designed for a program that knows exactly what it wants, while MCP is designed for a model that has to discover what is available and decide what to use at runtime.

An MCP server wraps existing APIs rather than replacing them. The server is a thin layer that describes the capability in a form a model can reason about, and the underlying HTTP call still happens the way it always did.

Resources and prompts

Beyond tools, MCP defines two more primitives. Resources are data the server can expose, closer to reading a file than calling a function. Prompts are reusable templates a server offers, which lets a domain-specific server contribute the phrasing that works well for its own domain.

A server that only exposes tools is still useful, but one that exposes all three gives a model much more to work with.

Transport and security

The two common transports are stdio, where the client launches the server as a subprocess and talks over pipes, and HTTP-based transports for servers running as network services. stdio suits local tools; HTTP suits shared or remote ones.

Security deserves real attention. A server can be given access to files or internal systems, so trust boundaries have to be explicit. A user should be able to see which servers are connected and what they can reach, and the host should require confirmation before a tool call touches anything destructive. An MCP server is effectively a privilege grant, and treating it lightly is how prompt-injection problems get access to your filesystem.

Where it fits

If you are building an assistant, MCP replaces your hand-rolled tool registry. If you are building a capability that many assistants could use, MCP gets you into every host that supports it without asking each one for a custom integration. If you already have a working API integration, MCP is worth adopting once you need a second host or want the tools discoverable by models rather than hardcoded.

Go deeper

• Get hands-on with the MCP course.
• Understand what makes an AI agent different from a scripted flow.