What is the Model Context Protocol (MCP)? Hosts, clients, servers and what they can do

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems such as files, databases, search engines and business tools. Instead of every app writing a custom connector for every service, a service publishes one MCP server and any MCP-capable app can use it.

This explainer covers the parts, what a server can offer, how data moves, the security question and where governance now sits. All technical details come from the project's own documentation, and we date what can change.

The USB-C analogy, and what it leaves out

The MCP documentation says to think of it as "a USB-C port for AI applications." A single standard plug replaces a drawer of cables. That is accurate for integration: the documentation says the same server can work with clients including Claude, ChatGPT, Visual Studio Code and Cursor.

What the analogy hides is that a cable carries power, while MCP carries authority. A connected server can give a model the means to act, not only to read. MCP standardizes the connection, not the trustworthiness of what is on the other end.

The three participants

MCP uses a client-server architecture with three roles, per the architecture overview.

• Host. The AI application, such as Claude Code or Visual Studio Code, that coordinates one or more clients.
• Client. A component the host creates for each server; each client keeps a dedicated connection to its server.
• Server. A program that provides context to clients. "Server" describes the role, not the location: it can run locally or remotely.

The documentation's example: Visual Studio Code is a host. Connecting to Sentry's MCP server creates one client object. Connecting to a local filesystem server creates a second.

What a server can offer: tools, resources, prompts

MCP defines three core primitives that servers expose.

• Tools are executable functions an application can invoke, such as file operations, API calls and database queries.
• Resources are data sources that give context, such as file contents, database records and API responses.
• Prompts are reusable templates that structure interactions, such as system prompts and few-shot examples.

A database server, in the documentation's own example, could expose tools for querying, a resource holding the schema and a prompt with example interactions. Clients discover what exists with list methods and then call a tool with tools/call.

Servers can also ask the user for more input through a client feature called elicitation, which is useful for confirming an action. Per the documentation, two older client features, sampling and logging, are deprecated as of protocol version 2026-07-28.

How a connection works

MCP has two layers. The data layer uses JSON-RPC 2.0 messages to define discovery, tools, resources, prompts and notifications. The transport layer handles how messages travel.

• Stdio uses standard input and output between local processes on one machine, with no network overhead.
• Streamable HTTP uses HTTP POST with optional Server-Sent Events, supports remote servers and standard authentication such as bearer tokens, and MCP recommends OAuth for tokens.

The documentation calls the protocol stateless: every request carries the protocol version and capabilities it needs. Servers advertise what they support through a server/discover request. Change notifications are opt-in, and the documentation says delivery is best effort, so clients should also poll.

Where skills fit

MCP often gets confused with Agent Skills, a different standard. MCP connects an agent to live systems; a skill packages instructions and scripts the agent loads on demand. Both now live under the same foundation, as we covered in our report on Anthropic donating Agent Skills. For the surrounding machinery, see our explainer on the agent harness.

Who governs it

Anthropic created MCP and donated it to the Agentic AI Foundation, a Linux Foundation project co-founded with Block and OpenAI. The Linux Foundation says AAIF now hosts 10 projects, including Agent2Agent (A2A), AGENTS.md and goose. David Soria Parra of Anthropic is described as MCP's co-creator and lead maintainer.

The security question

A server is software that runs with the access you give it, and the model reads its tool descriptions as text. That means a malicious or sloppy server can cause harm even when the protocol works exactly as designed. The documentation has a security section with best practices, and its transport guidance recommends standard authentication. Practical rules:

• Install servers only from sources you trust, and read what tools they expose.
• Give each server the minimum access it needs, preferring read-only.
• Keep human approval on for actions that send, spend or delete.
• Prefer remote servers that use OAuth over long-lived keys pasted into config files.

What MCP is not

MCP does not decide how an app uses a model or manages context. The documentation states that it "focuses solely on the protocol for context exchange." It also does not make an agent safe, correct or cheap.

A quick example of the flow

Say you connect a code editor to a database server. The editor, as host, creates a client for that server. The client asks what the server supports, lists its tools, and shows the model a tool such as a query function. When the model chooses it, the host routes the call to the server, which runs the query and returns content for the model to use. At every step the host decides what the model may see and do, which is why approvals and permissions belong in the host, not in the protocol alone.

Our position

MCP won because it solved a boring problem well. Its governance by a neutral foundation lowers the risk of building on it. Its main risk is the one every integration layer has: more connections mean more places where something can go wrong. Adopt it for integration, and keep your permission model stricter than the protocol requires.