Model Context Protocol

The Model Context Protocol (MCP) is an open protocol for connecting artificial intelligence applications to external capabilities and context. It standardizes how a host application communicates with servers that expose tools, resources, and prompts, along with supporting mechanisms for authorization, user input, notifications, and protocol extensions. The protocol supplies a common wire contract, and no more than that: it does not decide which server should be trusted, which tool a model should call, whether a result is true, or whether an action is safe.

Anthropic introduced MCP in November 2024 as a way to replace one-off integrations between AI applications and data sources with a reusable client-server interface. The project subsequently developed public governance, multiple dated specification revisions, official software development kits, and an extension process. (Anthropic launch; MCP governance)

The protocol changed substantially in the specification dated July 28, 2026. That revision made the core request model stateless and self-contained, removed the initialize handshake and protocol-level session identifiers from current semantics, moved client capabilities into each request, replaced independent server-to-client requests with multi round-trip requests, and revised Streamable HTTP. It also moved Tasks to an extension and deprecated Roots, Sampling, and Logging. Older explanations centered on a long-lived initialized session now describe a compatibility era, not the current protocol. (2026 release; 2026 changelog)

This entry explains the protocol itself as of that revision. The dated survey The Model Context Protocol Ecosystem as of 2026 covers implementations, vendors, server directories, adoption patterns, and ecosystem conditions. That survey should not be used as the normative description of the current wire protocol.

Coverage note: This article reflects the MCP specification and official documentation reviewed through August 8, 2026. The normative specification version discussed is 2026-07-28.

What MCP standardizes

MCP addresses a repeated integration problem. An AI application may need access to files, databases, search systems, business services, development tools, or domain-specific workflows. Without a shared protocol, each application needs a custom connector for each service, and each service needs application-specific integration logic. MCP places a protocol boundary between them:

• a server describes capabilities in a common schema;
• a client discovers and invokes those capabilities using defined methods;
• a host decides how those capabilities enter the application and model context;
• transports carry the same JSON-RPC semantics locally or remotely;
• authorization and security rules establish some of the surrounding constraints.

The standardization target is deliberately limited. MCP does not standardize the model, agent loop, user interface, retrieval strategy, database, operating system, or business API behind a server. A server may wrap a local command, a remote service, an in-memory index, or a composite workflow. A host may use a language model, a deterministic program, or a person to decide which exposed feature to invoke.

This separation is why MCP is better understood as an application protocol than as an agent framework. It defines typed messages and participant responsibilities. It does not define a complete autonomous agent architecture. The official specification describes JSON-RPC messages, host-client-server roles, request metadata, features, transports, and authorization while explicitly leaving deployment details and most policy decisions to implementations. (Current specification; Base protocol)

Three statements capture the boundary:

1. MCP makes capabilities legible across implementations. A shared method and schema let a host inspect a tool or resource across vendor boundaries.
2. MCP does not make capabilities trustworthy. A conforming server can still expose dangerous operations, misleading descriptions, vulnerable code, or malicious content.
3. MCP does not make host behavior uniform. Hosts can differ in consent prompts, model access, feature support, context selection, retries, auditing, and error presentation.

Participants and responsibility boundaries

MCP uses a host-client-server architecture. The distinction between a host and a client is easy to miss because one application often contains both.

Host

The host is the AI application or coordinating runtime. It creates and manages clients, controls user-facing permissions, aggregates context, applies security policies, and decides how server capabilities are exposed to a model or other decision process. Examples include a desktop assistant, an integrated development environment, or an agent runtime.

The host is the primary policy boundary. It can withhold a tool from the model, require confirmation before an action, redact data, restrict which servers may connect, or prevent one server’s data from reaching another. MCP messages can carry relevant metadata, but the host is responsible for enforcing the policy.

Client

