Model Context Protocol (MCP)
MCP lets an AI application discover and use information and tools supplied by another program—for example, a service that searches repository issues. The AI application is the host; it connects through an MCP client to an MCP server that exposes those capabilities. The versioned protocol defines how they exchange messages, discover available capabilities, and initialize a connection. It does not define what a business operation means, make the server trustworthy, or decide which actions the model may take.
Architecture
The host owns user interaction, model context, approval, and client orchestration. A client maintains one server connection. The server exposes a focused capability surface and may itself depend on another system.
Lifecycle and Capability Negotiation
A connection begins with initialization: client and server exchange protocol versions, implementation information, and declared capabilities. Normal operation follows only after initialization completes. Capability negotiation matters because optional features and revisions differ; “supports MCP” is not a sufficient compatibility test.
The common transports are local stdio and Streamable HTTP. Local does not mean harmless: a spawned server process inherits whatever filesystem, environment, and network authority the launcher grants. Remote transport adds origin, authentication, token, and network failure concerns.
Server Primitives
The protocol also includes notifications and optional capability families. Product support may cover only a subset.
Worked Boundary: Read-Only Issue Search
A focused server might expose search_issues(query, repository, limit) and return issue IDs, titles, URLs, and snippets. A safe host still needs to:
- restrict allowed repositories and maximum results;
- treat issue text as untrusted data;
- keep write tools disabled for a research task;
- show provenance and avoid placing huge results in context;
- require a separate approval path before commenting or closing an issue.
MCP makes the call discoverable; these controls remain application responsibilities.
Security failure modes and host controls
- Confused Deputy: The model or server uses the host's broad authority to execute unapproved side effects.
- Indirect Prompt Injection: Untrusted web or file payloads returned by tool calls contain instructions to trigger secondary destructive actions.
- Token Passthrough & Leakage: Credentials crossing transport boundaries without audience restriction or logging redaction.
- Scope Inflation: A convenient mega-server exposing overly broad write/delete tools.
A host can reduce these risks by treating server output as untrusted data, validating proposed tool arguments again before execution, granting each server only the credentials and paths it needs, and requiring approval for side effects chosen by local policy.
For local stdio servers, process isolation and a restricted environment can limit damage if the server is compromised. For remote Streamable HTTP servers, loopback binding is not a client-side control: use HTTPS, validate the server identity and origin, scope authorization tokens to the intended audience, and follow the protocol's authorization guidance. A server operated locally over HTTP may bind to loopback, but that is a different deployment case.
Stable schema ordering may improve prompt-cache reuse in some hosts, but it is a performance choice rather than an MCP security property.
MCP Versus Simpler Alternatives
MCP is an interoperability mechanism, not an architecture that every agentic system requires. Evaluate adoption against lifecycle complexity, runtime latency, transport security, and maintenance overhead.