What Is MCP? The Model Context Protocol in Plain Terms

Connecting an AI application to your files, a database and a ticket system used to mean three custom integrations, each written differently. MCP, the Model Context Protocol, is an attempt to make that one kind of connection instead.

MCP is an open protocol for connecting AI applications to external data sources and tools. The specification compares it to the Language Server Protocol, which did the same job for programming-language support in code editors: one way to plug things in, so each tool does not need a custom adapter for each application.

The three roles

Every MCP setup has the same three parts, and naming them is most of understanding it.

MCP messages are JSON-RPC 2.0, exchanged between hosts, clients and servers.

• The host is the AI application you are using: a chat app, an editor with an assistant, an agent runtime. It starts the connections.
• A client is the connector inside the host. The host runs one for each server it talks to.
• A server is a service that offers something: access to a file system, a database, an issue tracker.

So "installing an MCP server" means giving your host one more thing to connect to. The server can run on your machine or somewhere else.

What a server can offer

A server can offer three kinds of thing:

• Resources: context and data, such as files or records, for the user or the model to use.
• Prompts: templated messages and workflows a user can pick.
• Tools: functions the model can ask to run.

The traffic is not only one way. A server can ask the host for things too, for example asking the user for a missing piece of information.

Tools are the part that changes things in the world, and they work the way tool use always works: the model produces a request, and software decides whether it runs. MCP standardises how the host finds the tool and calls it. It does not make the decision.

What MCP leaves to you

The specification says MCP cannot enforce its security principles at the protocol level. It sets out what implementers should do: ask the user before any tool runs, ask before exposing user data to a server, and treat tools as what they are, a path to running arbitrary code. It also warns that a server's description of its own tools should be treated as untrusted unless the server is.

A standard way to connect a tool says nothing about whether calling that tool is a good idea. That judgement lives in the host: which servers it trusts, what each may reach, and what needs a person's yes.

Where that line should be drawn, and why a rule written into a prompt is not one of the bounds, is trust boundaries for tool execution. What happens between a request and its effect is from agent intent to governed execution.

What this changes

When someone proposes adding an MCP server, the protocol question is already answered. The questions left are the ones MCP hands back: what this server can reach, who said yes to that, and what the host checks before a tool runs.