An MCP client is the protocol component that communicates with one MCP server. The architecture pairs one client with one server, and that is a relationship rather than a connection count: under a stateless transport a single client may open and close many HTTP connections to the same server, and the pairing is unchanged. A host connected to five servers ordinarily manages five client instances. Each client handles message exchange, feature negotiation, transport behavior, and the host-side portion of the protocol for its server.

The client is not necessarily the end user and not necessarily the model. It is a protocol role. This distinction matters in security analysis because authorization might identify a client, a user, a host application, or some combination, while the model remains an internal component of the host.

Server

An MCP server exposes capabilities through the protocol. It can offer tools for actions and computations, resources for contextual data, and prompts for user-selectable interaction templates. It may also support optional utilities, subscriptions, and extensions.

The architecture aims to keep servers isolated from the host’s full operation. A server should receive only the information required for its requests, and in a well-built host the full conversation and the contents of other servers stay with the host. That is a property of the host's design, not a boundary the protocol enforces: nothing in MCP prevents a host from putting an entire transcript into a tool argument, and no server can tell that it happened. Whether an implementation actually preserves that minimization depends on what the host sends and what a tool argument contains. The protocol architecture supports isolation; it cannot guarantee that an application uses it well. (MCP architecture)

Role	Owns	Does not inherently own
Host	User experience, permission policy, context aggregation, client management, model integration	Server implementation details
Client	One server relationship, protocol messages, transport behavior, capability handling	The host’s total policy or the server’s business logic
Server	Capability definitions, execution, returned content, server-side authorization checks	The user interface, model behavior, or trust decision to invoke it

This division is a design constraint, not proof of least privilege. A host that sends excessive context or auto-approves every tool call defeats the intended boundary without violating the JSON-RPC grammar.

Wire format and message model

MCP uses JSON-RPC 2.0 as its base message format. Requests contain a method, parameters, and an identifier. Responses carry either a result or an error associated with that identifier — and in this revision a result is no longer an opaque object: it “MUST include a resultType field to indicate the type of the result.” Two values are defined in the core protocol, "complete" for a finished request and "input_required" for one that needs another round trip, extensions may add more, and an unrecognised value “MUST be considered invalid.” The compatibility rule matters as much as the field: because earlier revisions have no resultType, clients “MUST treat an absent resultType as "complete".” The revision also adds cache metadata: the changelog summarises it as “Require[s] ttlMs and cacheScope fields on results returned by tools/list, prompts/list, resources/list, resources/read, and resources/templates/list” through a new CacheableResult interface, and the normative caching page — not this summary — governs which results actually carry them — ttlMs a freshness hint, cacheScope ("public" or "private") governing whether a shared intermediary may cache the response. A client written to the older mental model — result-or-error, parse by request method — will not validate any of this. Notifications do not require a response. The July 2026 schema adopts JSON Schema 2020-12 for schema-bearing features, while the TypeScript schema in the specification repository remains a source of truth for protocol types. (Base protocol)

The current directionality is asymmetric:

• clients send JSON-RPC requests to servers;
• clients can send transport-appropriate notifications;
• servers return responses and request-related notifications;
• servers do not initiate independent JSON-RPC requests in the current protocol;
• server needs for roots, sampling, or elicitation are represented inside a response through the multi round-trip request pattern.

Every current request carries protocol metadata in _meta. The protocol version and client capabilities travel with each request; older revisions established them once for a connection-scoped conversation. Client identity information can also travel in this metadata. A transport may mirror selected information into an envelope such as HTTP headers, but the message body remains authoritative. (Transport overview)

The result is a request model in which any compliant server instance can understand a request without consulting a protocol session established earlier. The protocol is stateless in this specific sense. It does not prohibit all state.

Protocol statelessness versus application state

A shopping cart, long-running workflow, database transaction, authenticated account, or billing subscription can still persist across requests — application subscriptions in the commercial sense, not the protocol's subscriptions/listen streams, which do not survive a transport restart. The difference is that this state is explicit. A server can return an identifier, cursor, workflow handle, or other application-level reference, and the client supplies it in a later request. The protocol no longer supplies an implicit session bucket in which arbitrary context can hide.

