What Is the Model Context Protocol (MCP)?

The Model Context Protocol is a specification for how AI systems talk to the outside world. It standardizes the way a model or agent discovers and invokes external capabilities — reading a file, querying a database, calling an API — so the connection looks the same regardless of which model or which tool is involved.

The common analogy is a universal port. Before USB, every device needed its own connector; afterward, one standard worked everywhere. MCP aims to do the same for AI integrations: build a capability once as an MCP server, and any MCP-aware client can use it without custom glue code.

At run time the flow is short. The AI application connects to one or more MCP servers, asks each one what it offers, and hands the resulting tool descriptions to the model. When the model decides to use a tool, the application routes the call to the right server, receives the result and adds it to the model’s context. Servers can offer readable resources and reusable prompt templates alongside their tools.

Because the interface is standardized, the model does not need to know the internals of each integration. It asks the server what tools exist and calls them through the protocol. This is closely related to tool use and function calling — MCP is, in effect, a standard transport and discovery layer for tools.

An MCP server is a program that exposes capabilities to AI applications through the Model Context Protocol. According to the specification, it can offer any mix of three primitives: tools, functions the model may ask to run; resources, data and context for the user or model to read; and prompts, templated messages and workflows. A repository server, for instance, might publish “create issue” as a tool and a README file as a resource.

The specification names three roles. The host is the AI application the person works in, such as a chat app, an IDE or an agent, and it enforces consent and security policy. Inside the host, each client is a connector that talks to exactly one server. The server provides a focused set of capabilities and, by design, should not be able to read the whole conversation or see into other servers; the host controls anything that passes between them (MCP architecture). A server can be a local process or a remote service.

Two standard transports carry the JSON-RPC 2.0 messages. With stdio, the client launches the server as a subprocess and exchanges newline-delimited messages over standard input and output, which suits tools on the same machine. With Streamable HTTP, each message is an HTTP POST to a single MCP endpoint and replies arrive as a JSON object or a request-scoped server-sent-events stream, which suits shared and remote servers (transport spec). The revision current in September 2026, dated 2026-07-28, also makes the protocol stateless: every request carries its own protocol version and client capabilities.

Authorization is optional in MCP but specified in detail for HTTP transports. A protected server acts as an OAuth 2.1 resource server, must publish OAuth Protected Resource Metadata (RFC 9728) so clients can find its authorization server, and must accept only access tokens issued with it as the audience, never accepting or passing through tokens meant for anything else. A server on stdio should take its credentials from the environment instead (authorization spec). None of this decides which agent may call which tool. That policy is left to the host and to the organization running it.

The canonical documentation lives at modelcontextprotocol.io: the dated specification revisions, the architecture and security pages, and guides for building servers and clients. When a tutorial and the specification disagree, the specification wins, so check which revision a server claims to implement before relying on a feature.

The modelcontextprotocol/servers repository holds a small set of reference servers maintained by the MCP steering group: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time. Its README states that they are educational reference implementations rather than production-ready solutions, and it sends readers looking for other servers to the official MCP Registry, which lists published servers and their versions.

Many vendors now maintain their own servers. GitHub’s github-mcp-server can be used as a GitHub-hosted remote endpoint or run locally in Docker, signs in with OAuth or a personal access token, and supports toolset selection and a read-only mode. Microsoft keeps a catalog of its official MCP servers spanning Azure, Microsoft Learn, Microsoft 365, Fabric, SQL and security products. The enterprise MCP server roundup compares the servers teams ask about most (verified September 2026).

Before connecting any server, read its documentation for three things: which tools can write or delete, how it authenticates and where tokens are stored, and whether it can run inside your own network. A server that exists only as a vendor-hosted endpoint sends every tool call, and the data in it, to that vendor. The MCP gateway page explains how to register and restrict servers centrally.

Before standards like MCP, every model-to-tool connection was bespoke: N models times M tools meant a combinatorial explosion of custom integrations, each maintained separately. MCP collapses that to N + M — build each server and client once against the protocol.

The payoff is portability and reuse. Tools built for one agent work with another; swapping the underlying model does not break integrations; and an ecosystem of shared MCP servers reduces the work of connecting AI to real systems. For agent builders, it means less plumbing and more time on actual behavior.

MCP standardizes connection, not control. An MCP server can expose powerful actions — and a manipulated agent that can reach it could do real damage. So in enterprise settings, MCP must be wrapped in authentication, least-privilege permissions, input validation, and audit logging on every server.

The deployment question also matters: connecting agents to internal systems via MCP means those connections, and the data flowing through them, should stay inside controlled infrastructure. MCP is a powerful enabler, but the responsibility for who can call what — and proving it afterward — sits with the platform around it.

MCP turns N×M bespoke connectors into reusable, standardized servers and clients.