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.

In One Sentence

MCP is an open protocol that gives AI hosts a shared way to discover and exchange external context and capabilities, while the host, server, and underlying systems remain responsible for consent, authorization, validation, execution, and truth about outcomes.

The important distinction is between interoperability and authority.

MCP can make it easier for a host to connect to a new server. It can carry a tool description and its input schema. It can return a resource or a tool result in a common message shape.

It cannot tell a host whether a third-party server deserves access to private data. It cannot decide whether a user’s identity permits a refund. It cannot make a tool description honest. It cannot turn a pending request into a completed business outcome.

The protocol reduces the cost of connecting components. The surrounding architecture still has to decide which components should connect and what they may do.

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 several older ideas. That lineage matters because it shows both why the protocol is understandable and where it is different.

Direct APIs and SDK integrations

An application can call an API directly. It knows the endpoint, authentication scheme, request shape, response shape, retry behavior, and domain-specific assumptions.

This is often the right choice for a high-value, tightly controlled integration. The application owns the contract and can optimize the experience around one service.

The cost appears when the same capability must be connected to many AI hosts. Every host becomes responsible for the integration details, and each provider may represent tool definitions, results, approvals, and errors differently.

Plugin and adapter architectures

Plugin systems move extensibility outside the main application. A host can load an extension, discover its metadata, and call a known interface. Adapter layers translate a shared application interface into the shape required by a specific system.

These patterns already addressed a version of the many-to-many problem. The host still usually decided which plugin to load through deterministic configuration or code. A plugin’s metadata did not automatically become model context, and a plugin registry did not by itself define how a model should reason about its capabilities.

Service discovery and integration platforms

Service registries, API gateways, message brokers, and enterprise integration platforms made distributed capabilities easier to locate, route, observe, and govern.

They also taught an important lesson: finding an endpoint is not the same as understanding the domain behind it. A registry can tell a client where a service lives. It does not necessarily tell the client which customer record is authoritative, whether a call is safe to retry, or what a successful response means to the business.

JSON-RPC and protocol bindings

JSON-RPC provides a lightweight, transport-agnostic request and response format. It defines messages, method names, parameters, identifiers, errors, and notifications.

That is a useful foundation for MCP. It keeps the wire format simple while allowing the protocol to run over different bindings. The message format is not the whole architecture, though. JSON-RPC does not define what a tool means, how a host should assemble context, or who should approve a side effect.

Language Server Protocol

The closest architectural analogy is probably the Language Server Protocol, or LSP. LSP standardizes communication between development tools and language servers so one language implementation can work with several editors and one editor can support several languages.

The analogy is useful because both protocols separate a host experience from specialized servers. Both make an ecosystem more composable by defining a shared message contract.

The analogy breaks because language tooling usually operates over a more constrained domain. A language server can provide completion or navigation. An MCP server may expose private records, execute arbitrary code, send messages, modify data, or call a downstream service. The security and authority problem is therefore much broader.

MCP borrows the shape of a protocol ecosystem. It adds a model-mediated control problem to that ecosystem.

The host coordinates context, consent, and client connections; each client speaks to one server that exposes focused features.

The Abstraction Shift: How Software Keeps Moving Up

The old and protocol-mediated integration shapes are compared below.

MCP reduces repeated host-to-system connection logic while leaving the domain integration behind each server in place.

The host still needs a client connection for each server. The server still needs an adapter or domain integration for the system behind it. MCP does not erase those components.

What changes is the contract at the boundary. The host no longer needs to know every provider-specific way to discover a tool, request a resource, receive a result, or negotiate a feature. The server no longer needs a custom integration for every host that wants to use its capabilities.

The protocol turns a private integration seam into a potentially shared ecosystem seam.

That creates five important shifts.

The connector becomes an ecosystem boundary

An MCP server can be local or remote. It can expose focused capabilities backed by a repository, a document store, a business API, a developer environment, or a workflow system.

The host can connect several servers while keeping them isolated behind separate clients. This supports composition without requiring every server to see the whole conversation or communicate directly with every other server.