This distinction has operational consequences:

• requests can be routed to different server instances;
• retries do not depend on connection affinity when application state is explicit;
• state handles must be scoped and authorized like any other object identifier;
• a fresh process can handle a request if it has access to the referenced application state;
• developers cannot assume that a transport connection preserves protocol memory.

Explicit state can improve scalability and auditability, but it creates its own security obligations. A guessable or stolen workflow handle can become an insecure direct object reference. The official guidance here is the Security Best Practices document, and the modality is part of the content: it recommends that servers bind state handles to the authenticated principal and validate authorization on every use, rather than mandating it in the schema. Treat it as the standard of care a reviewer will hold you to, not as something a conformance test will catch. Possession alone provides insufficient authority. (Security practices)

The current request lifecycle

Earlier MCP revisions defined initialization, operation, and shutdown phases. A client sent initialize, the server returned negotiated capabilities, the client sent notifications/initialized, and an optional session identifier could bind later HTTP requests. Descriptions of that lifecycle remain relevant when interoperating with older servers.

The 2026-07-28 lifecycle is per request:

1. A compatibility-capable client may send server/discover to determine whether a server speaks modern MCP and which versions it supports.
2. The client sends a JSON-RPC request carrying its selected protocol version and per-request client capabilities.
3. The server either returns a final result, returns a protocol or application error, or returns resultType: input_required when it needs supported client-side input.
4. If input is required, the client obtains the requested information and sends a new invocation of the original method with the corresponding input responses and any opaque request state.
5. The server returns another input-required result or the final result.
6. Transport closure ends a local process or request stream, but there is no protocol-level session teardown.

The step is optional for the client, not for the server: server/discover is an RPC servers must implement, added by this revision, and a server that omits it is non-conformant however few clients call it. Sending it is especially important for clients that support both modern and legacy eras. A successful server/discover response identifies a modern server and its supported versions. A recognized modern unsupported-version error directs the client to a mutually supported version. An unknown-method-style response or timeout can trigger legacy initialize fallback, and what counts as one is transport-specific: over stdio an unrecognised non-modern reply to the probe is the signal, while over HTTP a 404 carrying JSON-RPC -32601 identifies a modern server and must not be read as a legacy endpoint. A client that supports only the current era can send a current request directly and handle an unsupported-version error. (Server discovery; stdio transport)

Concern	Legacy initialized era	2026-07-28 era
Version and capability agreement	Connection-scoped initialize exchange	Metadata on every request, with optional discovery
Protocol session	Connection or HTTP session could hold negotiated state	No protocol-level session
Server request to client	Independent JSON-RPC request	InputRequiredResult followed by client retry
HTTP server events	Could use a general GET SSE stream	Request-scoped SSE or explicit subscription listen stream
Cross-request business state	Often mixed with session assumptions	Explicit application handles or external state

Calling the modern protocol “sessionless” should not be confused with “connectionless.” A stdio client still owns a subprocess and its streams. An HTTP client still opens connections. SSE can remain open for a request or subscription. These are transport lifetimes, not implicit protocol sessions.

Multi round-trip requests

Multi round-trip requests (MRTR) replace independent server-initiated JSON-RPC requests. When a server handling tools/call, resources/read, or prompts/get needs information from the client, it returns an InputRequiredResult. That result can contain one or more input requests and an opaque requestState. The client fulfills the supported inputs and retries the original method with a new JSON-RPC identifier. (MRTR)

The pattern supports three kinds of input request retained in the current schema:

• elicitation from the user or client environment;
• sampling, in which the client obtains model output;
• roots listing, in which the client supplies filesystem or resource boundaries.

Sampling and Roots are deprecated features in the July 2026 lifecycle, but the MRTR mechanism defines how they operate during the compatibility period. Elicitation remains a current client feature.

