Wiki · Concept · Last reviewed June 16, 2026

Model Context Protocol

Model Context Protocol, or MCP, is an open protocol for connecting LLM applications to external tools, data sources, prompts, and contextual resources through a standard host-client-server interface.

Category: Concept Published: June 16, 2026 Modified: June 16, 2026 Last reviewed: June 16, 2026 Tags: MCP, AI Agents, Tool Use, Authorization, Prompt Injection, Agent Governance

Snapshot

Definition

Model Context Protocol is a standardized way for LLM applications to exchange context and capabilities with external systems. Anthropic's launch post framed the problem as fragmentation: every assistant otherwise needs custom connectors for content repositories, business tools, development environments, and other systems where useful data lives.

MCP is therefore best understood as an integration layer. An MCP host such as an assistant, coding environment, or agent runtime creates MCP clients. Each client maintains a connection to an MCP server. The server exposes capabilities such as resources to read, prompts to select, and tools to call.

The protocol does not decide whether a model's answer is true, whether a tool should be trusted, or whether an institution should permit an action. It gives applications a common interface for connection. Authorization, provenance, human approval, logging, and data governance remain deployment responsibilities.

Architecture

Hosts are the LLM applications that initiate and coordinate connections. The official architecture page describes the host as the container that creates and manages client instances, enforces security policies and consent requirements, handles user authorization decisions, coordinates LLM integration, and aggregates context.

Clients are connectors inside the host. Each client maintains one stateful session with one server, handles protocol negotiation and capability exchange, routes messages, and helps preserve security boundaries between servers.

Servers provide specialized context and capabilities. A server can run locally as a subprocess or remotely as a service, and can expose access to files, databases, APIs, search systems, code repositories, enterprise systems, or narrow workflows.

Resources, prompts, and tools are the main server features. Resources expose contextual data identified by URIs. Prompts expose reusable prompt templates or workflows for user selection. Tools expose callable functions that a model may invoke, such as querying a database, calling an API, or performing computation.

Roots, sampling, and elicitation are client features. Roots define filesystem or URI boundaries a server may operate within. Sampling lets a server request an LLM generation through the client without holding its own model API key. Elicitation lets a server request additional user input through the client, with URL mode reserved for sensitive interactions such as passwords, API keys, access tokens, or payment credentials.

Transports in the 2025-11-25 specification are stdio and Streamable HTTP. Stdio launches the server as a local subprocess and exchanges newline-delimited JSON-RPC messages. Streamable HTTP uses HTTP POST and GET against an MCP endpoint, optionally with Server-Sent Events. The spec says Streamable HTTP replaces the older HTTP+SSE transport from the 2024-11-05 version.

Authorization is optional in the protocol, but HTTP-based implementations that support it should follow the authorization specification. The 2025-11-25 authorization spec builds on OAuth 2.1-related work, protected resource metadata, authorization-server metadata, OpenID Connect discovery, dynamic client registration, client ID metadata documents, PKCE, token audience binding, and step-up authorization for insufficient scopes.

Current Context

As of June 16, 2026, MCP has moved from an Anthropic-originated open-source project into a cross-vendor integration surface. The official repository remains the specification and documentation home, while the 2025-11-25 specification and changelog show active protocol governance, authorization, SDK tiering, and working-group process work.

Major platforms now document MCP support in different ways. Microsoft announced MCP support in Copilot Studio on March 19, 2025 and describes it as a way to bring external data and APIs into agents while using connector infrastructure, data-loss-prevention controls, authentication methods, and other enterprise governance controls. GitHub documentation describes MCP across GitHub Copilot surfaces and identifies a GitHub-provided MCP server. OpenAI documentation describes remote MCP servers for ChatGPT Apps, deep research, and API integrations, and its API docs distinguish OpenAI-maintained connectors from arbitrary remote MCP servers.

Security guidance has also become more explicit. The MCP security best-practices page covers confused-deputy attacks, token passthrough, server-side request forgery, session hijacking, local MCP server compromise, and scope minimization. OWASP's MCP Top 10 frames MCP-enabled systems as a distinct security lifecycle with risks including token mismanagement, scope creep, tool poisoning, software supply-chain attacks, lack of audit and telemetry, shadow MCP servers, and context injection or over-sharing. NIST's 2026 AI-agent standards work and NCCoE concept paper place agent identity and authorization in a broader standards context.

Boundary With Adjacent Patterns

Function calling lets an application expose typed functions to a model. MCP can carry tool definitions across a client-server protocol, but it does not replace a host's tool policy, approval UI, or runtime enforcement.

Retrieval-augmented generation is a design pattern for grounding answers in retrieved information. MCP can expose resources or search/fetch tools used by a retrieval system, but it does not by itself rank sources, verify claims, or solve citation discipline.

Agent2Agent Protocol focuses on collaboration between agentic systems. MCP is narrower: it connects a host application to tools, data, prompts, and resources. A system may use both, but a tool server and a peer agent are different trust objects.

Connectors, plugins, and app stores are product or marketplace layers. An MCP server can be distributed through one of those layers, but protocol compliance is not a security review, endorsement, or license to grant broad authority.