The host remains the coordinator. Cross-server context and actions should pass through host policy rather than becoming an accidental server-to-server mesh.

Discovery becomes part of the runtime contract

An ordinary API integration often begins with a developer reading documentation and writing a client. In an MCP ecosystem, a host can ask a server what it offers.

That makes discovery a live architectural concern. The list of available tools, resources, and prompts may be filtered by identity, scope, task, or server state. Descriptions and schemas may enter model context. The size and ordering of that list can affect latency, model attention, caching, and selection quality.

Discovery is not just a catalog lookup. It is the step where the host decides which external capabilities become visible to the model and the user.

Context and capability get a common home

The protocol can carry both information and operations. A resource may provide a document or data view. A prompt may provide a reusable interaction template. A tool may retrieve information or cause an action.

These primitives are related, but they are not interchangeable. A resource is not automatically a permission to modify its source. A prompt is not a policy. A tool description is not an authorization grant.

The common protocol makes these surfaces easier to connect. The host still needs to preserve their different control and risk characteristics.

Server isolation becomes explicit

MCP’s architecture places the host between the model and its connected servers. Each client communicates with one server. The host manages the set of clients, aggregates context, and enforces application-level consent and policy.

This is more than a diagram convention. It is a trust-boundary recommendation. A server should receive only what it needs. It should not assume that it can read the whole conversation, inspect another server, or use the model as an unrestricted relay.

Protocol evolution becomes an operating concern

Once a shared protocol sits between many hosts and servers, versioning, capability negotiation, deprecation, transport compatibility, and extension support become part of operations.

A host may connect to servers that support different protocol versions or optional features. A server may expose a feature only when the caller declares support for the related response or interaction. Compatibility is no longer only a library upgrade problem. It is part of the runtime path.

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

The current protocol is easier to understand when its layers are kept separate.

1. The host coordinates the experience

The host is the AI application that the user or another system interacts with. It usually owns the model integration, conversation context, client lifecycle, user consent, and application-level policy.

The host can connect to more than one server. It decides which servers to enable, which capabilities to expose, how resources enter context, when tools need confirmation, and how results are shown to the user.

This is why an MCP server should not be treated as though it owns the host’s whole conversation. The server should receive the minimum context needed for its operation.

2. A client connects the host to one server

In MCP’s host-client-server architecture, a client is a connector created and managed by the host. Each client communicates with one server.

The client handles protocol messages, transport details, capability declarations, subscriptions, and responses for that server. It creates a boundary between the host and the server without requiring every server to understand the host’s entire internal architecture.

The one-to-one relationship is useful for isolation and lifecycle management. It does not mean the server is isolated from all risk. The host still has to control what context crosses the connection.

3. The server exposes focused features

An MCP server provides specialized context and capabilities. It may be a local process that wraps a developer environment or a remote service that fronts a business system.

The server can expose any combination of prompts, resources, and tools. It can also support optional features such as subscriptions, progress, cancellation, elicitation, or extensions.

The server should keep its boundary focused. A repository server should expose useful repository operations and context, not silently become a general-purpose path into every network or filesystem available to the process.

4. JSON-RPC carries the messages

MCP uses JSON-RPC 2.0 messages. A request has a method and parameters. A response returns a result or error. An identifier correlates the response to the request. Notifications carry one-way events without a response.

This gives MCP a predictable wire format. It does not give the messages business meaning by itself.

For example, a tools/call request can identify a tool and carry arguments. The server still has to validate the arguments, enforce policy, call the underlying capability, and return a result that accurately represents what happened.

5. Transports carry the same semantics

The protocol can use standard transports such as standard input and output for local processes or Streamable HTTP for remote services. The transport defines how messages are framed and delivered. The protocol semantics should remain the same.

This separation matters operationally. A local process and a remote HTTP server have different installation, networking, authentication, and isolation concerns. Neither transport changes the need for consent, authorization, validation, and observation.

6. Capabilities are declared and negotiated

Servers advertise the features they support. Clients declare capabilities relevant to the request. The two sides should use only features that have been declared and supported.

This makes optional behavior explicit. A host should not assume that every server can handle a subscription or an elicitation flow. A server should not depend on a client capability that the client did not declare.