MRTR serves the stateless design. The retry is an independent request. A server can encode the context it needs into requestState, and a different instance can process the retry. The client must treat that value as opaque and echo it unchanged. The server must treat it as attacker-controlled on return. If it affects authorization, resources, or business logic, the server should protect its integrity, bind it to the principal and original request, and impose an appropriate expiry — again recommended practice rather than a normative MUST, and again the thing a security review will ask for. Some one-time operations still require server-side replay prevention.

MRTR is not an unlimited dialogue channel. Current InputRequiredResult responses are permitted only for specified invocation methods, and a server may request only features the client declared. Clients can decline user input, fail to retry, or lack the requested capability. Servers must handle each outcome explicitly.

Core server primitives

MCP’s best-known server features are tools, resources, and prompts. They use related discovery and invocation patterns but represent different authority models.

Tools

A tool is an executable capability identified by name. Its definition includes a human-readable description and an input schema. It can also declare an output schema and annotations. Clients use tools/list to discover tools and tools/call to invoke one with arguments. Tool results can contain textual, image, audio, embedded-resource, or structured content depending on the schema and implementation. (MCP tools)

Tools are commonly described as model-controlled because a host may expose them to a model for selection. That is an interaction convention, not a requirement to auto-execute model choices. The host can require confirmation, restrict arguments, disable tools, or invoke them through deterministic application logic.

Tool descriptions and annotations are untrusted server-supplied claims. A label such as “read only” does not prove that implementation has no side effects. Trusted configuration, server identity, sandboxing, and observed behavior should drive host policy. An annotation alone supplies no security guarantee.

Resources

A resource is contextual data addressed by a URI. Servers can expose a fixed list of resources, URI templates for parameterized resources, or both. Clients can list resources and templates, read content, and, where supported, subscribe to updates. Resource contents can include text or binary data with media types and descriptive metadata. (MCP resources)

Resources are often called application-controlled because the host decides which resource to retrieve and how to place it into context. A model may influence that decision inside a host, but MCP does not require the server to decide what the model sees.

The URI is an identifier within the server contract, not proof that the data came from a safe location. A resource can contain prompt injection, malicious markup, secrets, false claims, or oversized content. Hosts must apply content and context policies after retrieval.

Prompts

A prompt is a named, discoverable template for constructing messages or workflows. Servers can list prompt definitions and return a rendered prompt for supplied arguments through prompts/get. The feature is commonly described as user-controlled because hosts may present prompts as commands, menu items, or explicit user selections. (MCP prompts)

Prompts do not outrank host policy or system instructions merely because they arrive through a protocol primitive. They are server-provided content. A host decides whether to display, transform, or submit them to a model.

Elicitation

Elicitation is listed here because a server initiates it, but the capability belongs to the client: it is the client that must be able to render a form or open a URL, and a server can only ask. It lets a server request additional information while processing an invocation. Form-mode elicitation asks for structured, non-sensitive input described by a schema. URL-mode elicitation directs the user to a browser interaction for sensitive information, third-party authorization, payment, or another out-of-band flow. The host controls presentation, consent, and what is returned. (MCP elicitation)

In the current protocol, elicitation travels through MRTR. Older independent server requests no longer carry it. The MRTR form keeps the request self-contained and prevents a server from opening an unsolicited bidirectional dialogue outside the invocation it is fulfilling.

Deprecated features and extensions

The July 2026 revision deprecated Roots, Sampling, Logging and Dynamic Client Registration with a defined compatibility period; the specification's deprecated-features registry gives all four an earliest removal of “First revision released on or after 2027-07-28”, and names Client ID Metadata Documents as the migration path for the last of them. Deprecation does not mean every implementation stops accepting them immediately. It means current implementers should not treat them as stable foundations for new protocol design, and the features may be removed after the documented lifecycle. The deprecated registry records status and replacement guidance. (Deprecated features)