Why It Matters

MCP turns context into infrastructure. It gives agent systems a standard way to reach outside the chat window and interact with the world of documents, services, permissions, and operational data.

That changes the practical meaning of AI deployment. A model without external context mostly answers from its training and conversation state. A model connected through MCP can retrieve current internal knowledge, call real tools, inspect repositories, query systems, and execute actions that affect live workflows.

MCP also changes institutional dependency. Once organizations expose knowledge and operations through MCP servers, AI systems become part of the access layer. The protocol is not just a developer convenience; it is a doorway between model behavior and institutional reality.

Risk Pattern

Tool poisoning. Tool names, descriptions, annotations, schemas, prompts, and outputs become model-facing context. A malicious or compromised server can present instructions that influence what the agent believes it is allowed or expected to do.

Prompt injection. MCP lets agents read untrusted content from files, websites, tickets, repositories, and internal systems. If the client does not separate data from authority, hostile text can attempt to redirect the model.

Confused deputy failures. The official MCP security guidance warns about proxy patterns where a server acting for a user can be tricked into granting or forwarding authority in ways the user did not intend. This is an authorization design problem, not a model-quality problem.

Token and scope risk. Broad credentials create broad blast radius. The authorization specification warns that stolen tokens can let attackers access protected resources as if requests were legitimate, and the security guidance treats over-broad scopes as a recurring failure mode.

Local server compromise. Local MCP servers can bridge a model to a user's machine, files, credentials, browser session, or developer environment. The official security guidance warns that local servers may execute commands with the same privileges as the client unless sandboxing and consent are enforced.

Remote server trust. Remote MCP servers can see data sent to them, return tool output into the model's context, and in some deployments perform write actions. A trusted model connected to an untrusted server is still an untrusted system.

Shadow servers and supply chain drift. Teams can add servers outside central review, tool behavior can change after approval, and package or registry dependencies can drift. OWASP's MCP Top 10 treats shadow MCP servers, dependency tampering, weak audit, and tool poisoning as explicit risk categories.

False standard comfort. A common protocol can make an integration feel safe because it is standardized. Standardization improves interoperability; it does not automatically solve authorization, provenance, data labeling, prompt injection, or human approval.

Governance Requirements

Governed MCP deployments should treat each server as a privileged integration, not as harmless context. The first control is inventory: server name, publisher, version, source repository, transport, deployment owner, data classes exposed, tools enabled, write capability, scopes requested, downstream APIs, and incident contact.

Least privilege should be the default. Expose only the tools and resources needed for a defined task, split read-only and write-capable tools, use narrow and short-lived credentials, avoid wildcard scopes, support revocation, and require step-up authorization for higher-risk actions.

Clients need visible approval boundaries. OpenAI's API documentation says MCP tool calls default to approval before data is shared with a connector or remote MCP server, and recommends reviewing and logging data shared with third-party MCP servers. That pattern should generalize: users and institutions should see which server is receiving data and which tool call is being approved.

Local servers need execution controls. One-click installation should show the exact command and arguments, identify that code will run on the user's system, require explicit consent, warn on dangerous command patterns, and sandbox file-system, network, and process access where possible.

Remote servers need identity and transport controls. HTTP deployments should use HTTPS, token audience validation, PKCE where required, protected-resource metadata, precise redirect URI validation, and server-side authorization checks. Session IDs should not become authentication; every inbound request still needs authorization verification.

Registries and marketplaces need provenance discipline. A server should be identifiable, versioned, reviewable, and auditable. Tool descriptions, prompts, manifests, dependency locks, and server endpoints should be treated as supply-chain artifacts because changes to them can steer model behavior.

Logs should preserve the chain: user intent, host, client, server identity, server version, tools listed, tools allowed, resource reads, prompt templates selected, approvals, arguments, returned data, errors, model-visible outputs, and final action. Without that trace, incident review becomes guesswork.

Source Discipline

Claims about MCP should name the protocol version. The 2024-11-05, 2025-06-18, and 2025-11-25 specifications differ in transports, authorization, client features, and governance details, so undated summaries can become misleading quickly.

Separate protocol claims from product claims. The MCP specification defines interoperability requirements; a vendor documentation page describes that vendor's implementation, approval UI, supported transports, connectors, or server marketplace. Neither one proves the other.

Separate server trust from protocol support. A server can be MCP-compatible and still be malicious, overbroad, stale, unmaintained, or inappropriate for a regulated workflow. Strong sources for this topic are official specifications, official platform docs, regulator or standards-body guidance, security advisories, reproducible research, and repository release notes.

Spiralist Reading

MCP is plumbing for the Mirror.

It turns the agent from a conversational surface into a participant in institutional systems. The model can ask the archive, call the calendar, inspect the codebase, query the customer record, search the memory store, and return with an answer shaped by live context.

That is powerful and dangerous for the same reason. MCP makes AI less isolated, but it also gives machine mediation a clearer path into the places where organizations store memory and authorize action. The question is not whether context should be connected. The question is who controls the connection, what the model is allowed to treat as authority, and whether humans can still see the boundary.

Open Questions

Sources

Return to Wiki