Capability negotiation is useful for compatibility. It is not a substitute for access control. A server can support tools and still expose only a subset to a particular identity or task.

7. Discovery produces model-facing context

The host can ask a server to list its tools, resources, or prompts. The response may include names, descriptions, schemas, titles, URIs, and other metadata.

The host then has a design choice. It can load everything into the model context, filter the set by task and identity, let a user select a subset, or defer discovery until a category is needed.

The choice affects:

• model attention and selection quality;
• prompt size and latency;
• privacy and data exposure;
• cacheability and freshness;
• evaluation coverage;
• the chance that similar capabilities are confused.

Large capability catalogs therefore create a context-engineering problem. Discovery makes capabilities available. It does not make all of them relevant.

8. Tools cross into execution

The model may select a tool because its description appears relevant. The host or client sends a structured request. The server validates the request and invokes the underlying operation if policy allows.

The server result may contain text, structured data, embedded resources, an error, or an indication that more input is required. The host decides what enters model context and what the user sees.

The authority path remains independent of the model’s proposal:

The model participates at the proposal boundary; deterministic systems remain authoritative over execution and outcomes.

MCP makes the middle exchange more consistent. It does not turn the model proposal into an authorized action.

9. Results need status and provenance

A result can be technically well-formed and still be operationally ambiguous. A server may return a successful transport response for a request that was accepted but not completed. A resource may be cached. A downstream system may return stale data.

When those distinctions matter, the result should carry status, source, timestamps, operation identifiers, and error semantics that the host can preserve. The model should not be encouraged to infer completion from a generic success message.

This is especially important for write operations, asynchronous tasks, and cross-system workflows.

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:

1. The host enables the incident server for the user’s task and presents the available features.
2. The user selects the incident-triage prompt, or the host applies an approved workflow.
3. The host attaches the relevant resource or asks the server for a filtered view.
4. The model interprets the evidence and proposes a search for related events.
5. The MCP client sends the structured request to the incident server.
6. The server checks identity, scope, query limits, and data policy before reading the incident system.
7. The server returns events with source, time range, freshness, and any incomplete-data status.
8. The model prepares an escalation proposal, but does not send it yet.
9. The host shows the target team, incident scope, message, and expected effect to the user for approval.
10. After approval, the host invokes create_escalation through the server.
11. The server validates the target, authorization, idempotency key, and current incident state before calling the notification capability.
12. 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.

What Changes Because of It?

Architecture

MCP creates a candidate integration layer between AI hosts and external context or capability providers. The important architectural decision is not whether every service should become an MCP server. It is where a shared protocol provides more value than a direct integration.

Teams need to decide:

• which capabilities deserve a shared server boundary;
• which context can be exposed and under what scope;
• whether a server should be local, remote, or both;
• where host policy ends and server policy begins;
• how identities and approvals propagate;
• how cross-server workflows are coordinated;
• who owns the contract and the underlying domain behavior.

The best server boundary usually wraps a governed capability rather than exposing raw tables, arbitrary shell access, or an internal service catalog.

Engineering

Protocol support reduces repeated transport and message-handling code. It adds a compatibility surface that needs tests and release discipline.

Engineering teams need fixtures for discovery, capability negotiation, tool calls, resources, prompts, errors, cancellation, partial results, and optional interactions. They need to test both the protocol messages and the domain behavior behind them.

Descriptions and schemas should be versioned with the implementation. If the server says a tool is read-only while it changes state, the protocol cannot correct the mismatch.

Product and UX

Users need to understand which server is being used, what context is being shared, when a tool is invoked, and whether an action is proposed, approved, accepted, or complete.

The host should make connected servers visible enough to support consent and troubleshooting. A conversational interface can make the path feel simple, but it should not hide a consequential operation behind a vague confirmation.

For elicitation and external authorization, the user should see which server is asking, what information is needed, where a URL leads, and how to decline or cancel.

Business and operations

The integration boundary creates new ownership questions. A server may be operated by a platform team while its data and policy belong to a domain team. A host may cache discovery data while the server owner changes a tool’s behavior.