Tasks, previously an experimental core feature for durable or asynchronous work, moved to an official extension. This change illustrates the role of the extension system: important functionality can evolve outside the minimal core, use its own versioning, and later mature without forcing every MCP implementation to support it. Extensions are additive protocol modules identified through namespaced metadata and governed through an extension lifecycle. (MCP extensions)

The core-extension boundary is architectural. A smaller core reduces mandatory complexity and makes conformance easier. Extensions let specialized features evolve faster. The cost is a more complex compatibility matrix: two products can both “support MCP” while sharing only the core and none of the same extensions.

Standard transports

MCP semantics are transport-independent. The current specification defines two standard bindings: stdio and Streamable HTTP. Both carry UTF-8 JSON-RPC. They differ in process ownership, framing, cancellation, metadata envelopes, and security assumptions. (Transport overview)

stdio

Under stdio, the client launches the server as a subprocess. It writes newline-delimited JSON-RPC messages to the server’s standard input and reads server messages from standard output. Each message occupies one line and cannot contain an embedded newline. The server may use standard error for logs but must keep standard output free of non-protocol text. (stdio transport)

All protocol metadata stays in the JSON-RPC body because there is no header layer. Cancellation uses a notifications/cancelled message associated with an in-flight request. Graceful shutdown begins when the client closes the server’s input stream; the client can terminate the process if it does not exit. If the process crashes, the spec says the client “SHOULD restart it”, and it is careful to separate what follows: because the protocol is stateless, in-flight requests “are simply lost and the client can retry them against the fresh process”, while active subscriptions/listen streams “must also be re-established after restart.” Retry is permitted, not required — which is the right rule, since blindly retrying a non-idempotent tool call is how a crash turns into a duplicate side effect.

stdio is simple and useful for local integrations, but local does not mean harmless. Launching a server grants code execution under some operating-system identity. Install flows, command arguments, environment variables, filesystem access, inherited credentials, and package provenance are part of the trust decision.

Streamable HTTP

Under current Streamable HTTP, a server exposes one MCP endpoint that accepts POST. Every client JSON-RPC message is a separate POST — though in practice that means requests: “This revision of the core protocol defines no client-to-server notifications over Streamable HTTP.” The one client-sent notification in the core protocol, notifications/cancelled, is stdio-only; on this transport “closing the SSE response stream is itself the cancellation signal”, and the spec says outright that header requirements for notification POSTs “are not defined by this revision.” A client that ports its stdio cancellation path to HTTP is implementing a message the transport does not expect. A request receives either one JSON response or an SSE stream scoped to that request. The stream can carry progress or logging notifications related to the request and then the final response. Long-lived change notifications use the response stream of subscriptions/listen, not a general server event channel. (Streamable HTTP)

The 2026-07-28 revision removed both the general GET stream endpoint and protocol-level sessions. It also requires request metadata to be mirrored in HTTP headers. Every POST carries MCP-Protocol-Version; every request carries Mcp-Method; calls to tools, reads of resources, and retrievals of prompts also carry Mcp-Name. The corresponding body fields remain authoritative, and mismatches must be rejected. Tool schemas can designate selected primitive arguments for safe mirroring into Mcp-Param-* headers.

Servers must validate the Origin header to reduce DNS rebinding risk, should bind local HTTP servers to loopback rather than all interfaces, and should authenticate remote connections. Closing a request’s SSE response stream signals cancellation for that request. Resumable SSE through Last-Event-ID is not part of the current binding.

The transport comparison is therefore not “local versus internet” alone:

Property	stdio	Streamable HTTP
Server ownership	Client-launched subprocess	Independently running service
Framing	One JSON-RPC message per line	One JSON-RPC message per POST
Metadata envelope	Message body only	Body plus required mirrored headers
Streaming	Shared process output channel	JSON response or request-scoped SSE
Cancellation	notifications/cancelled	Close the response stream
Typical credential source	Process environment or local configuration	Optional MCP OAuth-based authorization

Authorization

