Model Context Protocol (MCP)

Why Capabilities Need a Shared Protocol

An AI application can connect to a repository, ticket system, calendar, database, or internal API through a collection of custom adapters. That approach works for one host and a few integrations. It becomes expensive when every host builds a separate connector for every system.

The integration problem is not new. The caller is.

An AI host may need to discover available context, expose selected capabilities to a model, ask a server for more information, and carry the result back into a model-mediated workflow. Each application can implement those interactions independently, but the resulting ecosystem becomes a many-to-many collection of special cases.

The Model Context Protocol, or MCP, is an attempt to make that boundary shared.

MCP defines a common protocol for hosts, clients, and servers to exchange context and capabilities. It can standardize how a host discovers resources, prompts, and tools, how it invokes a tool, how a server returns a result, and how the two sides negotiate supported behavior.

It does not standardize the meaning of a customer, the eligibility for a refund, the authority of a record, or the permission to perform a business operation. Those remain application and domain responsibilities.

MCP makes integration more composable. It does not make integration automatically trustworthy.

This is Post 05 in The Abstraction Shift: How Software Keeps Moving Up.

Why This Exists

AI systems are useful when they can work with current information and external capabilities. A model trained on general data cannot know the current state of a private incident, the contents of a repository, the status of an account, or the rules in an internal procedure unless an application supplies that context.

The first generation of integrations usually looked like this:

one AI application;
one custom connector for each data source or service;
one provider-specific tool schema;
one set of authentication, consent, and error-handling assumptions;
one collection of code that had to be maintained as both sides changed.

That is manageable at small scale. It is less manageable when the same repository, data source, or business capability should be available to several AI hosts, or when one host should combine many focused services.

The pressure comes from both sides.

On the host side, a coding assistant, enterprise chat application, research workflow, and internal agent may all need access to related systems. Each host has a different user experience and control model, but they should not each build an entirely different integration stack.

On the server side, a data or capability owner may want to expose one integration to several hosts without writing a new adapter for each model provider or agent framework.

MCP addresses the repeated connection problem by introducing a shared protocol boundary. The host speaks MCP through a client. The server speaks MCP while retaining responsibility for its specialized resources and capabilities.

The name emphasizes context because context is broader than a tool call. An AI application may need a document, a database schema, a prompt template, a search result, a live subscription, or an executable operation. A protocol that handles only function invocation leaves much of the integration problem outside the contract.

The protocol therefore gives different kinds of interaction different names and control relationships. The details evolve, but the architectural question remains stable:

How can an AI application connect to external context and capability without rebuilding every integration from scratch or surrendering control to every connected server?

What We Did Before

MCP combines familiar ideas: direct APIs, plugin systems, service discovery, JSON-RPC, and the host/server separation popularized by the Language Server Protocol. Those patterns solved parts of the integration problem, but they did not make model-facing context and capabilities a shared contract.

MCP applies that ecosystem shape to AI hosts. The durable question is not whether every integration uses MCP. It is whether the host, connected server, and domain system have explicit boundaries for discovery, context, authority, and outcomes.

The host coordinates context and consent; each client connects it to a focused server.

What’s Actually New?

MCP is not the invention of remote calls, metadata, plugins, or service discovery. Its newness comes from composing those ideas around model-mediated applications and treating context exchange as a first-class protocol problem.

1. One host can assemble many context and capability providers

An MCP host can connect to multiple focused servers through multiple client instances. One server might expose a repository, another a ticket system, and another a deployment environment.

The host can combine their outputs into one user experience while preserving a separate connection and permission boundary for each server.

This is useful because the model’s task may cross system boundaries. It is risky because the host now has to decide which server sees which part of the task and which results may influence an action in another system.

2. The integration contract includes model-facing descriptions

An MCP tool is not only a method name and a request schema. Its description is intended to help a model and a host understand when the operation applies. Resources and prompts also carry metadata that affects discoverability and presentation.

That makes interface writing operational. A vague description can produce poor selection. An incomplete schema can generate ambiguous arguments. A confident annotation can make a consequential tool appear safer than it is.

The description belongs in the review and release process for the capability. It is not harmless documentation once it is placed in model context.

3. The protocol names different control models

MCP distinguishes three server-side primitives:

Prompts are user-controlled templates or workflows. A user may choose one through a menu, command, or other host interface.
Resources are application-controlled context and data. The host decides whether and how to attach or present them.
Tools are model-controlled functions that can retrieve information or perform actions.

The labels describe the intended interaction model. They do not replace authorization. A model-controlled tool still requires host and server policy. An application-controlled resource can still contain sensitive data. A user-controlled prompt can still embed unsafe instructions.

MCP separates prompts, resources, and tools by interaction model, but those labels do not grant permission to use an underlying business system.

4. The protocol carries interaction beyond a single tool call

A useful integration sometimes needs more information in the middle of an operation. A server may need the user to choose an option, provide a non-sensitive value, or complete an external authorization flow.

Current MCP specifications provide elicitation patterns for these cases. A server can ask the client to obtain structured user input or direct the user to an external URL for a sensitive interaction. The host retains control over presentation, consent, and what data is shared.

This matters because real integrations do not always fit a single request and response. Approval, missing information, and external authorization are part of the workflow.

The protocol can represent the interaction. It does not remove the need to make the interaction understandable and safe.

5. Protocol metadata becomes part of the control plane

MCP messages can carry protocol version, client capabilities, tracing data, and other metadata. The current 2026-07-28 specification uses self-contained requests at the protocol layer, which lets a server process each request without relying on hidden state from a previous connection.

That is a current protocol detail, not a timeless definition of MCP. Earlier deployed revisions used a session-oriented lifecycle, and optional extensions can add their own state or continuation model.

The durable idea is that a protocol should make compatibility and observability explicit. A server should not infer a caller’s capabilities from a connection that happens to remain open, and an operator should be able to trace a request across the host, client, server, and downstream capability.

Where the Analogy Breaks

MCP can be compared to LSP, plugins, USB-C, API gateways, or service discovery. Each comparison illuminates one part of the design. None of them describes the whole problem.

MCP is not universal semantic interoperability

Two systems can speak the same protocol and still disagree about what a field means. One server’s status may mean the last transport event. Another’s may mean the business lifecycle state. A resource URI can identify content without establishing its authority, freshness, or completeness.

MCP standardizes exchange. It does not create a universal enterprise ontology.

MCP is not an API gateway

An API gateway can route, authenticate, rate-limit, transform, and observe traffic. An MCP host or server may perform some similar functions, but the protocol itself does not become the enterprise gateway.

The host may decide which server is visible to a user or model. The server may enforce access to its own capabilities. A domain service may still own authorization, policy, validation, and outcome semantics.

There can be several control points, and their responsibilities need to be explicit.

Discovery is not trust

A server can advertise a tool, resource, or prompt. That advertisement tells the host what the server claims to provide. It does not prove that the server is safe, that its description is accurate, or that its output can be trusted as instructions.

Treat discovery metadata as input to a review and policy process. Do not treat it as a self-authenticating permission document.

Protocol authorization is not domain authorization

MCP can define an authorization flow for protected HTTP servers. That can establish whether a client may make requests to a server on behalf of a resource owner.

It does not answer every domain question. The server still needs to decide whether this user may read this account, whether this action is allowed in the current state, whether approval is required, and whether a downstream operation may run.

Transport-level identity and domain-level authority are related, but they are not the same decision.

A server is not automatically a safe plugin

Local MCP servers may run as processes launched by a host. Remote servers may receive sensitive context and return content that influences a model. Either form can be useful and either form can be dangerous.

The protocol does not make arbitrary code safe. A host needs an installation and trust model, process isolation where appropriate, network controls, data minimization, consent, logging, and a way to disable or revoke a server.

MCP does not replace direct integrations everywhere

A protocol is valuable when several hosts and servers need a shared integration boundary. A direct integration may still be simpler for a tightly coupled, high-volume, latency-sensitive, or highly regulated path.

The goal is not to put every internal call through MCP. The goal is to use a shared protocol where a model-mediated ecosystem benefits from composability and a common interaction contract.

MCP carries messages across a boundary; it does not make a description trustworthy, a request authorized, or an outcome complete.

Under the Hood

A useful MCP path keeps four responsibilities separate:

Host: chooses which servers and capabilities are visible, controls model context, and owns user consent.
Client: maintains the connection to one server and handles protocol messages and negotiated features.
Server: exposes focused prompts, resources, and tools, then enforces its own identity, scope, validation, and domain policy.
Capability: performs the underlying read or write and returns status, provenance, freshness, and error meaning.

Discovery makes capabilities available; it does not make them relevant or trusted. The host should filter catalogs by task and identity, and the server should validate every request independently. Tool descriptions and schemas are part of the runtime contract because they influence model selection and argument construction.

A write path should distinguish proposed, accepted, pending, completed, failed, and unknown states. The host must not turn a successful protocol response into a claim that the business operation completed.

The model proposes; host, server, and domain systems retain authority over execution and outcomes.

A Concrete Example

Consider an incident assistant for a payments platform. The user asks:

Find the customer-impacting payment incidents from today, summarize the evidence, and prepare an escalation for the on-call team.

The assistant needs current incident context and a controlled path to create an escalation. A single application could build direct integrations to the incident system, runbook repository, and notification service. An MCP-based host could connect to focused servers through a common protocol.

An incident server might expose:

a resource such as incident://today/customer-impacting;
a prompt such as triage_incident;
a read tool such as search_incident_events;
a consequential tool such as create_escalation.

A safe sequence could be:

The host enables the incident server for the user’s task and presents the available features.
The user selects the incident-triage prompt, or the host applies an approved workflow.
The host attaches the relevant resource or asks the server for a filtered view.
The model interprets the evidence and proposes a search for related events.
The MCP client sends the structured request to the incident server.
The server checks identity, scope, query limits, and data policy before reading the incident system.
The server returns events with source, time range, freshness, and any incomplete-data status.
The model prepares an escalation proposal, but does not send it yet.
The host shows the target team, incident scope, message, and expected effect to the user for approval.
After approval, the host invokes create_escalation through the server.
The server validates the target, authorization, idempotency key, and current incident state before calling the notification capability.
The result distinguishes sent, accepted for delivery, failed, and pending states.

MCP is helpful here because the host and server share a common way to describe context, tools, requests, results, and user interaction. It does not decide what counts as a customer-impacting incident or who may page the on-call team. Those are domain and governance decisions.

The same pattern can apply to compliance research, procurement, support, developer operations, or internal knowledge work. The systems behind the server change. The protocol boundary and authority questions remain.

Failure Modes

Misleading metadata

A vague description or incomplete schema causes poor selection or ambiguous arguments. Treat model-facing metadata as versioned, reviewed interface code.

Discovery mistaken for trust

A server can advertise a capability without proving that its output is authoritative or safe. Keep installation, identity, provenance, and policy separate from discovery.

Protocol success mistaken for business success

A valid request and response do not prove that a downstream state changed. Return explicit operation status and reconcile consequential outcomes with the source of truth.

Cross-boundary data leakage

A host may combine context from several servers without preserving tenant, purpose, or sensitivity boundaries. Filter context before transfer and enforce scope again at each server.

Untrusted results influencing control flow

Resources and tool results can contain instructions or misleading claims. Treat them as data, preserve provenance, and apply prompt-injection defenses before they influence a next action.

Version or ownership drift

Protocol revisions, extensions, and capability catalogs change. Version the contract, test supported features, and give every exposed capability a clear domain owner.

Sources

Introducing the Model Context Protocol, Anthropic: the original description of MCP’s integration problem and initial host, client, and server model.
Language Server Protocol: a primary reference for the host and specialized-server protocol analogy.
JSON-RPC 2.0 Specification: the message format and request, response, error, and notification foundation.
Model Context Protocol specification: the current authoritative protocol overview, primitives, security principles, and extensions.
MCP architecture: the host, client, server, isolation, and capability-negotiation model.
MCP base protocol: current message patterns, stateless requests, metadata, schema handling, and authorization scope.
MCP transports: the standard transport bindings and the separation between transport and protocol semantics.
MCP tools: tool discovery, model-controlled invocation, schemas, results, and human-interaction guidance.
MCP resources: application-controlled resources and context exchange.
MCP authorization: the HTTP authorization framework and its transport-level scope.
MCP elicitation: user input, consent, and sensitive external interaction patterns.