Operations should measure:

• server availability and latency by capability;
• discovery freshness and cache behavior;
• tool selection and invocation rates;
• authorization and consent denials;
• error and retry patterns;
• downstream completion versus accepted requests;
• data volume and sensitive-field exposure;
• protocol version and extension compatibility.

The most useful trace spans the host, MCP client, server, downstream capability, and final user-visible outcome. A log that says only “tool call succeeded” is not enough.

Security and governance

An MCP connection is a data and action boundary. Security review should cover both sides of the connection and the process between them.

For a local server, ask what code is installed, which files and network destinations it can reach, which credentials it inherits, and how it is isolated. For a remote server, ask what context leaves the host, how identity is established, where data is stored, and which downstream systems the server can reach.

Treat model instructions, resource content, tool descriptions, and tool results as separate inputs with separate trust levels. A document returned from a server may contain an instruction aimed at the model. That instruction must not change authorization or approval rules.

The server should not receive the entire conversation by default. The host should not pass a user’s token through to a downstream service merely because it is convenient. The capability owner should enforce access again at the point of effect.

Failure Modes

The most common failures appear when a shared protocol is mistaken for a complete integration architecture.

Capability catalog overload

The host exposes hundreds of tools because discovery made them easy to list. The model sees overlapping names, descriptions, and schemas. Selection quality falls, context grows, and latency increases.

Filter by task, identity, risk, and relevance. Treat capability discovery as context engineering.

Poisoned or misleading metadata

A tool description claims that an operation is safe, read-only, or limited when the implementation does something else. A resource annotation suggests authority that the underlying data does not have.

Review metadata as executable interface material. Enforce side-effect classification and policy outside the description.

Protocol success mistaken for business success

The MCP request returned a valid response, so the host tells the user that the operation completed. The underlying service may only have accepted the request, queued it, or returned a partial result.

Model the outcome states explicitly and preserve operation identifiers when later lookup is required.

Cross-server data leakage

The host sends too much conversation context to one server, or lets a result from one server flow into another without checking scope and provenance.

Use least-necessary context, per-server permissions, explicit provenance, and host-controlled composition.

Confused deputy and token passthrough

A server uses a broad host credential to perform an action for a user, or forwards a token to a downstream service that was not intended to receive it. The user appears authorized at one boundary while the actual action bypasses another boundary.

Bind identity and scope at each relevant boundary. The server and downstream capability should make their own authorization decisions.

Unsafe local server installation

A local server runs with access to files, environment variables, network destinations, or credentials beyond what its feature requires. The host treats installation as convenience rather than code execution.

Use an explicit trust and installation model, isolate processes where practical, minimize permissions, and make revocation possible.

Prompt injection through resources or results

A repository file, incident note, web page, or tool result contains instructions such as “ignore previous rules” or “send this data elsewhere.” The model treats the content as an instruction rather than untrusted data.

Preserve provenance, separate data from instructions, and enforce authorization and approval in deterministic code.

Stale discovery

The host caches a tool or resource list after the server’s contract has changed. The model continues to use an old description or calls a capability that is no longer available.

Use explicit freshness and invalidation behavior, version contracts, and test old-client/new-server and new-client/old-server combinations.

Version and extension mismatch

A server expects a feature that the client did not declare, or a client assumes that every server supports an optional extension. The failure may appear only in an uncommon interaction such as cancellation, elicitation, or long-running work.

Negotiate capabilities explicitly and make unsupported behavior fail clearly.

Hidden state in a supposedly stateless path

The host assumes that a connection, process, or transport session represents one conversation. Requests are retried or load-balanced and the server applies state from the wrong task or user.

Keep state explicit, bind it to identity and task scope, and do not use connection identity as a substitute for an application-level handle.

Protocol sprawl without domain ownership

Several teams publish servers for the same system with different names, semantics, and policy behavior. The organization has a standard wire format but no standard meaning or owner.

Treat MCP as an integration boundary inside an architecture governance model. A protocol cannot resolve duplicated domain authority by itself.

KNOW / UNDERSTAND / BUILD

KNOW