MCP authorization is optional and defined for HTTP-based transports. It is based on a selected set of OAuth and OpenID standards. A protected MCP server acts as a resource server, the MCP client acts as an OAuth client, and an authorization server authenticates the resource owner and issues access tokens. stdio implementations should obtain credentials from the environment rather than applying the HTTP authorization flow. (MCP authorization)

Current authorization discovery begins with OAuth Protected Resource Metadata. Clients locate the authorization server, obtain a client identifier through Client ID Metadata Documents, preregistration, or Dynamic Client Registration — which is not merely legacy but formally deprecated in this revision, with Client ID Metadata Documents as its named migration path, and use authorization-code protections appropriate to public or confidential clients. Client ID Metadata Documents are preferred; Dynamic Client Registration remains for backward compatibility. Servers can challenge for the minimum scopes required and clients can perform bounded step-up authorization when an operation needs more access.

Resource binding is central. The client includes a resource indicator for the intended MCP server, and the server validates that an access token was issued for itself. A token received by the MCP server must not simply be forwarded to a downstream API. If the server calls another OAuth-protected service, it acts as a separate OAuth client there and obtains a token intended for that service. Downstream services authenticated some other way — an API key, mTLS, or nothing — are outside this rule, but the principle that survives is the same one: the token the MCP server received is not currency anywhere else.

Authorization answers a limited question: which principal may invoke which protected server operation under which scopes? It does not establish that the operation is prudent, that the model understood the user, that the tool description is accurate, or that returned content is safe. A valid token is not informed consent for every action available through the token.

Security and trust boundaries

The MCP specification states security principles but also acknowledges that the protocol cannot enforce them by itself. Implementations must build consent, access control, isolation, data minimization, and audit around the wire contract. (Current specification)

Several trust boundaries deserve separate treatment.

Server installation and connection

A local server is executable code. A remote server is a network principal with access to whatever the client sends and whatever scopes the user grants. A polished manifest or valid protocol response does not establish provenance. Hosts need allowlists, package verification, sandboxing, network controls, or equivalent deployment policy appropriate to the risk.

Tool invocation

Tool calls can read, write, spend, send, delete, execute, or disclose. The host should distinguish read-only retrieval from mutation, show consequential arguments, support confirmation and cancellation, and log enough detail for review. Tool annotations can inform presentation but cannot substitute for enforcement.

Content entering model context

Resources, prompt templates, tool results, and error messages are untrusted content. They can contain instructions designed to override the host or manipulate the model. MCP gives the content a typed path into the application; it does not solve prompt injection. Hosts need provenance markers, context separation, least-privilege tool exposure, output validation, and policies that prevent retrieved text from silently acquiring authority.

OAuth intermediaries

Official security guidance identifies confused-deputy attacks, token passthrough, and server-side request forgery among the relevant risks. A proxy server using shared upstream credentials must preserve per-client consent. Clients fetching authorization metadata must prevent attacker-controlled URLs from reaching internal services or cloud metadata endpoints. Tokens must be audience-bound, validated, and kept out of query strings. (Security practices)

Explicit state

Stateless protocol design shifts durable state into visible handles. Servers should authorize each use, prevent cross-user reuse, protect MRTR request state from tampering, and add expiry or single-use enforcement where required — recommended practice, as the sections above say, with one normative exception: validating returned requestState is required by the MRTR specification rather than merely advised. Statelessness improves routing; it does not eliminate state attacks.

Capability disclosure

Per-request capabilities reduce reliance on stale session negotiation, but a server still must not assume the client will fulfill an input request or support a feature it did not declare. A client should expose only capabilities it is prepared to implement safely. Advertising elicitation or model sampling creates an interface through which a server can ask for more authority or information.

Versioning, compatibility, and governance

