Model Context Protocol explained: how AI connects to tools without making everything a plugin

Reviewed September 30, 2026. Protocol details refer to the final MCP specification revision dated July 28, 2026. Implementations may also support older revisions.

An AI model can write a plausible answer using the text already in its context. To inspect a repository, query a database, read a calendar, or update a ticket, the application around the model needs a controlled way to expose those capabilities. Model Context Protocol, usually shortened to MCP, defines a common interface for that connection.

The useful comparison is not “MCP is a USB port for AI,” because the metaphor hides the parts that matter. MCP is a protocol: it defines roles, message shapes, capability discovery, and the way a client calls a server. Authentication, authorization, approval, data governance, and whether a tool is safe remain application responsibilities.

The architecture: host, client, and server

Host application
Runs the model and policy→MCP client
Speaks the protocol⇄MCP server
Offers capabilities→External system
Files, APIs, or data

• Host: the AI application the user interacts with. It decides how model output, permissions, approvals, and server results are handled.
• Client: the protocol component inside the host. It discovers server capabilities, sends structured requests, and receives results.
• Server: a program that exposes a bounded set of capabilities. A server may run locally beside the client or remotely behind HTTPS.

This separation matters. The server does not become the model, and the model does not receive unrestricted access to the system behind a server. A well-designed host mediates the relationship.

Tools, resources, and prompts are different primitives

The MCP documentation describes three foundational server features. Their names sound similar, but they imply different control and risk.

A tool is not automatically dangerous, but it can cause an effect. “Read invoice” and “pay invoice” should not be bundled into one vague function. Resources also need boundaries: reading a selected project folder is different from indexing an entire home directory.

What happens during a tool call?

1. The host gives the model a description and input schema for allowed tools.
2. The model proposes a tool name and structured arguments.
3. The host validates the proposal against policy, user intent, and the schema.
4. The client sends the MCP request to the selected server.
5. The server authenticates the caller where required, performs the bounded operation, and returns content or structured data.
6. The host decides what result enters model context and whether another action is permitted.

Local and remote servers have different trust boundaries

“Local” does not mean harmless. Installing a local server means running code. “Remote” does not mean insecure, but it introduces a network and provider boundary. Before connecting either type, identify its publisher, requested permissions, data destinations, and revocation path.

What changed in the July 2026 specification?

The final 2026-07-28 revision made the core protocol stateless. Requests are self-describing, and a client can optionally call server/discover to learn capabilities. The release also added header-based routing, cache hints for list responses, an extensions framework, and authorization hardening. Long-running Tasks became an extension rather than an experimental core feature.

Stateless at the protocol layer does not mean an application cannot keep state. The maintainers recommend explicit state handles when a workflow must continue across calls. That makes the state visible in the operation rather than hiding it in a transport session.

The same release deprecated several older mechanisms with a minimum transition window. This is why integrations should negotiate or declare protocol revisions instead of assuming that every MCP server speaks the same era.

Security questions to ask before enabling a server

1. What is the smallest useful permission? Prefer read-only scope first, narrow directories, and separate tools for separate effects.
2. What information reaches the server? Tool arguments and attached context may contain more than the final visible answer.
3. Can external content steer the model? A document or webpage may contain hostile instructions. Treat retrieved content as untrusted data, not authority.
4. Which actions require confirmation? Confirm at the moment of a consequential action, showing the target and final parameters.
5. Can access be revoked and audited? Tokens need a lifecycle; tool calls need useful logs that avoid leaking secrets.

For OAuth-based remote access, the 2026 specification hardened issuer validation and credential isolation. Those mechanisms protect the authorization flow, but they do not replace application-level checks on what each tool may do.

When MCP is useful—and when it is unnecessary

MCP is useful when several AI hosts should connect to the same capability, or when one host needs a consistent way to connect to many services. A well-described server can reduce custom integration work and make its tools discoverable.

It may be unnecessary when a fixed application owns one stable API call. A direct function can be simpler, easier to test, and easier to secure. Protocol adoption should solve an interoperability problem, not add a layer merely because the word “agent” appears in the project.

A practical evaluation checklist

MCP makes a connection interoperable. A trustworthy system still comes from narrow capabilities, clear schemas, disciplined authorization, adversarial testing, and visible user control.