What Is MCP? Model Context Protocol Explained

01 / The story

What is MCP in plain English?

Imagine asking an assistant to find a document in an approved business folder. The model does not automatically know your file system. The application needs a connection that can retrieve the document under your permissions. MCP is an open protocol for that connection between an AI application and a service exposing data or tools. [1]

MCP stands for Model Context Protocol. It is not a model, a database or an agent. It supplies a common integration boundary so developers do not have to describe every external capability in a completely unrelated format. It does not make every app compatible or grant permission to everything a server exposes.

This guide follows the official July 28, 2026 specification, identified as latest when checked October 22. Older tutorials can describe a different protocol revision. A working integration must agree on the actual revision and supported capabilities. [1] [2]

02 / The story

Host, client and server: who does what?

The host is the AI application managing the user experience and connections. The client is the connector within that host. The server exposes capabilities associated with a service or data source. Communication uses JSON-RPC messages. One host can connect to multiple servers; a server can wrap an existing API. [1]

The following diagram is conceptual. It shows responsibility boundaries, not a required physical deployment or a promise that every arrow is an internet connection. Local and remote servers differ.

User request
  → AI application / host
    → MCP client
      → MCP server
        → approved API, files or data source
Result returns through the connection; the host controls the user experience.

03 / The story

Resources, prompts and tools are different capabilities

Resources expose context or data. Prompts expose templated messages or workflows. Tools expose callable functions, such as a lookup or an operation in a connected application. A tool may read data or cause a real change, so the tool name alone does not establish its risk. [1]

An illustrative document server could offer an approved-folder resource and a search tool. A calendar integration could expose a lookup and a separately authorized event-creation tool. These are examples of possible designs, not verified support claims for every calendar or document product.

04 / The story

How a request works—and what changed in the latest revision

At a high level, the host receives the user’s task, uses its MCP client to discover or invoke supported capabilities, gets a result and decides how to present or use it. The surrounding application can use model function calling to choose a tool, but the model is not itself the entire protocol connection. [1]

The July 28 revision specifies stateless, self-contained requests and per-request capability negotiation. Its change log removes the earlier initialize/initialized handshake and carries protocol version and client capabilities in request metadata. Describing the old handshake as mandatory current behavior would mislead developers. [2]

Stateless protocol requests do not mean that every application has no memory or that a connected business operation has no lasting effect. A created calendar event still persists in the calendar. Distinguish communication rules from the state of the application behind them.

05 / The story

MCP versus APIs versus function calling

An API is a service interface. Function calling is a way for a model to request an application-defined function. MCP standardizes how the AI application discovers and interacts with external capabilities. A system can use all three: the model requests a function, the host invokes an MCP tool and the server calls an existing service API. [1]

MCP can reduce duplicated integration work when several hosts need the same capability format. A direct API connection may be simpler when one application needs one stable operation and the team already has a maintained integration. A common standard is useful, but adding another service boundary also adds something to operate and secure.

For background on service interfaces, see what APIs are. For an approved creative-software use case, read the separate GenFlick contribution through the Contributors directory; that contributed text is not a specification manual.

06 / The story

Local and remote servers require different checks

A local server may run as a process with access to local files or credentials. Installing it can therefore mean executing someone else’s code, not merely adding a link. Review the maintainer, package provenance, requested permissions and updates before running it. [5]

A remote server is another service boundary. Check transport security, identity, allowed scopes and where data goes. The specification’s OAuth-based authorization flow concerns HTTP transports; it is not a statement that every local STDIO server uses OAuth. Authorization is optional at the protocol level, but real access still needs appropriate controls. [3]

The meaningful question is “which actor is allowed to perform which action on which data?” Compatibility with MCP does not answer that question by itself.

07 / The story

What the authorization rules actually require

For the specified authorization flow, clients send the resource parameter and servers validate that tokens were issued for them. Token passthrough is forbidden. In plain terms, a connector should not accept a token for one service and casually reuse it at another. [3] [4]

Clients must use PKCE and check support, with S256 required when technically capable. PKCE helps bind an authorization exchange to the client that began it. Exact redirect checks, secure token storage and protected communications remain important parts of the implementation. [4]

Security guidance also covers untrusted discovery URLs, confused-deputy risks and server-side request forgery. A server-side request forgery risk arises when untrusted input causes a server to contact destinations it should not. Do not treat a tool description or returned document as new authority to ignore host policy. [5]

08 / The story

A safe first experiment

Choose a maintained integration, a compatible host and a non-sensitive sample source. Expose only a small approved folder or test account. Start with a lookup instead of a write action. Verify what the host shows before a tool call and what the server actually authorizes.

Ask how credentials are stored, what gets logged, whether updates change tools and how to revoke access. If the integration cannot explain those boundaries, postpone production use. Our computer-use agent security guide covers the wider containment problem.

MCP is valuable when it makes a connection easier to understand and maintain. It is not a universal compatibility adapter or a safety certificate. We reviewed the specification and guidance, not a live integration or every implementation.