MCP specification versions use date identifiers such as 2026-07-28, whose immediate predecessor is 2025-11-25 — the revision this one's changelog measures itself against, and the one a "legacy initialized era" client is most likely to be speaking. The date identifies a protocol contract, not merely a documentation snapshot. A request declares the version whose semantics it uses. A server that recognizes modern MCP but cannot support that version returns an unsupported-version error with its supported set. Compatibility-capable clients can use discovery and the documented era rules to choose current or legacy behavior. (Versioning)

This design makes the revision boundary explicit. A server must not accept a current version header while silently applying the stateful semantics of an older revision. HTTP body and header versions must agree. Client libraries should test mixed-version behavior; two MCP-branded components may implement different lifecycles.

The project uses Specification Enhancement Proposals, or SEPs, for major features, breaking changes, interoperability standards, and governance changes. SEPs record motivation, specification, rationale, backward compatibility, reference implementations, and security implications. Final proposals are historical records; the current specification and changelog remain authoritative when later revisions alter the accepted design. (MCP governance)

The July 2026 release also formalized a feature lifecycle with deprecation periods and conformance expectations. This improves change discipline, but it does not erase migration risk. The revision is a major architectural break from the initialized-session era. Ecosystem support can lag the normative document, and SDK versions can differ in which era and extensions they implement.

What MCP does not provide

Several common descriptions attribute more to MCP than the protocol supplies.

It is not a universal API replacement

An MCP server usually wraps an existing API, library, command, or data source. The underlying service still defines business semantics, transactions, quotas, and domain errors. MCP standardizes how an AI host sees selected capabilities; it does not replace every service contract.

It is not a model context window

The word context refers to connecting applications with external information and capabilities. MCP does not enlarge a model’s token limit or specify how retrieved content is compressed, ranked, cited, or retained.

It is not an agent planner

MCP exposes possible actions and data. It does not select goals, decompose tasks, choose tools, recover from semantic failure, or decide when to stop. Those behaviors belong to the host, model, and surrounding agent architecture.

It is not a security sandbox

Protocol conformance does not constrain what server code can do on the machine or what a remote operation can change. Sandboxing, credentials, network restrictions, user consent, and audit are implementation concerns.

It does not guarantee semantic interoperability

Two weather tools can use different names, units, error conventions, geographic assumptions, and freshness guarantees while both conforming to MCP. Schemas improve structural interoperability, not shared ontology or result quality.

It does not guarantee feature parity

Hosts may omit prompts, subscriptions, elicitation, extensions, or legacy compatibility. Servers may expose different subsets. “Supports MCP” is therefore an incomplete procurement or architecture claim. The relevant question is which specification version, transports, primitives, authorization profile, and extensions have been tested together.

Implementation checklist

A current implementation review can use the following sequence.

1. Pin the protocol era. State whether the component implements 2026-07-28, a legacy initialized revision, or both.
2. Validate every request, and every result. Check JSON-RPC shape, protocol metadata, capabilities, method parameters, and schema constraints on the way in — and on the way back, that a result carries a resultType your client recognises, that an absent one is read as "complete" rather than rejected, and that cache metadata on cacheable results is honoured or deliberately ignored.
3. Keep current requests self-contained. Do not depend on an initialize exchange or protocol session when claiming current semantics.
4. Handle MRTR deliberately. Support only declared input request types, treat requestState as opaque on the client and untrusted on the server, and bound retries.
5. Separate application state. Use explicit, authorized handles and document their lifetime, ownership, and replay behavior.
6. Implement one transport exactly before adding another. Keep stdout protocol-clean for stdio; validate origins, headers, and SSE behavior for HTTP.
7. Define the trust policy outside server metadata. Decide installation, allowlisting, consent, tool-risk classes, context handling, and logging from trusted configuration.
8. Bind authorization correctly. Use protected-resource discovery, audience-bound tokens, least privilege, issuer validation, and no token passthrough.
9. Treat all server content as untrusted. Validate outputs, preserve provenance, and prevent data from becoming instructions by default.
10. Test mixed-version failure. Verify discovery, unsupported versions, legacy fallback, header-body mismatch, missing features, and extension absence.
11. Test cancellation and interruption. Cover closed HTTP streams, stdio cancellation, process death, repeated MRTR, and abandoned user input.
12. Publish exact support claims. Name the revision, transport, primitives, authorization mode, extensions, and known deviations.