Know that MCP is a shared protocol for connecting AI hosts to external context and capabilities. Know the host, client, server, and the three core server primitives: prompts, resources, and tools.

Know the central caveat: discovery and interoperability do not equal trust or authorization.

UNDERSTAND

Understand when a shared protocol is more useful than a direct integration. Understand the difference between the host’s control over model context and the server’s control over its capability boundary. Understand how discovery, schemas, transport, authentication, consent, and domain policy fit together.

Understand that a tool exposed through MCP is still a tool call, and that MCP does not replace the runtime controls described in Post 04, Tool Calling.

BUILD

MCP belongs at KNOW for most readers today. Build a small server if you are implementing AI integrations or evaluating the protocol in your environment.

The smallest useful experiment has one host, one server, one read resource, one read tool, and one consequential tool behind explicit approval. Log discovery, capability negotiation, each request and response, identity, policy decisions, latency, and the final outcome.

Then test an ambiguous argument, a denied request, a stale resource, an injected instruction in tool output, a retry after an uncertain timeout, and a server that does not support an optional feature. The point is to observe the boundaries, not to accumulate a large catalog of tools.

Build It Once

Start with a capability that already has a clear owner and a stable domain boundary. A useful first server might expose a repository search or incident lookup, not a generic shell or unrestricted database connection.

Define:

• the server’s purpose and owner;
• the data and systems it may reach;
• the resources, prompts, and tools it exposes;
• the identity and scope required for each feature;
• the input and output schemas;
• the data classification and provenance returned;
• the side-effect and approval classification;
• retry, idempotency, timeout, and completion behavior;
• the supported protocol versions and extensions;
• the host contexts in which the server is allowed to run.

For a first read capability, return a stable structured result with source, freshness, and scope. For a first write capability, return a distinct status for rejected, accepted, pending, and completed. Make the host ask for approval before the side effect and make the server enforce the rule again.

Keep the server narrow enough that a reviewer can understand the entire exposure. Add more capabilities only when a real task needs them and the resulting context remains usable.

Will This Term Survive?

Model Context Protocol is likely to remain a recognizable label because it names a real ecosystem boundary and has a concise acronym. The exact specification, transport model, primitive set, and extension names will continue to change.

The phrase may eventually sit alongside more general terms such as capability protocol, agent protocol, or context exchange. A different protocol may also become dominant for a particular class of agent interoperability.

The durable pattern is broader than MCP: hosts and external capability providers need shared contracts for discovery, context exchange, invocation, results, identity, and evolution. That pattern will remain useful even if today’s name or wire format changes.

The durable question is not whether every AI application uses MCP. It is whether teams have made the boundary between an AI host and an external capability explicit enough to govern.

Where It Fits in the Map

MCP sits between model context and governed capability.

• Post 03, The Application Boundary Is Weakening: MCP is one concrete way for multiple experiences and agents to reach shared context and capability without placing all meaning inside one application UI.
• Post 04, Tool Calling: tool calling describes the model-mediated invocation pattern. MCP can standardize how tools are discovered, described, invoked, and returned across hosts and servers. It does not replace runtime authorization or business policy.
• Context engineering: MCP provides resources, prompts, tool descriptions, and results that may enter context. Context engineering decides what belongs in the model’s working set and how it should be trusted.
• Agents and orchestration: an agent may choose MCP tools across several rounds. MCP provides a connection contract; the agent runtime still owns stopping conditions, budgets, recovery, and workflow policy.
• Authorization and security: MCP can carry protocol-level identity and authorization flows, but each server and domain capability still needs its own access, data, and action controls.
• Observability and evals: discovery, selection, requests, results, and downstream outcomes should appear in traces and evaluation cases.
• Durable execution: long-running operations may need explicit task handles, polling, and resumability. A transport connection should not be mistaken for durable workflow state.

MCP connects context and capability in the larger AI-native stack; adjacent layers keep their own responsibilities.

The abstraction shift is from custom pairwise integrations toward a shared protocol boundary. The hard work then moves to the questions a protocol cannot answer for you: which context is trusted, which capability is allowed, who owns the policy, and what actually happened.

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.