This checklist is intentionally more specific than “use an SDK.” An SDK can serialize messages correctly while an application still violates trust boundaries or applies semantics from the wrong protocol era.

Open questions and confidence

Confidence is very high in the wire-level account because the July 28 specification, changelog, transport pages, and security guidance are explicit. Confidence is high in the architectural distinction between protocol interoperability and host policy. Confidence is moderate in predictions about real-world interoperability because the revision was eleven days old at this article’s staging date. Client, server, gateway, and SDK adoption could lag or implement transitional behavior.

The largest conceptual uncertainty is not what the current specification says, but how the ecosystem will divide responsibility between core, extensions, and host-specific conventions. Moving capabilities out of the core can improve simplicity while increasing optionality. Per-request negotiation can improve horizontal scaling while requiring more disciplined metadata and state-handle security. HTTP routing headers can improve infrastructure visibility while expanding the metadata exposed to intermediaries.

MCP’s enduring value will depend on more than connector counts. It will depend on whether implementations preserve the protocol’s narrow contract, state their supported era precisely, and build enforceable trust policy around capabilities that can affect real systems.

References

1 Anthropic launch — Anthropic, “Introducing the Model Context Protocol.” (Anthropic)

2 2026 release — David Soria Parra and Den Delimarsky, “The 2026-07-28 Specification.” (MCP Blog)

3 Current specification — Model Context Protocol project, “Specification, Revision 2026-07-28.” (MCP Specification)

4 2026 changelog — Model Context Protocol project, “Key Changes in the 2026-07-28 Specification.” (MCP Specification)

5 MCP architecture — Model Context Protocol project, “Architecture.” (MCP Specification)

6 Base protocol — Model Context Protocol project, “Base Protocol Overview.” (MCP Specification)

7 Transport overview — Model Context Protocol project, “Transports: Overview.” (MCP Specification)

8 Server discovery — Model Context Protocol project, “Discovery.” (MCP Specification)

9 stdio transport — Model Context Protocol project, “stdio.” (MCP Specification)

10 Streamable HTTP — Model Context Protocol project, “Streamable HTTP.” (MCP Specification)

11 MCP tools — Model Context Protocol project, “Tools.” (MCP Specification)

12 MCP resources — Model Context Protocol project, “Resources.” (MCP Specification)

13 MCP prompts — Model Context Protocol project, “Prompts.” (MCP Specification)

14 MCP elicitation — Model Context Protocol project, “Elicitation.” (MCP Specification)

15 MRTR — Model Context Protocol project, “Multi Round-Trip Requests.” (MCP Specification)

16 Deprecated features — Model Context Protocol project, “Deprecated Features.” (MCP Specification)

17 Security practices — Model Context Protocol project, “Security Best Practices.” (MCP Documentation)

18 MCP governance — Model Context Protocol project, “SEP Guidelines.” (MCP Community)

19 MCP extensions — Model Context Protocol project, “Extensions Overview.” (MCP Extensions)

20 MCP authorization — Model Context Protocol project, “Authorization.” (MCP Specification)

21 Versioning — Model Context Protocol project, “Versioning and Compatibility.” (MCP Specification)

Related concepts

• The Model Context Protocol Ecosystem as of 2026 for the dated ecosystem and adoption survey
• Agent Harness for the host-side software surrounding a model
• Tool Use for model selection and invocation of external capabilities
• Tool Calling Semantics for how providers represent and execute model-selected calls
• Retrieval-Augmented Generation for bringing external information into model context
• Prompt Injection for attacks carried through untrusted content and tool output
• Local-First AI Tooling for local process, credential, and installation boundaries