Domain Explainer: Model Context Protocol#

Is this domain relevant to me?

Read this if you have wondered why an AI assistant can write a database query but can’t run it, or why every AI tool seems to need its own integration with everything. This explains what that problem is, why it needed a standard, and what it costs to solve.

The Hardware Store Analogy#

Picture a workshop full of excellent power tools, each from a different manufacturer, each with its own proprietary battery.

The drill takes a square battery. The saw takes a round one. The sander takes something else again. Every tool works beautifully. None of the batteries fit any other tool. When you buy a new tool you also buy its battery, its charger, and shelf space for both.

Then the industry agrees on one battery shape. Now any battery fits any tool. The manufacturers still compete on how good their drills are — they just stopped competing on the shape of the connector, because nobody was ever choosing a drill for its battery shape.

MCP is that agreed battery shape, for connecting AI assistants to the tools and data they need.

Before it, every AI product built its own connectors to every service, and every service that wanted AI reach built to each AI product’s format separately. Multiply the assistants by the services and you get the number of integrations somebody had to write and maintain. Most never got written, which is why AI assistants spent their first years able to discuss your systems but not touch them.

The analogy has one important limit, and it is worth carrying with you: a battery only delivers power, but an MCP connection delivers instructions the AI reads and acts on. A poisoned battery just fails. A poisoned tool description can tell the assistant to do something you did not ask for. Come back to that when you reach the trade-offs section — it is the domain’s central difficulty.

The Problem#

An AI assistant, by itself, can only produce text. It has no access to your files, your database, your calendar, or your company’s systems. It can describe how to fix your deployment; it cannot look at it.

This produces a specific and very familiar friction: the human becomes a data-transfer mechanism. You paste in logs. It suggests a command. You run it, copy the output, paste that back. You are doing clerical work to move information between a system that could reason about it and a system that holds it.

The obvious fix is to let the assistant reach the systems directly. The non-obvious part is that this is a coordination problem rather than a technical one. Any single connection is easy to build. The difficulty is that there are many assistants and many systems, and without an agreement, every pair needs its own bespoke connector — written by someone, maintained by someone, and rewritten when either side changes.

That is the situation a standard exists to fix, and it is why this became a standards problem rather than a product feature.

What the Standard Actually Does#

MCP defines how an AI client asks a system three questions and acts on the answers:

• What can you do? The system advertises its available actions — “search invoices,” “create a ticket,” “run this query” — each with a description and the parameters it expects.
• Do this. The client calls one, with arguments, and receives a result.
• What do you know? The system can expose readable content the assistant can consult.

That is close to the whole of it conceptually. The reason a specification runs to many pages is not conceptual complexity — it is everything around the edges: proving who is allowed to do what, handling work that takes a long time, running at scale behind ordinary web infrastructure, and evolving without breaking what already exists.

Two Very Different Deployments#

This is the most useful thing to understand about the domain, and the least well explained elsewhere. MCP is used in two ways that share a message format and almost nothing else.

On your own machine. The AI client launches the tool as a program on your computer and talks to it directly. No network, no passwords, no hosting. It runs as you, with your access. This is the fast path — an afternoon’s work to connect something — and it is where most usage actually lives.

Over the internet. The tool is a service somewhere else, and the AI reaches it across the network. This requires proper authorisation: you explicitly grant the assistant permission to act on your behalf, in a flow much like “sign in with Google,” and you can withdraw it later.

Almost every confusing claim about MCP comes from applying a fact about one of these to the other. “MCP requires OAuth” is true remotely and false locally. “MCP servers are unmanaged and invisible to IT” is true locally and false remotely. When you read anything about MCP, establish which one it is describing first.

The Trade-Offs#

What you gain. Write a connector once and every compliant AI client can use it. Switching assistants doesn’t mean rebuilding integrations. Services get AI reach without partnering with each AI vendor individually. It is the ordinary payoff of standardisation, and it is real — there are tens of thousands of published connectors, up from about fifty in late 2024.

What it costs.

A trust decision that isn’t revisited. This is the big one, and it follows directly from the limit in the analogy. Connecting a tool means the AI reads that tool’s descriptions of itself in order to decide what to do. If a tool you trusted is later updated to describe itself dishonestly, the assistant follows the new description. Nothing automatically re-checks.

This is not hypothetical: in one documented case, the maintainer of a widely-used connector added code that silently copied every email it sent to an outside address. It had been clean when people installed it. Practical defences exist — allowlist what you connect, pin versions, review changes, require human confirmation before anything irreversible — but they are your responsibility, not the standard’s.

An authorisation step that can’t be skipped. For network connections, someone must deliberately grant access before anything works. That deliberateness is exactly the security benefit, so it isn’t going away. It also means a service cannot demonstrate its AI integration to a curious stranger — the permission comes first, the value comes after.

A moving target. The standard revised substantially in 2026, removing several features. There is now a policy guaranteeing at least twelve months’ notice before anything is removed, but anyone building on it is signing up to follow along.

When This Domain Is Relevant#

Strongly relevant if:

• You maintain a system that people would rather operate through an AI assistant.
• You keep pasting information between an AI and your own tools.
• You are building an AI client and want it to reach things on day one.
• You need agent access to internal systems to be authorised, logged, and revocable.

Not relevant if:

• You want the AI to reason about text you can simply paste. Not everything needs plumbing.
• You have exactly one AI tool and one system to connect, forever. A direct integration is simpler, and the standard’s value is in the many-to-many case.
• You need an anonymous visitor to use an AI feature immediately. The authorisation step rules this out; that is a different problem with different answers.
• You cannot take on the security responsibility described above and have no way to constrain what gets connected.

What to Take Away#

MCP solved the connector problem and inherited a trust problem.

The standardisation worked. It is genuinely cross-vendor — competing AI companies implement it, six programming languages have official support, and a connector written for one assistant works with the others. That is what a successful standard looks like, and it happened unusually fast.

What it does not do is tell you whether a connector deserves the access you are about to give it, or notice when one changes its behaviour after you have trusted it. The standard proves who a tool is. It does not vouch for what that tool tells your assistant.

So the practical posture is straightforward: treat connecting an MCP tool the way you would treat installing a dependency with access to your data — because that is exactly what it is.

S1 Approach — Does MCP Qualify as an Open Standard?#

Survey: 2.074 Pass: S1 Rapid Discovery Original pass: December 2025 Refreshed: 2026-08-04 (see refresh-2026-08.md)

The S1 Question#

2.xxx surveys cover standards, not libraries, so S1 here asks a gate question before anything else: does MCP actually qualify as an open standard, or is it a vendor protocol with adopters?

The distinction matters because MCP was created by Anthropic and reached wide adoption fast. Fast single-vendor adoption is exactly what a de facto vendor protocol looks like early on, and the survey should not confer standard status on momentum alone.

S1 assessed this against the 2.xxx criteria: vendor-neutral governance, multiple independent implementations, and production maturity.

What S1 Concluded#

MCP qualifies. Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation in December 2025, with OpenAI, Google, Microsoft, AWS and others participating in governance. The specification is MIT-licensed, development is public via the SEP process, and independent implementations exist across languages and vendors — including direct competitors consuming it.

The verdict was recorded despite MCP’s young age (one year at the time), on the reasoning that governance transfer plus cross-vendor implementation is what the criteria actually test, and age is a proxy for those rather than a requirement of its own.

Nothing since has weakened that verdict. The 2026-07-28 revision strengthened it — a formal feature lifecycle policy with a twelve-month deprecation window and a formalised PR-based SEP workflow are process maturity markers a vendor protocol rarely bothers with.

Files in This Pass#

Reading This Pass in 2026#

S1 was written against protocol revision 2025-11-25. The current revision is 2026-07-28, and it is the largest change since MCP launched — sessions and the handshake removed, several core features deprecated, others moved into extensions.

Two consequences for anyone reading S1 now:

1. refresh-2026-08.md supersedes S1 on protocol substance, and records three claims about that revision that circulate widely in secondary sources and are false.
2. implementation-landscape.md carries a staleness banner. Its version and ecosystem figures are December 2025. ../S2-comprehensive/implementation-landscape-2026.md has the current picture, verified against package registries and the GitHub API.

The original text is retained unedited. Dated point-in-time records are more useful than silently updated ones — they show what was believed when, which is how the RC-versus-final divergence became visible in the first place.

2.074 MCP Protocol - Implementation Landscape#

Research Date: December 2025 Category: 2.0XX Open Standards & Portability Layer

⚠️ Version and ecosystem figures below are December 2025 and are superseded. Retained as a point-in-time record. Notably wrong if read as current: the Python SDK is 2.0.0 (not 1.24.0), FastMCP is 3.x (not 2.14), and Go / C# / Java / Rust are no longer “emerging community SDKs” — all four are official SDKs under the modelcontextprotocol GitHub org. There is also now an official MCP Registry. See ../S2-comprehensive/ for the current implementation picture and refresh-2026-08.md for the 2026-07-28 protocol revision.

Overview#

MCP has multiple implementations across languages and platforms. This document catalogs the ecosystem for portability assessment.

Official SDKs#

Python SDK#

• Package: mcp
• Version: 1.24.0 (Dec 2025)
• Maintainer: Anthropic
• License: MIT
• Features: Full protocol, all transports, OAuth 2.1
• Repository: https://github.com/modelcontextprotocol/python-sdk

TypeScript SDK#

• Package: @modelcontextprotocol/sdk
• Maintainer: Anthropic
• License: MIT
• Features: Full protocol, all transports
• Repository: https://github.com/modelcontextprotocol/typescript-sdk

Third-Party SDKs#

Python#

Other Languages#

MCP Clients#

Major Clients (December 2025)#

Client Compatibility#

All clients implement the same MCP specification:

• Any MCP server works with any MCP client
• No server changes needed when switching clients
• Protocol-level compatibility guaranteed

Managed MCP Infrastructure#

Google Cloud#

• Managed MCP servers for Maps, BigQuery, Compute Engine, Kubernetes Engine
• “Agent-ready by design”
• Launched Dec 2025

AWS#

• MCP servers for Lambda, ECS, EKS, Fargate
• Bedrock MCP integration
• Enterprise deployment support

FastMCP Cloud#

• Hosted MCP server deployment
• By Prefect
• Managed auth, scaling

Server Ecosystem#

Ecosystem Size (December 2025)#

Server Categories#

Transport Implementations#

stdio#

• Support: All SDKs
• Use case: Local subprocess
• Complexity: Lowest
• Performance: Best for local

Streamable HTTP#

• Support: All SDKs (since 2025-03)
• Use case: Remote/networked
• Complexity: Medium
• Performance: Production-ready

SSE (Legacy)#

• Support: Deprecated since 2024-11
• Use case: Legacy only
• Complexity: Higher
• Performance: Suboptimal

WebSocket#

• Support: Extension (mcp[ws])
• Use case: Real-time bidirectional
• Complexity: Higher
• Performance: Good for streaming

Auth Implementations#

OAuth 2.1 (Standard)#

• Built into spec since 2025-03-26
• RFC 9728 compliance
• Resource indicators (RFC 8707)

FastMCP Enterprise Auth#

• Google, GitHub, Azure, Auth0, WorkOS
• Zero-configuration OAuth providers
• Additional to spec

Custom Auth#

• API keys
• JWT tokens
• Custom schemes (not spec-compliant)

Compatibility Matrix#

Migration Paths#

From Custom Integration#

Custom LLM Integration
         │
         ▼ (20-80 hours)
   MCP Server (FastMCP)
         │
         ▼ (0 hours)
   Works with all MCP clients

From REST API#

FastAPI REST API
         │
         ▼ (2-8 hours)
   FastAPI-MCP or FastMCP.from_fastapi()
         │
         ▼ (0 hours)
   Dual REST + MCP support

Between SDKs#

FastMCP Server
         │
         ▼ (1-2 hours, import changes)
   MCP SDK Server
         │
         ▼ (0 hours)
   Same clients work

Interoperability Evidence#

Cross-Vendor Testing#

Protocol Compliance#

All major implementations pass MCP protocol test suites:

• Tool registration
• Resource access
• Prompt handling
• Transport negotiation
• Auth flows (2025-03+)

Sources#

• MCP GitHub Organization
• FastMCP GitHub
• Google Managed MCP
• AWS MCP Servers
• One Year of MCP

2.074 MCP Protocol - S1 Recommendations#

Research Date: December 2025 Category: 2.0XX Open Standards & Portability Layer Status: S1 Complete

Executive Summary#

MCP qualifies as a 2.xxx Open Standard. Despite being only one year old, MCP has achieved:

• Vendor-neutral governance (Linux Foundation)
• Multi-vendor adoption (OpenAI, Google, Microsoft, AWS)
• Production maturity (4 spec versions, 97M+ downloads)
• True portability (protocol-level, any client)

Recommendation: Adopt MCP for LLM tool integration. Lock-in risk is LOW.

Decision Framework#

When to Adopt MCP#

When to NOT Adopt MCP#

Implementation Recommendations#

For New Projects#

1. Use FastMCP 2.0 (see 1.210 research)

   • Simplest path to MCP compliance
   • Enterprise auth built-in
   • Well-documented

2. Start with stdio transport

   • Simplest for development
   • Works with Claude Desktop immediately

3. Use standard OAuth 2.1 for production auth

   • Spec-compliant since 2025-03-26
   • Avoid proprietary auth

For Existing Systems#

For Multi-Agent Systems#

┌─────────────────────────────────────────────────────────┐
│  Multi-Agent Architecture                                │
│                                                          │
│   Agent A ◄──── A2A ────► Agent B                       │
│      │                        │                          │
│     MCP                      MCP                         │
│      │                        │                          │
│      ▼                        ▼                          │
│   Tools/Data              Tools/Data                     │
│                                                          │
│  • A2A for agent-to-agent (horizontal)                  │
│  • MCP for agent-to-tool (vertical)                     │
└─────────────────────────────────────────────────────────┘

Portability Strategy#

Maximize Portability#

1. Stick to core primitives: Tools, Resources, Prompts
2. Use standard transports: stdio, Streamable HTTP
3. Avoid client-specific features: Don’t rely on Claude-only capabilities
4. Document tool schemas: Enable any client to understand your server

Test with Multiple Clients#

SDK Portability#

All major Python SDKs implement the same protocol:

# FastMCP 2.0
from fastmcp import FastMCP
mcp = FastMCP("server")

# Official SDK
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("server")

# Same protocol, same clients work

Risk Assessment#

Low Risk Factors#

Residual Risks#

Comparison to Other 2.xxx Standards#

Assessment: MCP is younger but has faster adoption than most standards at the same age.

Versioning Strategy#

Current Spec Versions#

Recommendation#

• Target: 2025-06-18 or later for new projects
• Minimum: 2025-03-26 (OAuth 2.1, Streamable HTTP)
• Avoid: 2024-11-05 (missing auth, deprecated SSE)

Summary#

Sources#

• MCP joins Agentic AI Foundation
• Linux Foundation AAIF Announcement
• MCP Specification
• MCP vs A2A Comparison
• A2A and MCP Complementary

2.074 MCP — Refresh 2026-08-04#

Trigger: Freshness sweep — August 2026 (issue #26), flagged highest priority. Closes the watch timer set by the July sweep (issue #24): “schedule an S-tier pass for July 28+ to pin RC → final and verify no protocol deltas from the 10-week SDK feedback window.” Verified against: the official 2026-07-28 changelog and blog, 2026-08-04.

Headline#

The 2026-07-28 specification shipped on schedule (28 July 2026). It supersedes 2025-11-25 and is, per the MCP blog, “the largest revision to the protocol since launch.” Beta SDKs for Python, TypeScript, Go, and C# are available; the official C# SDK has shipped v2.0.

Verdict on the RC → final question: there ARE protocol deltas. The 10-week feedback window was not cosmetic. Anyone working from the May RC summaries — including several widely-cited secondary write-ups — carries at least three wrong details, listed under RC-era corrections below. The survey’s current_version moves 2025-11-25 → 2026-07-28.

The architectural change: MCP is now stateless#

This is the change everything else follows from.

Sessions are gone. Protocol-level sessions and the Mcp-Session-Id header are removed from the Streamable HTTP transport (SEP-2567). List endpoints (tools/list, resources/list, prompts/list) no longer vary per connection. Servers needing cross-call state use explicit, server-minted handles passed as ordinary tool arguments — state becomes application data rather than a transport concern.

The handshake is gone. The initialize / notifications/initialized exchange is removed (SEP-2575). Every request now carries its protocol version and client capabilities in _meta:

• io.modelcontextprotocol/protocolVersion
• io.modelcontextprotocol/clientCapabilities
• io.modelcontextprotocol/clientInfo (clients SHOULD identify themselves per request)
• io.modelcontextprotocol/serverInfo (servers SHOULD identify themselves in each result’s _meta)

Version mismatches return UnsupportedProtocolVersionError.

Operational consequence: a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. This materially lowers the cost of hosting an MCP endpoint — the relevant change for small operators, and for the gateway layer (2.083), which can now route on headers without parsing bodies.

Required headers: Mcp-Method and Mcp-Name on Streamable HTTP POST requests, plus support for custom headers from tool parameters via x-mcp-header (SEP-2243).

server/discover — new, and it changes the discovery story#

Servers MUST implement a server/discover RPC advertising their supported protocol versions, capabilities, and identity. Clients MAY call it before any other request for up-front version selection, or use it as a backward-compatibility probe on STDIO (SEP-2575).

Scope it precisely. This is in-band discovery: you must already possess the endpoint URL to call it. It is not out-of-band discovery at a well-known URL, and it is not an equivalent of A2A’s signed agent cards at /.well-known/agent.json. A page still has no standard way to advertise “I have an MCP server, here it is” such that a client would find and offer to connect it. Endpoint discovery remains unsolved; capability discovery is now solved once you have the endpoint.

Other substantive protocol changes#

Multi Round-Trip Requests (MRTR) (SEP-2322) replaces server-initiated requests — roots/list, sampling/createMessage, elicitation/create. Servers return an InputRequiredResult (resultType: "input_required") whose inputRequests field carries what is needed; the client retries the original request with inputResponses. All results now carry a required resultType field ("complete" or "input_required"); results from earlier-protocol servers that omit it MUST be treated as "complete".

subscriptions/listen replaces the HTTP GET endpoint and resources/subscribe/resources/unsubscribe: one long-lived POST-response stream for opted-in change notifications (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions), tagged with io.modelcontextprotocol/subscriptionId. Request-scoped notifications (notifications/progress, notifications/message) still flow on their own request’s response stream.

Removed: ping, logging/setLevel, notifications/roots/list_changed. Log level is set per request via io.modelcontextprotocol/logLevel in _meta. Also removed: SSE stream resumability and message redelivery (Last-Event-ID, SSE event IDs) — a broken response stream now loses the in-flight request and the client MUST re-issue it with a new request ID.

Caching: ttlMs and cacheScope ("public"/"private") are now required on results from tools/list, prompts/list, resources/list, resources/read, and resources/templates/list via a new CacheableResult interface (SEP-2549). Servers SHOULD also return tools/list in a deterministic order to improve client-side caching and LLM prompt-cache hit rates.

Schema: inputSchema/outputSchema loosened to any JSON Schema 2020-12 keywords, with $ref resolution requirements and composition-keyword resource bounds (SEP-2106). Resource not-found error code moved -32002 → -32602.

Extensions become first class#

ClientCapabilities and ServerCapabilities gain an extensions field. Two official extensions ship alongside the core:

• Tasks (io.modelcontextprotocol/tasks, SEP-2663) — moved out of experimental core. Polling via tasks/get replaces the blocking tasks/result; tasks/update carries client-to-server input; tasks/list is removed; servers may return task handles unsolicited without per-request opt-in.
• MCP Apps (io.modelcontextprotocol/ui, SEP-1865) — reached Final. Servers ship interactive HTML that hosts render in a sandboxed iframe, with UI templates declared ahead of time so hosts can prefetch, cache, and security-review before anything runs. Host support has shipped in ChatGPT, Claude, Goose, and VS Code; servers exist from Shopify, Hugging Face, and ElevenLabs.

Neither is baked into the base SDK — a deliberate split between a small core and negotiated extensions.

Deprecations — the part most likely to bite implementers#

The revision adopts a feature lifecycle and deprecation policy (SEP-2596) defining Active / Deprecated / Removed states, a minimum twelve-month deprecation window, and a registry of deprecated features. Newly deprecated:

• Roots, Sampling, and Logging (SEP-2577). Functional during the window, but new implementations should not adopt them. Suggested migrations: pass directories/files as tool parameters, resource URIs, or server config instead of Roots; integrate directly with LLM provider APIs instead of Sampling; log to stderr or use OpenTelemetry instead of Logging.
• OAuth 2.0 Dynamic Client Registration (RFC 7591) — deprecated as a client registration mechanism in favour of Client ID Metadata Documents (CIMD), retained only for backwards compatibility with authorization servers that lack CIMD support.
• HTTP+SSE transport (deprecated since 2025-03-26) reclassified as Deprecated. Migrate to Streamable HTTP.
• includeContext values "thisServer" / "allServers" reclassified as Deprecated; they will be removed no later than Sampling itself.

The DCR → CIMD move is the one to watch: it changes the recommended answer to “how does a client register without out-of-band setup,” which is load-bearing for any argument about connect-step friction.

Authorization hardening#

Four changes tighten authorization-server confusion and token-misredemption defences:

• SEP-2468 — authorization servers SHOULD include iss per RFC 9207; clients MUST validate a present iss against the recorded issuer before redeeming the authorization code.
• SEP-837 — clients MUST specify an appropriate application_type during Dynamic Client Registration, avoiding OpenID Connect redirect-URI conflicts.
• SEP-2352 — client credentials are bound to the issuing authorization server: key persisted credentials by issuer identifier, never reuse across authorization servers, re-register when the authorization server changes.
• SEP-2351 — OpenID Connect discovery for authorization servers via .well-known.

Note this is the only .well-known usage in the revision, and it concerns authorization servers — not server capability discovery.

Process and governance#

• Feature lifecycle policy with a 12-month minimum deprecation window (SEP-2596) — the protocol now has a formal answer to “how long until this breaks.”
• PR-based SEP workflow formalised: markdown files in a seps/ directory, PR-derived numbering, sponsor responsibilities, status managed via PR labels (SEP-1850).
• Error code allocation policy: -32000–-32019 implementation-defined (existing SDK usage grandfathered), -32020–-32099 reserved for the specification. Codes introduced in this draft renumbered accordingly — HeaderMismatch -32001 → -32020, MissingRequiredClientCapability -32003 → -32021, UnsupportedProtocolVersion -32004 → -32022.
• OpenTelemetry trace context propagation conventions documented for _meta keys (traceparent, tracestate, baggage) (SEP-414).

Governance itself is unchanged: Agentic AI Foundation (Linux Foundation), MIT-licensed spec.

RC-era corrections#

Three claims that circulated from May-2026 RC coverage and are wrong against the final spec. Recorded because they appear in secondary sources and in at least one other survey in this repository:

1. There is no MCP-Protocol-Version header. The RC summaries described header-based version dispatch. In the final spec, only Mcp-Method and Mcp-Name are required headers; protocol version and client capabilities travel in _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities).

2. There are no “Server Cards.” No such feature exists in the revision, and there is no capability-discovery .well-known URL. The real mechanisms are the in-band server/discover RPC and — separately — OIDC discovery for authorization servers (SEP-2351). The name appears to be a conflation with A2A’s genuine agent cards.

3. Dynamic Client Registration is now deprecated, not the recommended path. RC-era framing presented DCR as the mechanism removing administrative setup; the final spec deprecates RFC 7591 DCR in favour of Client ID Metadata Documents.

Assessment#

No change to the 2.xxx verdict: MCP remains a governed open standard under the Linux Foundation’s Agentic AI Foundation, and this revision strengthens the case — a formal deprecation policy with a 12-month window and a formalised SEP workflow are exactly the process maturity a standard is judged on.

The direction of travel is consistent: a smaller stateless core, negotiated extensions, and cheaper hosting. Sessions, handshake, ping, logging, sampling, roots, and SSE resumability all left the core; extensions became first class. That is a protocol consolidating rather than accreting.

Next watch item: the twelve-month deprecation window means Roots, Sampling, Logging, and RFC 7591 DCR are removable from July 2027 at the earliest. Track whether the CIMD migration lands cleanly before then.

2.074 MCP Protocol - Standard Overview#

Research Date: December 2025 Category: 2.0XX Open Standards & Portability Layer Status: S1 Complete

Executive Summary#

MCP (Model Context Protocol) has achieved the maturity of a true open standard. In December 2025, Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation (AAIF), joining OpenAI, Google, Microsoft, AWS, and others in governance. With 97+ million monthly SDK downloads and adoption by all major AI platforms, MCP meets 2.xxx criteria for an open standard.

Verdict: MCP qualifies as a 2.xxx Open Standard despite its young age (1 year).

Standard Identity#

Governance Structure#

Pre-December 2025#

• Anthropic-controlled with community input
• SEP (Specification Enhancement Proposal) process
• Open-source development on GitHub

Post-December 2025 (Current)#

• Agentic AI Foundation (AAIF) under Linux Foundation
• Co-founders: Anthropic, Block, OpenAI
• Supporters: Google, Microsoft, AWS, Cloudflare, Bloomberg

Governance Model#

“The AAIF Governing Board will make decisions regarding strategic investments, budget allocation, member recruitment, and approval of new projects, while individual projects, such as MCP, maintain full autonomy over their technical direction and day-to-day operations.”

Key Point: Technical decisions remain with maintainers; strategic decisions with AAIF board.

Maturity Assessment#

2.xxx Criteria Evaluation#

Version History#

Adoption Metrics (December 2025)#

• 97+ million monthly SDK downloads
• 10,000+ active public servers
• 5,800+ registered MCP servers
• 300+ MCP clients

Major Adopters#

What MCP Standardizes#

Core Primitives#

1. Tools: Functions an LLM can invoke (like POST endpoints)
2. Resources: Read-only data access (like GET endpoints)
3. Prompts: Reusable message templates
4. Context: Session state and capabilities

Transports#

Protocol Details#

• Message Format: JSON-RPC 2.0
• Authentication: OAuth 2.1 (since 2025-03-26)
• Content Types: Text, Images, Audio (since 2025-03)
• Structured Output: Pydantic/TypedDict (since 2025-06)

What MCP Does NOT Standardize#

Related Protocols#

A2A (Agent-to-Agent Protocol)#

• Creator: Google (April 2025)
• Purpose: Agent-to-agent communication (horizontal)
• Relationship: Complementary to MCP (vertical)

ACP (Agent Communication Protocol)#

• Creator: IBM (BeeAI framework)
• Purpose: Inter-framework agent communication

Comparison#

Key Insight: MCP and A2A are complementary, not competing.

Lock-in Analysis#

Lock-in Risk: LOW#

Switching Costs#

What Could Cause Lock-in#

1. Vendor-specific extensions: Using non-standard features
2. Proprietary auth: Custom auth beyond OAuth 2.1
3. Client-specific features: Relying on Claude-only capabilities

Mitigation#

• Stick to core MCP primitives
• Use standard OAuth 2.1 auth
• Test with multiple clients

Portability Test#

Can you switch implementations via config only?

Conclusion: MCP passes the 2.xxx portability test.

Sources#

• MCP joins the Agentic AI Foundation
• Linux Foundation AAIF Announcement
• Anthropic Donation Announcement
• MCP Specification Changelog
• MCP Wikipedia
• GitHub Blog: MCP joins Linux Foundation
• One Year of MCP

S2 Approach — How MCP Actually Works#

Survey: 2.074 Pass: S2 Comprehensive Analysis Date: 2026-08-04 Protocol revision analysed: 2026-07-28 (current)

What Changed Since S1#

S1 was written in December 2025 against protocol revision 2025-11-25. Since then MCP has shipped the largest revision since launch — a revision that removes the session model, the handshake, and several core features, and moves others into negotiated extensions.

An S2 written against the old revision would describe a protocol that no longer exists. So this pass analyses 2026-07-28 as the subject and treats earlier revisions as migration context.

The S1 files are retained unedited as a point-in-time record, with a staleness banner where their figures would mislead.

The Organising Question#

MCP is usually explained as “USB-C for AI tools” — a universal connector between models and capabilities. That analogy gets the purpose right and the engineering wrong, because it implies the hard part is the plug shape. It isn’t.

The hard parts, and therefore this pass’s structure, are:

1. Where state lives when a protocol serves stateless HTTP infrastructure but stateful conversations. The 2026-07-28 revision is essentially one long answer to this.
2. How trust is established between a client and a server it did not write.
3. What happens to trust after connection — the question the security literature says MCP answers badly.
4. How the protocol grows without the core growing.

Files in This Pass#

Method and Sourcing#

Protocol claims are taken from the official 2026-07-28 changelog and specification, with SEP numbers cited inline so any claim can be traced to its enhancement proposal. Version and ecosystem figures are taken from package registries (PyPI, npm) and the GitHub API rather than from announcements or secondary write-ups.

That sourcing discipline is not boilerplate here. Preparing this survey’s August 2026 refresh found three widely-repeated claims about this exact revision that are false — a MCP-Protocol-Version header that does not exist, a “Server Cards” discovery feature that does not exist, and Dynamic Client Registration described as the recommended path when the revision deprecates it. All three originate in coverage of the May release candidate, which differed from what shipped. Where this pass relies on a secondary source, it says so.

Code in This Pass#

Wire formats and method names appear where the shape of a message clarifies a concept that prose states less precisely. There are no tutorials, no SDK walkthroughs, and no setup instructions — those belong to 1.210 (MCP Server Implementation), not to a standards survey.

Authorization — OAuth 2.1, and What the Hardening Reveals#

Verified: 2026-08-04

The Baseline Requirement#

Since the 2025-11-25 revision, any MCP server reachable over the internet must implement OAuth 2.1 with PKCE using the S256 method. The specification states this without exception.

That is a strong stance for a protocol barely a year old at the time. It means there is no sanctioned API-key mode for remote servers, no “just use a bearer token,” and no gradual on-ramp. Custom auth schemes exist in the wild but are outside the specification, and a client encountering one is dealing with a non-compliant server.

The stringency is deliberate. An MCP server is not an ordinary API: it is an endpoint an autonomous agent will call on a user’s behalf, with the user absent. The authorization decision has to be explicit, scoped, and revocable precisely because nobody will be watching at invocation time.

The 2026-07-28 Hardening#

Six SEPs tightened authorization in the current revision. Four matter architecturally:

Read together, these are authorization-server confusion and token-misredemption defences — the failure class where a client is induced to send a token intended for one server to another.

What that implies is more interesting than the SEPs themselves. A protocol receives this kind of attention only when it is deployed in adversarial, multi-tenant environments where multiple authorization servers coexist and an attacker can influence which one a client talks to. Specifications do not spend a revision on RFC 9207 conformance speculatively. This is evidence of real production deployment at a scale where the subtle OAuth attacks became reachable.

Note also that SEP-2351 is the only .well-known usage in this revision, and it concerns authorization servers. It is routinely misreported as capability discovery for MCP servers. It is not — see protocol-architecture.md.

The DCR → CIMD Shift#

The revision deprecates OAuth 2.0 Dynamic Client Registration (RFC 7591) as a client registration mechanism, in favour of Client ID Metadata Documents. DCR remains available only for backwards compatibility with authorization servers that do not support CIMD.

This matters more than a typical deprecation because DCR was load-bearing in how MCP’s onboarding story was told. The pitch was: no pre-registered client ID, no out-of-band setup between the server operator and the AI vendor — the client registers itself on the fly. DCR was the mechanism that made “connect a server with a single Google or GitHub login, no JSON configuration” true.

CIMD achieves a similar end differently: rather than the client registering itself at runtime, it publishes a metadata document the authorization server can fetch and verify. The trust anchor moves from an act of registration to a document at a URL the client controls, which is more auditable and less prone to the redirect-URI conflicts SEP-837 addresses.

Anyone repeating the DCR framing today is describing the legacy path. Managed identity providers still cover the full surface — PKCE, Resource Indicators, Protected Resource Metadata — so the user experience of one-click connection is unchanged. The mechanism underneath is not.

The Connect Step Is a Floor, Not Friction#

The most important architectural point about MCP authorization is what it does not try to optimise away.

Every change in this revision makes the connect step smoother, better specified, and harder to attack. None makes it optional. Dynamic registration — and now CIMD — removes the administrative prerequisite. What neither removes is the authorization grant: a human deciding, in an authorization-server interface, that this client may act for them.

That is not latency awaiting optimisation. It is the security property being purchased. OAuth exists to make delegation explicit and revocable; a version without a deliberate human decision would not be OAuth, it would be a shared secret with extra steps.

The consequence is structural and worth stating plainly, because it bounds where MCP can be used at all: a remote MCP server cannot serve an anonymous, first-time user. A mechanism requiring an authorization grant before delivering any value is disqualified from first contact by construction. Survey 2.078 traces what fills that gap for page-to-AI handoff; for MCP the relevant conclusion is that its addressable population is users who have already committed to a relationship, and that no amount of specification work changes this.

stdio and the Local Exception#

The OAuth requirement applies to servers reachable over the internet. Local stdio servers — subprocesses launched by the client on the user’s own machine — sit outside it.

This is coherent: a subprocess the user’s client spawned inherits the user’s authority directly, and interposing OAuth between a process and its own child would be ceremony without a trust boundary.

It is also where most MCP servers actually run, which produces a notable asymmetry: the best-specified part of MCP’s security model applies to the minority of deployments. The local case is governed by operating-system process permissions and by whatever the user consented to when they added the server to their configuration — which is exactly the surface the rug-pull attacks in security-model.md exploit.

Assessment#

Authorization is the strongest-specified area of MCP and the clearest evidence of the protocol’s maturity. It mandates modern practice (OAuth 2.1, PKCE/S256, RFC 9207 issuer validation), it has been hardened in response to real deployment conditions, and it is backed by mature identity infrastructure rather than bespoke mechanisms.

Its limits are equally clear. It establishes who a server is and what a client may do on a user’s behalf. It says nothing about whether a verified server’s tool descriptions deserve the model’s trust — which is where the actual attacks live.

Extensions — How MCP Grows Without the Core Growing#

Verified: 2026-08-04

The Mechanism#

The 2026-07-28 revision adds an extensions field to both ClientCapabilities and ServerCapabilities, making optional capabilities beyond the core protocol a negotiated, first-class concept rather than an informal convention.

The pairing with the stateless-core work is not coincidental. The revision simultaneously shrank the core — removing sessions, handshake, ping, logging control, server-initiated requests — and created a sanctioned place to put things that are not core. Features did not simply disappear; several moved.

This is a protocol adopting the architecture that lets it stay small while its ecosystem gets large. The core becomes the part every implementation must get right; everything else becomes opt-in and independently versioned.

Tasks (io.modelcontextprotocol/tasks)#

Long-running work, graduated out of experimental core into an official extension (SEP-2663).

The lifecycle:

• tools/call returns a task handle instead of blocking for a result.
• Clients drive progress with tasks/get (polling), tasks/update (client-to-server input), and tasks/cancel.
• The blocking tasks/result method was replaced by polling via tasks/get.
• tasks/list was removed.
• Servers may return task handles unsolicited, without per-request opt-in.

Two design choices deserve attention.

Polling replaced blocking, which is the stateless principle applied again: a blocking call holds a connection and therefore holds state at both ends. Polling costs round trips and buys the ability for any instance to answer.

tasks/list was removed, and this is the more informative deletion. Without it, a client cannot enumerate tasks it does not already hold handles for — task discovery is deliberately not a protocol feature. Handles function as capabilities: holding one is the authority to inspect the task. That is a coherent security model for a stateless protocol (there is no session to scope a listing to, so a listing would need its own authorization semantics), and it pushes correlation onto the client, which must remember what it started.

Unsolicited handles are the pragmatic concession: a server that discovers mid-call that work will take a while can hand back a handle without the client having asked for asynchrony up front.

MCP Apps (io.modelcontextprotocol/ui)#

Servers ship interactive HTML that hosts render in a sandboxed iframe, communicating back over the same JSON-RPC protocol as direct tool calls (SEP-1865). Tools declare their UI templates ahead of time, so hosts can prefetch, cache, and security-review them before anything runs.

MCP Apps reached Final and ships as an official extension — not core, and not in the base SDK.

Host support has shipped in ChatGPT, Claude, Goose, and VS Code, with servers from Shopify, Hugging Face, and ElevenLabs. That is unusually broad for a capability this new, and it is a stronger cross-vendor signal than most of MCP’s core features have.

Architecturally this inverts the usual direction of integration. Everything else in MCP moves capability into the model’s reach. MCP Apps move the service’s interface into the AI client — the user does not go to the service, the service’s UI comes to them.

The ahead-of-time declaration requirement is the same containment instinct visible throughout the current generation of agent protocols: constrain what an untrusted party can introduce at runtime, because runtime-introduced content is where these systems get attacked. It is the direct analogue of WebMCP’s character budgets and of prefill-not-send in deep links (see 2.078), arrived at independently.

Deprecations Feeding the Extension Model#

The revision deprecates three core features under SEP-2577, with suggested migrations:

Also deprecated: the HTTP+SSE transport (deprecated since 2025-03-26, now formally reclassified), and the includeContext values "thisServer" / "allServers".

Look at what these three have in common. Roots let the server ask about the client’s filesystem; Sampling let the server use the client’s model; Logging let the server control the client’s log level. Each inverted the normal direction of control — the server reaching into the client’s environment. All three are gone in the same revision that removed server-initiated requests.

The migrations tell a consistent story: pass what the server needs as explicit data, and let the server use its own resources rather than borrowing the client’s. Sampling in particular was MCP’s most ambitious idea — a server could ask the client’s model to think for it, without its own API key — and its deprecation is a real narrowing of the protocol’s scope in exchange for a much simpler trust and billing model.

Feature Lifecycle Policy#

Underpinning all of this, the revision adopts a feature lifecycle and deprecation policy (SEP-2596) defining:

• Three states: Active, Deprecated, Removed.
• A minimum twelve-month deprecation window.
• A published registry of deprecated features.

This is the governance change that makes the aggressive deprecation defensible. Removing Sampling, Roots, Logging, HTTP+SSE, and DCR in one revision would be reckless without a guaranteed window; with one, implementers have a bounded, published migration schedule.

Practical consequence: nothing deprecated in 2026-07-28 can be removed before July 2027 at the earliest. That is the planning horizon for anyone depending on those features.

Assessment#

The extension mechanism is the most strategically significant thing in this revision after the stateless core, and the two are the same move viewed from different angles: shrink what is mandatory, formalise what is optional.

It gives MCP a way to absorb ambitious capabilities — server-rendered UI, long-running work — without every implementation having to support them, and gives implementers a defensible answer to “must I build this?” Tasks and MCP Apps are strong first citizens: both are genuinely useful, both would have bloated a core protocol, and MCP Apps already has multi-vendor host support.

The risk is the usual one for extension systems: fragmentation. If important capabilities live in extensions that only some hosts implement, “MCP-compatible” stops being a single meaningful claim and becomes a matrix. The extensions capability field makes that matrix negotiable rather than guessable, which is the right mitigation, but it does not prevent the ecosystem from splitting along extension lines.

Implementation Landscape — August 2026#

Verified: 2026-08-04 against PyPI, npm, and the GitHub API. Supersedes the December 2025 figures in ../S1-rapid/implementation-landscape.md.

Official SDKs#

The most significant change since S1 is not a version bump. It is that five languages beyond Python and TypeScript now have official SDKs under the modelcontextprotocol GitHub organisation. S1’s characterisation of Go, C#, and Rust as “emerging community SDKs” is obsolete.

Current package versions:

The Python SDK’s 2.0.0 is the number to notice. A major version aligns with a protocol revision that removed the session model and the handshake — the SDK could not have absorbed that without breaking changes. Anyone pinned to the 1.x line is on the pre-stateless protocol.

Beta SDKs for Python, TypeScript, Go, and C# accompanied the spec release, and the C# SDK has since shipped a v2.0.

Five of six repositories were pushed to on the day of verification. Java’s ten-day gap is the only visible lag and is not obviously meaningful at this sample.

FastMCP#

FastMCP — the high-level Python framework from Prefect — is at 3.4.5, up from the 2.14 S1 recorded. It remains the most prominent third-party layer, offering ergonomics above the official SDK plus enterprise auth integrations (Google, GitHub, Azure, Auth0, WorkOS) that the specification does not mandate.

Its position is worth stating precisely because it is easy to misread: FastMCP is not a competing protocol implementation. It is a developer-experience layer over the same wire format, so servers built with it interoperate normally. The choice between FastMCP and the official SDK is an ergonomics and support decision, not a compatibility one.

The Official Registry#

modelcontextprotocol/registry (7,103 stars, last push 2026-07-29) is the official server registry — a real piece of ecosystem infrastructure that did not exist when S1 was written.

Scale, from secondary analyses with differing methodologies:

Treat the 96,771 figure carefully. It aggregates five directories with overlapping contents and no deduplication guarantee, and it sits an order of magnitude above the official registry’s own count. A defensible reading: roughly ten thousand registry-quality servers, tens of thousands of published-somewhere servers, and a long tail beyond that. The growth from ~50 servers at launch in November 2024 is not in dispute.

Note the registry’s relationship to the protocol. server/discover answers “what can this server do?” once you hold its URL; the registry is the out-of-band layer that helps you find the URL. That function lives in ecosystem infrastructure, not in the specification — which is why protocol-architecture.md records endpoint discovery as unaddressed at the protocol level even though a registry exists.

Clients and Hosts#

MCP consumption is genuinely cross-vendor, which remains its strongest claim. First-party documentation or announcements of MCP support exist from Anthropic, OpenAI, Google, Microsoft, GitHub, Vercel, VS Code, and Cursor.

The MCP Apps extension gives a sharper read on host maturity, since it requires real implementation work beyond tool calling: ChatGPT, Claude, Goose, and VS Code have shipped support, with servers from Shopify, Hugging Face, and ElevenLabs.

That two direct competitors — Anthropic and OpenAI — both consume MCP and both implement the same optional UI extension is the single best evidence that MCP functions as a standard rather than as one vendor’s integration surface.

Managed Infrastructure#

Cloud vendors ship first-party MCP servers for their own services: Google (Maps, BigQuery, Compute Engine, Kubernetes Engine), AWS (Lambda, ECS, EKS, Fargate, Bedrock integration). Hosted deployment platforms exist, including FastMCP Cloud.

Strategically this is the “agent-ready by design” posture — cloud providers treating MCP endpoints as a standard surface for their services, comparable to shipping a REST API. It is also a concentration risk of the kind security-model.md notes: the Smithery path-traversal incident exposed 3,000+ credentials through the aggregator, not through any individual server.

Interoperability#

The core interoperability claim holds: any MCP server works with any MCP client, and switching clients requires no server changes. This is the property the whole standard exists to deliver, and cross-vendor client support is what makes it real rather than aspirational.

Two qualifications the S1 compatibility matrix did not need:

Protocol revision now matters. With 2026-07-28 removing sessions, the handshake, and several core features, “speaks MCP” is no longer a single claim. A client and server on either side of that boundary are not straightforwardly compatible, which is what server/discover and the required protocol version in _meta exist to negotiate.

Extensions fragment the claim. A host supporting core MCP but not io.modelcontextprotocol/ui is fully compliant and cannot render an MCP App. “MCP-compatible” has become a matrix rather than a boolean — negotiable via the extensions capability field, but a matrix nonetheless.

Assessment#

The implementation ecosystem is substantially more mature than S1 documented, and the growth is in the dimension that matters for a standard: not raw server count, but independent implementations across languages and vendors. Six official SDKs, cross-vendor client support including direct competitors, first-party cloud servers, and an official registry are the markers of a standard with a real ecosystem rather than a vendor protocol with adopters.

The counterweight is quality distribution. The same ecosystem scale that demonstrates success also means most public servers are unaudited software written quickly against an API — which is what the prevalence figures in security-model.md measure.

Protocol Architecture — The Stateless Core#

Revision: 2026-07-28 Verified: 2026-08-04 against the official changelog

The Central Design Move#

Every significant change in this revision follows from one decision: MCP stopped being a stateful session protocol and became a request/response one.

Before, a client opened a connection, performed an initialize handshake, received a session identifier, and conducted a conversation within that session. The server held context. List results could vary per connection. Notifications flowed on a long-lived channel bound to the session.

Now there is no session, no handshake, and no server-held conversational context. Each request carries what it needs.

This is the single most consequential fact about MCP’s architecture, and it inverts the usual trajectory. Protocols normally accrete state as they mature. MCP shed it.

What Was Removed#

Reading that table as a list of deletions understates it. Roughly every mechanism that required the server to remember or initiate something is gone.

The New Request Model#

Two required headers on Streamable HTTP POST requests carry routing (SEP-2243):

Mcp-Method: tools/call
Mcp-Name: summarize_document

Everything else that used to be negotiated now rides in _meta on each request:

Version mismatches return UnsupportedProtocolVersionError.

Note what this costs. Every request now repeats the version and capability payload that a handshake would have established once. That is real per-request overhead, traded deliberately for the ability to route any request to any instance. It is the same bargain REST made against session-oriented predecessors, and MCP made it for the same reason: horizontal scaling beats per-request efficiency when the bottleneck is operational, not computational.

x-mcp-header additionally allows custom headers to be supplied from tool parameters.

server/discover#

Servers MUST implement a server/discover RPC advertising supported protocol versions, capabilities, and identity (SEP-2575). Clients MAY call it before any other request to select a version up front, or use it as a backward-compatibility probe on STDIO.

This is what replaces the handshake’s negotiation function — but as an optional, cacheable query rather than a mandatory, per-connection ceremony. A client that already knows what it is talking to can skip it entirely.

Scope it precisely, because this is widely misreported. server/discover is in-band: it answers “what can this server do?” and requires that you already hold the server’s URL. It is not discovery at a well-known URL, and it is not equivalent to A2A’s signed agent cards at /.well-known/agent.json (see 2.075). How a client comes to hold the URL at all remains outside the protocol — in practice a copy-pasted string from documentation, a registry entry, or a configuration file.

There is no “Server Cards” feature. That name appears in secondary coverage of this revision and corresponds to nothing in the specification.

Multi Round-Trip Requests (MRTR)#

The protocol previously let servers initiate requests back at clients — asking for filesystem roots, asking the client’s model to sample, eliciting user input. Server-initiated requests require the server to know how to reach the client, which is precisely what a stateless model cannot guarantee.

MRTR (SEP-2322) inverts it. A server needing more information returns an InputRequiredResult rather than calling back:

{
  "resultType": "input_required",
  "inputRequests": [ /* what the server needs */ ]
}

The client then retries the original request, supplying inputResponses. The conversation becomes a sequence of complete request/response pairs, each independently routable.

Consequently all results now carry a required resultType — "complete" or "input_required". Results from earlier-protocol servers that omit the field MUST be treated as "complete".

The elegance is real, and so is the cost: the client now owns the state machine. It must remember what it was doing across retries, since the server does not. Servers needing to correlate an interaction across retries encode their own identifier in requestState — which is the same “explicit handles as ordinary arguments” pattern that replaced sessions, applied again. The pattern is the revision’s signature: if state is needed, make it visible data rather than invisible context.

Notifications After the Session#

With the GET endpoint gone, opted-in server-to-client notifications flow over subscriptions/listen — a single long-lived POST-response stream. Clients opt in to specific types (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions), the server acknowledges, and notifications are tagged with io.modelcontextprotocol/subscriptionId.

Request-scoped notifications — notifications/progress, notifications/message — do not use this stream. They continue to flow on the response stream of the request they relate to, which keeps them correlated without a session.

Servers MUST NOT emit notifications/message for requests that did not set io.modelcontextprotocol/logLevel. Logging is now opt-in per request rather than a connection mode.

Caching as a First-Class Concern#

A stateless protocol re-fetches things a session would have held, so the revision makes caching explicit. ttlMs and cacheScope are required on results from tools/list, prompts/list, resources/list, resources/read, and resources/templates/list via a CacheableResult interface (SEP-2549):

• ttlMs — freshness hint in milliseconds, letting clients cache and reduce polling.
• cacheScope — "public" or "private", controlling whether shared intermediaries may cache.

Both complement the existing listChanged notifications rather than replacing them. Servers SHOULD also return tools/list in a deterministic order — not for tidiness, but because tool lists enter the model’s prompt, and a stable order improves LLM prompt-cache hit rates.

That detail is worth pausing on: it is a protocol requirement that exists because of how inference billing works, not how networking works. It is a small, clear sign that MCP is designed against the economics of the thing consuming it.

Schema and Errors#

inputSchema and outputSchema were loosened to permit any JSON Schema 2020-12 keywords, and structuredContent to permit any JSON value, with $ref resolution requirements and composition-keyword resource bounds (SEP-2106).

Error codes gained an allocation policy: -32000–-32019 remains implementation-defined (existing SDK usage grandfathered), -32020–-32099 is reserved for the specification. Codes introduced in this draft were renumbered accordingly (HeaderMismatch → -32020, MissingRequiredClientCapability → -32021, UnsupportedProtocolVersion → -32022). Resource-not-found moved from -32002 to -32602 (Invalid Params) to align with JSON-RPC.

Error-code partitioning is unglamorous and is exactly the kind of thing a protocol does once it has enough independent implementations for collisions to hurt.

Architectural Assessment#

The revision is coherent. It is not a grab-bag: sessions, handshake, server-initiated requests, SSE resumability, and per-connection list variance were all removed because each of them assumed a connection with memory, and the replacements — handles, _meta, MRTR, subscriptions/listen, CacheableResult — are all instances of one principle.

What it optimises for: operational simplicity at the server, horizontal scale, and cheap participation. A server that needed sticky sessions, a shared session store, and deep packet inspection at the gateway now runs behind a plain round-robin load balancer.

What it costs: per-request overhead, a heavier client, and a real migration burden for existing implementations. Roots, Sampling, and Logging are deprecated on top of everything else (see extensions.md), so the client-side surface changed as much as the server-side did.

Who benefits: server operators, disproportionately. That is a deliberate bet — MCP’s value scales with how many servers exist, so lowering the cost of running one is the highest-leverage change available. The corresponding bet is that client implementers, who are far fewer and mostly well-resourced vendors, can absorb the added complexity.

S2 Synthesis — What the Architecture Says About MCP#

Survey: 2.074 Pass: S2 Comprehensive Analysis Revision analysed: 2026-07-28 Verified: 2026-08-04

One Principle Explains the Revision#

Almost every change in 2026-07-28 is the same move: if state is needed, make it visible data rather than invisible context.

Once seen, the revision stops looking like a list of breaking changes and starts looking like a single refactor applied consistently. That coherence is a maturity signal in itself — protocols usually change by accretion, not by principle.

What MCP Optimises For#

Server operators, deliberately and disproportionately. The stateless core, header-based dispatch, and explicit caching all reduce the cost of running a server: no sticky sessions, no shared session store, no deep packet inspection at the gateway, plain round-robin load balancing.

The logic is sound. MCP’s value scales with how many servers exist, so lowering the cost of running one is the highest-leverage change available. The corresponding bet is that client implementers — far fewer, mostly well-resourced vendors — can absorb the complexity that moved to them. MRTR in particular makes the client own a state machine the server used to hold.

The tools/list deterministic-ordering requirement is the sharpest illustration of who this protocol is designed for: a wire-format rule that exists to improve LLM prompt-cache hit rates. That is a protocol shaped by inference economics, not networking convention.

The Three Structural Facts#

1. MCP is two protocols sharing a message format. A local subprocess protocol governed by OS permissions and user trust, and a remote web protocol governed by OAuth and cacheable statelessness. The specification’s most sophisticated machinery addresses the remote case; the majority of deployments are stdio. Most confusion about MCP’s security or scalability comes from applying a claim about one to the other.

2. Perimeter security is strong; interior security is unaddressed. Authorization is genuinely well-specified — OAuth 2.1 with mandatory PKCE, RFC 9207 issuer validation, issuer-bound credentials, DCR superseded by CIMD. None of it touches trust inheritance: a connected server retains standing permission to write into the model’s reasoning context, and tool descriptions are prompt content. The protocol answers “is this the server I think it is?” and has no answer to “should I still trust what it tells my model today?”

3. Discovery is half-solved. server/discover answers what a server can do once you hold its URL. Nothing in the protocol says how you come to hold the URL. That function lives in ecosystem infrastructure — the official registry, documentation, configuration files — not in the specification. There is no .well-known capability document; the sole .well-known usage concerns authorization servers (SEP-2351).

What MCP Gave Up#

The deprecations are a real narrowing of ambition, and they point one direction:

• Sampling — a server could ask the client’s model to think for it, without its own API key. This was MCP’s most ambitious idea and its most interesting economic property. Deprecated; migrate to your own provider API.
• Roots — the server could ask about the client’s filesystem. Deprecated; pass paths as parameters.
• Logging — the server could control the client’s log level. Deprecated; use stderr or OpenTelemetry.
• Server-initiated requests generally — replaced by MRTR.

Every one of these let the server reach into the client’s environment. MCP has decided that servers provide capability and consume nothing. Simpler to reason about, simpler to secure, simpler to bill — and meaningfully less powerful than what was originally proposed.

The twelve-month deprecation window (SEP-2596) is what makes this defensible rather than reckless. Nothing deprecated here can be removed before July 2027.

Where the Next Work Will Be#

The architecture points at two gaps, one urgent:

Trust continuity (urgent). Documented rug pulls (Postmark, September 2025), tool shadowing, and description poisoning share one cause the specification does not address. The mitigations proposed in adjacent research — origin-bound immutable tool identity, lifecycle consistency validation, traceable registration and invocation logs — apply directly. The required ttlMs/cacheScope and deterministic ordering give clients a cheap place to detect tool changes, which is the closest the spec comes; nothing requires them to look.

Endpoint discovery (tractable). A2A’s signed agent cards at /.well-known/agent.json are a worked, governed model for out-of-band capability discovery with cryptographic provenance. MCP has no equivalent. This is smaller and better-understood than trust continuity, and provenance signing would partially serve both.

Handoffs#

To S3: the selection axis is deployment topology and trust posture, not use case. stdio versus remote determines which half of the specification applies, and whether the user is committed enough to complete an authorization grant determines whether remote MCP is reachable at all. Personas should be built on those axes.

To S4: three questions the architecture poses but cannot settle.

1. Does the trust-inheritance gap get closed by the specification, by hosts, or by registries — and what happens to adoption if a serious incident lands first?
2. Does the extension mechanism keep the ecosystem coherent, or does “MCP-compatible” fragment into a capability matrix?
3. Was giving up Sampling and server-initiated capability the right narrowing, or does it cede ground to protocols willing to keep them?

Security Model — Trust Inheritance and Its Consequences#

Verified: 2026-08-04

The Structural Problem#

MCP’s security literature converges on one finding, and it is not about any particular bug:

MCP clients inherit trust from the servers they connect to, without continuous verification of that trust.

Three named attack classes — tool description poisoning, rug pulls, and tool shadowing — share that single structural cause. They are not implementation defects that patching individual servers resolves; analysts describe tool poisoning as rooted in architectural trust-model design, not a CVE class.

The mechanism is specific to how models consume MCP. A tool description is not documentation — it is prompt content. The model reads names, descriptions, and parameter schemas to decide whether and how to call a tool. Anything that can write those fields can write into the model’s context. Ordinary API design keeps interface documentation and executable behaviour in separate trust domains; MCP collapses them, because the consumer is a language model rather than a compiler.

The Attack Classes#

Tool description poisoning. Adversarial instructions embedded in tool descriptions, parameter schemas, or response content — all of which the agent treats as trusted operational context. The tool can behave exactly as advertised while its description instructs the model to do something else first.

Rug pulls. A server ships clean, earns trust and installs, then pushes an update adding poisoned content. Hosts reload tool descriptions without re-prompting the user, so the trust decision the user made is silently re-scoped to code they never reviewed. Same package name, same publisher, different behaviour.

Tool shadowing. A malicious server defines tools that impersonate or override another server’s, exploiting the fact that the model chooses among tools by description rather than by provenance. First documented by Invariant Labs against GitHub and WhatsApp MCP integrations in 2025.

Documented Incidents#

Not hypothetical. Two well-sourced cases anchor the discussion:

Postmark (September 2025) — the maintainer of the official Postmark MCP server added BCC logic silently copying every sent email to an attacker-controlled address. A textbook rug pull: previously-clean code, then malicious code, same package name, same publisher. The trust signal users relied on — official server, established publisher — was exactly the signal that failed.

Smithery path traversal — a vulnerability in the Smithery platform exposed 3,000+ credentials. Notable because the failure was in the aggregator rather than in any individual server: concentrating servers behind a directory concentrates the blast radius too.

The first malicious MCP package was identified in September 2025 — roughly ten months after launch, which is fast for an ecosystem to attract targeted supply-chain attacks and reflects how quickly MCP reached enough deployment to be worth attacking.

Prevalence#

Several independent scans put numbers on it. These come from secondary analyses with differing methodologies and sample frames, so treat them as indicative of magnitude rather than precise:

Even discounting heavily for methodology, the direction is unambiguous: the median public MCP server is not a hardened piece of software. Most were written quickly to expose an existing API, by authors who were not thinking about an adversarial model reading their tool descriptions.

OWASP now publishes an MCP Security Cheat Sheet, and the Cloud Security Alliance has a research note on tool poisoning — the ecosystem markers of a threat class that has become mainstream rather than exotic.

What the Protocol Does and Does Not Address#

The 2026-07-28 revision hardens authorization substantially (see authorization.md): issuer validation per RFC 9207, issuer-bound credentials, application_type declaration, and the move from Dynamic Client Registration to Client ID Metadata Documents. Those close real attack paths — authorization-server confusion and token misredemption.

They do not touch trust inheritance. Every hardening SEP concerns proving who the server is. None concerns what the server’s tool descriptions are allowed to say to the model, or what happens when a verified server changes its tools after you trusted it.

That gap is the security story. MCP now has strong answers to “is this really the server I think it is?” and no protocol-level answer to “should I still trust what it tells my model today?”

There is one partial exception worth noting: the revision’s ttlMs / cacheScope and deterministic tool ordering make list results explicitly cacheable. A client that caches tool definitions has, incidentally, a place to detect that they changed. The protocol does not require that comparison, but it makes it cheap — which is the closest the spec comes to a rug-pull defence.

The Comparison That Clarifies It#

Survey 2.078 analyses WebMCP, where pages register tools for browser-attached agents. Independent security research there (Mid-Session Tool Injection, NYCU 2026) found tool hijacking succeeding 94–100% of the time and tool framing — manipulating names, descriptions, and hints — succeeding 36–85% while preserving task completion 81–85% of the time, so the user sees a normal outcome while data leaks.

The same structural weakness, reached independently by a different team on a different transport. Both systems let an untrusted party write the metadata a model reasons over, and both discovered that metadata manipulation is stealthier than behaviour manipulation.

The proposed mitigations in that literature — binding tool identity to origin with immutable IDs, lifecycle consistency validation, and traceable registration/invocation logs — map cleanly onto MCP’s problem. None is in either specification.

Practical Posture#

Since the protocol does not solve this, the defences are operational, and they follow directly from the attack classes:

• Treat tool descriptions from third-party servers as untrusted input. Review them when registering a server, and review changes when a server updates — the rug-pull vector is precisely the update nobody re-reads.
• Pin versions. An unpinned MCP server is an unpinned dependency with prompt-injection reach into your agent.
• Require human-in-the-loop approval for irreversible actions. Deleting records, sending messages, moving money — the model’s judgement about whether a tool call is appropriate is exactly what poisoning subverts.
• Constrain blast radius by scoping credentials to what the server genuinely needs. OAuth’s revocability is worth more here than its authentication.
• Prefer first-party or audited servers for anything privileged, accepting that Postmark shows “official” is a weaker signal than it looks.

Assessment#

MCP’s security posture in mid-2026 is strong at the perimeter, weak in the interior. Authentication and authorization are now genuinely well-specified, hardened by a revision’s worth of focused work, and backed by mature OAuth practice.

Inside that perimeter, a connected server retains standing permission to write into the model’s reasoning context, with no protocol-level mechanism for continuous verification, provenance binding, or change detection.

This is the most likely area for the next substantive specification work, and the most important thing for an adopter to understand: connecting an MCP server is a trust decision that the protocol will not re-examine on your behalf.

Transports — stdio, Streamable HTTP, and the Cost of Statelessness#

Verified: 2026-08-04

Two Transports, Two Worlds#

MCP has effectively two live transports, and they serve populations so different that most generalisations about “MCP servers” are false for one of them.

HTTP+SSE — the original remote transport, deprecated since 2025-03-26 — was formally reclassified as Deprecated under the new lifecycle policy (SEP-2596), with migration to Streamable HTTP. Under the twelve-month window it cannot be removed before July 2027.

The old S1 also lists a WebSocket transport via an SDK extra. That was never a specification transport and should not be read as one.

stdio: The Underdiscussed Majority#

A stdio server is a subprocess. The client launches it, writes JSON-RPC to its stdin, reads from stdout. There is no network, no TLS, no tokens.

This is where MCP started and where most servers still run — every locally-configured server in a desktop AI client or IDE. It explains a persistent mismatch in how MCP is discussed: the specification’s most sophisticated machinery (OAuth 2.1, issuer binding, CIMD, stateless horizontal scaling) addresses the remote case, while the typical deployment is a subprocess on a laptop.

The security consequence is direct. A stdio server runs with the user’s full authority, and its protection is whatever the operating system and the user’s configuration choices provide. When security-model.md describes rug pulls — a trusted package updating to add malicious behaviour — stdio is the setting where that plays out most cleanly, because there is no token to scope and no authorization server to revoke.

server/discover doubles as a backward-compatibility probe on STDIO, which is the practical way a client establishes what an older local server supports without a handshake.

Streamable HTTP After the Session#

The stateless revision changed this transport substantially. What remains:

Required headers on POST requests — Mcp-Method and Mcp-Name (SEP-2243), plus x-mcp-header support for custom headers sourced from tool parameters.

No Mcp-Session-Id. Removed with sessions themselves (SEP-2567).

No GET endpoint. Opted-in server-to-client notifications moved to subscriptions/listen, a single long-lived POST-response stream.

No SSE resumability. The Last-Event-ID header and SSE event IDs are gone. A broken response stream loses the in-flight request, and the client MUST re-issue it as a new request with a new request ID.

That last change is the one to think hardest about. Resumability was a real feature: a client on a flaky connection could reconnect and recover a stream mid-flight. Removing it trades resilience for the ability to route any request to any instance — you cannot resume a stream on an instance that never had it without shared state, which is exactly what the revision set out to eliminate.

Retry semantics therefore become the client’s problem, and idempotency becomes the server author’s. A tool call that is expensive or non-idempotent now needs application-level protection against a client legitimately re-issuing it after a dropped stream. The Tasks extension is the sanctioned answer for anything long enough that this matters: get a handle, poll it, and a dropped connection costs a poll rather than the work.

What Gateways Can Now Do#

Header-based dispatch has a consequence beyond the origin server. Because Mcp-Method and Mcp-Name are required headers rather than body fields, intermediaries can route on method and tool name without parsing JSON-RPC bodies.

Previously a gateway wanting per-tool policy — rate limits, authorization, audit, routing — had to do deep packet inspection. Now it reads two headers.

Combined with the removal of sticky sessions, this is what makes the gateway layer (survey 2.083) tractable: a plain round-robin load balancer suffices for distribution, and policy enforcement becomes header inspection. A server that previously needed sticky sessions, a shared session store, and DPI at the gateway now runs behind ordinary infrastructure.

This is the clearest instance of MCP being designed for operational deployment rather than protocol elegance. The header duplication is redundant with the body; it exists so that infrastructure that should not parse payloads does not have to.

Caching as Transport Concern#

Statelessness means re-fetching what a session would have retained, so CacheableResult (SEP-2549) makes caching explicit: required ttlMs and cacheScope ("public" / "private") on tools/list, prompts/list, resources/list, resources/read, and resources/templates/list.

cacheScope is specifically about shared intermediaries — whether a gateway may cache a response for more than one user. That field exists because the deployment model now assumes intermediaries, which the pre-stateless protocol did not.

Assessment#

The transport story is coherent but the two halves have diverged in maturity. Streamable HTTP received essentially all the revision’s attention and is now well-suited to ordinary web infrastructure — stateless, header-routable, cache-aware, gateway-friendly.

stdio is stable and comparatively unexamined, while remaining where most servers run. Its simplicity is a genuine virtue: no transport-level failure modes worth discussing, and the lowest-friction path from “I have a script” to “my agent can use it.”

The honest summary is that MCP has become two protocols sharing a message format — a local subprocess protocol governed by OS permissions and user trust, and a remote web protocol governed by OAuth and cacheable statelessness. Most confusion about MCP’s security or scalability comes from applying claims about one to the other.

S3 Approach — Who Adopts MCP, and Why#

Survey: 2.074 Pass: S3 Need-Driven Discovery Date: 2026-08-04

The Selection Axis#

S2 found that MCP is effectively two protocols sharing a message format: a local subprocess protocol governed by OS permissions and user trust, and a remote web protocol governed by OAuth and cacheable statelessness. The specification’s most sophisticated machinery serves the remote case; most deployments are stdio.

That split, not use case, is what determines whose problem MCP solves. A persona’s position on two axes decides almost everything:

A second axis cuts across it: which side of the protocol you implement. Server authors, client/host implementers, and platform operators experience entirely different protocols under the same name — and the 2026-07-28 revision moved work from servers to clients, so their interests are not merely different but opposed.

What Personas Are For#

Each states who has the need and why it arises — the situation, the constraint that makes MCP relevant or unusable, and what “working” means for them. No implementation guidance; that is 1.210’s job.

Several of these personas are served unevenly, and one is served badly. Where that is true, S3 says so and leaves the strategic implication to S4.

The Personas#

The last is unusual for a 4PS S3 and earns its place here: MCP’s documented attack classes mean a named reviewer is frequently the actual decision-maker on whether adoption proceeds, which makes them a persona rather than a constraint.

A Note on Category-First Framing#

MCP is load-bearing infrastructure for many agent stacks, including ones the reader may operate. Per RAIL 0, this survey judges MCP on the category’s merits for any adopter. No persona here is a stand-in for a particular deployment, and the fact that a reader depends on MCP is not an argument in its favour.

Persona: The Client and Host Implementer#

Position: Either topology — this persona spans both Constraint: Absorbs the complexity the protocol moves off servers

Who#

A team building something that consumes MCP: an AI client, an IDE extension, an agent framework, an internal assistant. They are on the other side of the protocol from everyone else in this pass.

Numerically they are the smallest population here — a few dozen serious implementations against tens of thousands of servers. Structurally they are the most consequential, because a server is only as reachable as the clients that speak to it.

Why the Need Arises#

An agent without tools is a chat window. The value of a client is largely the value of what it can reach, and building integrations one by one does not scale — that is the pre-MCP world from the client side.

MCP inverts the economics: implement the protocol once, and every server anyone has written becomes available. With roughly ten thousand registry-quality servers and tens of thousands published across directories, that is a decisive difference in what a client can offer on launch day.

For a client implementer, MCP is less an integration standard than a distribution channel already stocked.

What the Revision Did to Them#

2026-07-28 moved work from servers to clients, deliberately. This persona pays for the statelessness that server operators enjoy.

The client now owns the state machine. Multi Round-Trip Requests replaced server-initiated callbacks: the server returns InputRequiredResult and the client must remember what it was doing, gather the requested input, and retry the original request with inputResponses. Previously the server drove that exchange. Now the client tracks it, across retries, with no session to lean on.

Version and capability negotiation is per-request. With the handshake gone, the client attaches io.modelcontextprotocol/protocolVersion and clientCapabilities to every request, and should identify itself with clientInfo. server/discover is available for up-front version selection, but it is optional and the client decides when to call and how long to cache it.

Caching became the client’s responsibility to exploit. Required ttlMs and cacheScope on list results are hints. A client that ignores them re-fetches constantly; one that honours them must implement invalidation correctly, including respecting "private" scope.

Retry logic is now load-bearing. SSE resumability is gone. A broken response stream loses the in-flight request and the client MUST re-issue with a new request ID — while avoiding duplicate side effects on non-idempotent calls.

Deprecated features must still be supported. Roots, Sampling, and Logging cannot be removed before July 2027, and servers in the wild use them. Clients carry both paths.

The Asymmetry Worth Naming#

Server authors got a simpler protocol. Client implementers got a harder one. That is the revision’s central trade, and it is defensible: there are far fewer clients, they are mostly well-resourced vendors, and MCP’s value scales with server count, so lowering server cost is the higher-leverage move.

But it means “MCP support” is a much bigger claim for a client than for a server, and the gap widened. A minimal compliant server is an afternoon; a good client is a sustained engineering commitment that now includes a retry state machine, a cache with scope semantics, dual support for deprecated features, and — if it wants parity with ChatGPT, Claude, Goose, and VS Code — a sandboxed iframe host for MCP Apps.

The Security Burden Lands Here#

The trust-inheritance problem in S2 is, in practice, the client implementer’s problem, because the client is what decides which tool descriptions reach the model.

Nothing in the specification requires a client to detect that a server’s tools changed, verify provenance, or re-prompt the user after a rug pull. The protocol makes detection cheap — cacheable list results with deterministic ordering give a client a natural place to diff — but requires nothing.

So the defences against documented attacks (Postmark’s rug pull, tool shadowing, description poisoning) are product decisions by client teams, not protocol guarantees. Clients that implement change detection, provenance display, and human-in-the-loop confirmation for irreversible actions are doing unrequired work that materially protects users. Clients that do not are fully compliant.

That is an uncomfortable position: the smallest population in the ecosystem holds the only practical lever on its largest risk.

What “Working” Means Here#

• Every compliant server works, including ones written after the client shipped.
• Protocol revisions don’t force a rewrite — a real concern given this revision’s scope.
• Extension support is a deliberate, negotiable choice rather than an obligation.
• The client can protect its users from servers it did not write, without protocol help.

Persona: The Enterprise Platform Team#

Position: Remote, organisation, gateway-mediated Constraint: Must enable agent access without losing control of it

Who#

The platform, infrastructure, or internal-developer-experience group at a company where engineers are already using AI agents. Their mandate is to make agent access to internal systems possible, safe, and observable — and to be able to answer for it.

They arrive at MCP late, because their engineers arrived first.

Why the Need Arises#

The trigger is almost always the same. Engineers have been running local stdio MCP servers against internal systems for months, configured individually, on laptops. It works. Nobody approved it, nobody knows the inventory, and the servers hold the engineers’ own credentials.

The platform team’s problem is not whether to allow agent access — that decision was made for them by adoption. It is that the current state has no inventory, no authorization boundary, no audit trail, and no revocation.

MCP is attractive precisely because it turns an unmanageable pattern into a manageable one: a single protocol, a defined authorization model, and a chokepoint where policy can live.

Why the Revision Made This Tractable#

Two changes in 2026-07-28 matter disproportionately here, and together they are what makes central mediation practical rather than aspirational.

Header-based dispatch. Mcp-Method and Mcp-Name are required headers, so an intermediary can apply per-tool policy — rate limits, authorization, audit, routing — without parsing JSON-RPC bodies. Previously this needed deep packet inspection, which is expensive, fragile, and a hard sell to a security review of its own.

No sticky sessions. Requests route to any instance, so the gateway is a plain load balancer rather than a session-aware router.

The combination is what makes an MCP gateway a normal piece of infrastructure. cacheScope ("public" / "private") exists specifically because the deployment model now assumes shared intermediaries — the protocol anticipates this persona. Survey 2.083 covers the gateway layer itself.

What They Need That MCP Provides#

Explicit, revocable delegation. OAuth 2.1 with mandatory PKCE means every remote connection is a grant that can be scoped, logged, and withdrawn. The 2026-07-28 hardening — RFC 9207 issuer validation, issuer-bound credentials, application_type declaration, CIMD replacing DCR — closes exactly the authorization-server confusion findings an internal security review would otherwise raise.

A single protocol to govern. One policy surface instead of per-vendor integrations.

Vendor neutrality. Engineers use different clients. A gateway speaking MCP serves all of them, and does not lock the company to whichever assistant is currently ahead.

What MCP Does Not Give Them#

No inventory of what engineers run locally. The governance gap that triggered the project is in the stdio half of the protocol, and nothing in the specification touches it. A local subprocess with the user’s authority is invisible to a gateway. The platform team can offer a sanctioned remote path; they cannot enforce it through MCP.

This is the persona’s central frustration, and it is structural: the half of MCP they can govern is not the half their engineers are using. Enforcement has to come from endpoint management, client configuration policy, or procurement — not from the protocol.

No trust continuity. Once a server is approved and connected, nothing re-examines it. Rug pulls (Postmark, September 2025) are precisely the case where an approval remains valid while the approved thing changes underneath it. A platform team must build change detection themselves, or buy it.

No provenance. There is no signed capability document. A2A has signed agent cards at /.well-known/agent.json; MCP has server/discover, which is in-band and unsigned. “Is this server who it claims to be, and has it changed?” has no protocol answer.

What “Working” Means Here#

• Every remote agent-to-system connection is authenticated, scoped, logged, and revocable.
• Per-tool policy without body parsing.
• One control point, not one per AI vendor.
• Answers for auditors: who connected what, when, under whose authority, and what changed.
• A sanctioned path good enough that engineers prefer it to their laptop configuration.

Assessment#

This persona is the best-served by the current specification and the worst-served by the current reality. The remote protocol is close to what they would have asked for. The deployment they actually have is a fleet of ungoverned local subprocesses.

Closing that gap is a migration problem, not a protocol problem — and the incentive has to be carrot, since MCP gives them no stick. The sanctioned remote path must be easier than the laptop configuration engineers already have working, which is a high bar given the local path has no authorization step at all.

S3 Synthesis — What the Personas Establish#

Survey: 2.074 Pass: S3 Need-Driven Discovery Date: 2026-08-04

Coverage Map#

1. The Local/Remote Split Is the Whole Story#

Every persona’s experience is determined first by which half of S2’s split they occupy, and the two halves have diverged sharply in how much attention they receive.

The remote half got the entire revision. Stateless core, header dispatch, OAuth hardening, cache scopes, gateway-friendliness. Vendors, small operators, and platform teams all benefit.

The local half got nothing, and is where most servers run. No authorization boundary, no inventory, no governance surface. The server author persona thrives there precisely because it is unregulated — no hosting, no OAuth, no network surface.

That produces the sharpest tension in the survey: the enterprise platform team’s problem is the server author’s convenience. The ungoverned local path that makes MCP adoptable in an afternoon is the same path that makes it ungovernable at an organisation. Neither party is wrong, and the protocol takes no position.

2. The Revision Redistributed Cost, and Not Evenly#

2026-07-28 moved work from servers to clients, deliberately and with sound reasoning: fewer clients, better resourced, and MCP’s value scales with server count.

The consequence is that “supports MCP” now means very different amounts of work depending on which side you are on. A minimal compliant server is an afternoon. A good client is a retry state machine, a cache with scope semantics, dual support for features deprecated but not yet removed, and — for parity with ChatGPT, Claude, Goose, and VS Code — a sandboxed iframe host for MCP Apps.

3. The Authorization Grant Splits the Population#

For the security reviewer and the platform team, the OAuth grant is the feature — explicit, scoped, revocable delegation is exactly what they need to approve anything.

For the small operator, it is the barrier — it removes any try-before-you-commit path, and they often have no other acquisition channel.

Both readings are correct, and they cannot be reconciled by better UX, because the deliberateness is the security property. This is the clearest instance of MCP serving organisations better than individuals, and it is structural rather than incidental.

Practical consequence for any vendor: MCP is a retention and depth feature, not an acquisition one.

4. Security Lands on Whoever Will Carry It#

The trust-inheritance gap has no protocol owner, so it falls to whoever is willing:

• The security reviewer carries it as organisational controls — allowlisting, version pinning, description review, human-in-the-loop for irreversible actions.
• The client implementer is the only party technically positioned to fix it, since the client decides which tool descriptions reach the model — and nothing requires them to.
• The server author and small operator are unaware of it, which is not a criticism: they are the population the prevalence scans measure precisely because entry is cheap.

The smallest population holds the only practical lever on the largest risk. That is a fragile arrangement, and it is the finding S4 most needs to weigh.

What S3 Hands to S4#

1. MCP’s spec quality and MCP’s deployment reality have diverged. The specification is written for the remote, governed, authenticated case; most deployment is local, ungoverned, and unauthenticated. Any viability judgement has to say which one it is judging.

2. The revision’s cost redistribution is a bet on client implementers. It is sound while clients are few and well-resourced. If MCP client implementation becomes something smaller teams attempt, the asymmetry starts to bite — and the security burden sits on exactly those teams.

3. The interior security gap is the adoption risk. Not because the protocol is unusable today, but because approval currently rests on organisational controls that a single high-profile incident could be judged insufficient. The security reviewer’s “conditionally yes” is the load-bearing verdict in this pass, and it is conditional on things MCP does not guarantee.

Persona: The SaaS Vendor Shipping a Remote Endpoint#

Position: Remote, organisation Constraint: Customers must reach it from whichever AI client they already use

Who#

A product team at a software company whose customers keep asking whether the product “works with AI.” They have an existing web application, an API, authenticated accounts, and an operations team.

The decision in front of them is not whether to add AI features — it is whether to let their customers’ own agents reach the product’s data and actions.

Why the Need Arises#

Two pressures, pulling the same direction.

Customers arrive with agents already chosen. They use Claude, ChatGPT, Cursor, VS Code, or something internal. A vendor cannot dictate which, and building a separate integration per client is the pre-MCP world this persona is trying to escape.

Not integrating has a cost. Products an agent cannot reach become products the user must leave the agent to operate — friction that increasingly reads as staleness.

MCP answers this with the property that matters most to a vendor: one server implementation, consumed by every MCP client. First-party support exists from Anthropic, OpenAI, Google, Microsoft, GitHub, Vercel, VS Code, and Cursor. That two direct competitors both consume it is what makes this a platform decision rather than a bet on one vendor.

What the Stateless Core Changed#

This persona is the primary beneficiary of 2026-07-28, and the change is operational rather than functional.

Before, a remote MCP server needed sticky sessions, a shared session store, and deep packet inspection at the gateway. That is not exotic infrastructure, but it is different infrastructure — it does not look like the stateless HTTP services the team already runs, and it requires routing decisions the platform team has to be talked into.

After, the server runs behind a plain round-robin load balancer. It looks like every other stateless service the company operates. The integration stopped being an architecture conversation and became a normal service.

Header-based dispatch (Mcp-Method, Mcp-Name) compounds this: the gateway can apply per-tool rate limits, authorization, and audit by reading two headers rather than parsing bodies.

What It Costs#

OAuth 2.1 with PKCE is mandatory for any internet-reachable server, without exception. For a vendor this is less painful than it sounds — they already have accounts, sessions, and probably an identity provider — but it is real work, and the 2026-07-28 hardening added requirements: RFC 9207 issuer validation, issuer-bound credentials, application_type at registration, and the shift from Dynamic Client Registration to Client ID Metadata Documents.

A team that built against DCR guidance is building on the deprecated path.

Migration debt is ongoing. This revision removed sessions, the handshake, server-initiated requests, and SSE resumability. Roots, Sampling, and Logging are deprecated with removal possible from July 2027. A vendor committing to MCP is committing to track a specification that revises substantially and removes things.

Retry and idempotency became the server author’s problem. With SSE resumability gone, a broken stream means the client re-issues the request. Any expensive or non-idempotent tool call needs application-level protection, or the Tasks extension.

The Constraint That Bites#

The authorization grant blocks first contact, permanently.

A remote MCP server cannot serve an anonymous prospective customer. The user must complete a grant — deliberately, in an authorization-server interface — before anything works. That is not friction to be optimised; it is the security property being purchased, and every change in the revision makes the step smoother while none makes it optional.

For a vendor this has a concrete marketing consequence: MCP is a retention and depth feature, not an acquisition one. It deepens the relationship with customers who already have accounts. It cannot demonstrate value to someone evaluating the product, because the connect step precedes any value. A team expecting MCP to drive trials has misread what it is.

What “Working” Means Here#

• One implementation, reachable from every major AI client.
• Runs on the infrastructure the company already operates.
• Authorization is explicit, scoped, revocable, and auditable — properties enterprise customers will ask about.
• Doesn’t require re-architecture at each protocol revision.

The Open Risk#

Trust inheritance is the vendor’s problem too, in reverse. S2’s security analysis is usually read from the client side, but a vendor shipping a public MCP server is publishing tool descriptions that enter customers’ models’ context, and taking tool calls whose intent they cannot verify.

The Postmark incident (September 2025) is the cautionary case pointed the other way: an official server, established publisher, malicious update. A vendor’s reputational exposure runs through their MCP server’s supply chain — including any dependency that can alter a tool description.

Persona: The Security Reviewer#

Position: Cross-cutting, adversarial — the one who can say no Constraint: Must make a defensible decision about software nobody in the org wrote

Who#

Whoever signs off on whether MCP servers may be connected to systems that matter — an AppSec engineer, a security architect, a CISO’s delegate, or at a smaller company the most security-literate engineer available.

They are included as a persona rather than a constraint because in practice they are frequently the actual decision-maker on adoption. A platform team can build the gateway and a vendor can ship the endpoint, and neither matters if this person declines.

Why the Need Arises#

They are handed a request: engineers want agents to reach internal systems via MCP. The request usually arrives after adoption has already happened informally, which sharpens the framing — the question is not “should we permit this?” but “what do we do about the fact that it is already happening?”

They need a defensible position, and defensible means grounded in what the protocol actually guarantees rather than in how enthusiastically it is described.

What They Find Reassuring#

The authorization story genuinely holds up, and this is the part that lets adoption proceed.

• OAuth 2.1 with mandatory PKCE (S256) for every internet-reachable server, stated without exception. No sanctioned API-key mode, no bearer-token shortcut.
• Hardening that reads like it came from a review: RFC 9207 issuer validation (SEP-2468), issuer-bound credentials (SEP-2352), application_type declaration (SEP-837), OIDC discovery (SEP-2351). These are authorization-server-confusion and token-misredemption defences — the findings a competent reviewer would otherwise write up themselves.
• Explicit, scoped, revocable delegation. Every connection is a grant with an audit trail and an off switch.
• Governance: Linux Foundation Agentic AI Foundation, MIT-licensed spec, public SEP process, and a formal feature lifecycle with a twelve-month deprecation window.

A reviewer can write “authentication and authorization meet current best practice” and mean it.

What They Find Alarming#

The interior. And the evidence is not hypothetical, which is what makes this persona’s objection hard to wave off.

Tool descriptions are prompt content. The model reads names, descriptions, and parameter schemas to decide what to call. Anything that can write those fields writes into the model’s reasoning context. A reviewer recognises this immediately as an injection surface with no sanitisation boundary — and unlike SQL injection, there is no parameterisation available, because the “query” is natural language interpreted by a probabilistic system.

Trust is inherited and never re-examined. Clients inherit trust from connected servers with no continuous verification. The named attack classes — description poisoning, rug pulls, tool shadowing — all follow from that one structural fact.

Documented incidents, not theory:

• Postmark (September 2025) — the maintainer of the official server added BCC logic copying every sent email to an attacker-controlled address. Same package, same publisher, previously clean. The trust signals a reviewer would normally rely on are exactly what failed.
• Smithery — path traversal in the platform exposed 3,000+ credentials, showing that aggregators concentrate blast radius as well as convenience.

Prevalence data that will end a meeting: 43% of tested servers with command injection, 82% using file operations prone to path traversal (2,614 implementations), 36.7% SSRF-vulnerable (7,000+ servers), 33% of 1,000 scanned with critical vulnerabilities. Methodologies differ and the figures should be read as magnitude rather than precision — but a reviewer does not need precision to conclude that the median public server is not hardened.

The specification does not address any of this. Every hardening SEP concerns proving who a server is. None governs what a verified server’s tool descriptions may say to the model, or what happens when they change after approval.

The Question With No Good Answer#

“How will we know if an approved server turns malicious?”

MCP has no protocol answer. There is no signed capability document, no provenance binding, no required change detection. server/discover is in-band and unsigned. A2A’s signed agent cards show the shape of a solution exists in the neighbourhood; MCP has no equivalent.

The nearest thing is incidental: required ttlMs/cacheScope and deterministic tool ordering make list results cacheable, so a client that caches has somewhere to diff. Nothing requires the comparison — it is a client product decision, which means the reviewer is depending on a vendor’s roadmap rather than on a guarantee.

What a Defensible Approval Looks Like#

Because the protocol won’t do it, the controls are organisational:

• Allowlist servers; treat the public ecosystem as untrusted by default.
• Pin versions. An unpinned MCP server is an unpinned dependency with prompt-injection reach.
• Review tool descriptions at registration and on update — the rug-pull vector is the update nobody re-reads.
• Require human-in-the-loop approval for irreversible actions. The model’s judgement about whether a call is appropriate is precisely what poisoning subverts.
• Scope credentials narrowly; OAuth’s revocability matters more here than its authentication.
• Prefer first-party or audited servers, while accepting that Postmark shows “official” is weaker than it looks.

What “Working” Means Here#

• A decision defensible to an auditor, stated in terms of what is guaranteed versus mitigated.
• Known inventory of what is connected, under whose authority.
• Detection when a trusted thing changes.
• A blast radius they can describe.

Assessment#

This persona’s verdict on MCP in mid-2026 is conditionally yes — approve the remote, gateway-mediated, allowlisted path, and treat the local stdio fleet as the open risk.

That verdict is unusually contingent on organisational controls rather than protocol properties, which is the honest summary of MCP’s security posture: strong at the perimeter, unaddressed in the interior. A reviewer who approves MCP is approving a trust model they must supplement themselves, and should say so in writing.

Persona: The Engineer Exposing an Internal API#

Position: Local (stdio) first, remote later — individual or small team Constraint: The work must be small enough to justify on a hunch

Who#

An engineer with a system their agent cannot reach: an internal service, a database, a deployment tool, a ticketing system, a pile of scripts. They already use an AI client daily. They want it to do things in their environment rather than advise them about it.

They are not building a product. They are removing a copy-paste step from their own day.

Why the Need Arises#

The gap is mundane and constant. The agent can reason about the problem but cannot see the system, so the human becomes a data-transfer mechanism — pasting logs in, pasting commands out, re-describing state that a query would answer.

Before MCP, closing that gap meant writing a client-specific integration: learn one vendor’s plugin format, build to it, and rebuild if you switch clients or if the vendor changes it. The cost was high and the result was disposable, which is why most people never bothered.

MCP changes the arithmetic in one specific way: write the integration once, and every MCP client can use it. The integration outlives the client choice. That is what makes it worth an afternoon for a personal itch, and the afternoon-scale threshold is the whole point — this persona does not appear at all if the cost is a week.

Why stdio Fits#

Almost everything this persona needs is on the local side of S2’s split:

• No hosting. The client spawns the server as a subprocess. Nothing to deploy, nothing to keep running, nothing to pay for.
• No authorization. stdio sits outside the OAuth requirement. The subprocess inherits the user’s authority, which is correct — it is acting as them, on their machine, with their credentials already in the environment.
• No network surface. Nothing is exposed. The blast radius is the user’s own machine.

The remote machinery that dominates the specification — OAuth 2.1, PKCE, issuer binding, CIMD, stateless scaling, cache scopes — is irrelevant here. This persona can build something useful having read almost none of it.

What Rules Things Out#

Anything requiring an OAuth implementation for the first version. If the entry cost included standing up authorization, this persona would not start.

Anything client-specific. The durability across clients is the reason to build at all.

Protocol churn that breaks working things. This is the sharpest risk for this persona, and it is not hypothetical: the 2026-07-28 revision removed sessions and the handshake, and the Python SDK went to 2.0.0. A server built against the 1.x line and left alone is on the pre-stateless protocol. Someone who built a personal tool in early 2026 and did not follow the spec will find it broken and will not know why.

The twelve-month deprecation window (SEP-2596) helps, but it governs deprecations, not the removals already shipped in this revision.

What “Working” Means Here#

• An afternoon from idea to the agent using it.
• Survives switching AI clients.
• No infrastructure, no credentials management, no hosting bill.
• Doesn’t silently break when the protocol moves.

Where It Goes Next#

This persona is where most MCP servers come from, and it explains a lot about the ecosystem’s shape — including its quality distribution. Servers written in an afternoon, against an existing API, by someone not modelling an adversarial reader of tool descriptions, are exactly the population the prevalence scans in S2 measure: 43% with command injection, 82% using file operations prone to path traversal.

That is not a criticism of the persona. It is what a low entry threshold produces, and the low threshold is why MCP has an ecosystem at all. The two are the same fact.

The transition that matters is when a personal server becomes something colleagues want. At that point the persona crosses into remote territory — hosting, OAuth, and the trust questions in security-reviewer.md — and the afternoon-scale economics stop applying. Many servers never make that crossing, and the honest read is that most should not.

Persona: The Small Operator#

Position: Remote, individual or very small team Constraint: Infrastructure cost and operational surface must stay near zero

Who#

One person or a handful, running something real that other people use: a niche SaaS, a consultancy’s client-facing tool, a community service, an open-source project with hosted components.

They are distinguished from the SaaS vendor persona by having no platform team, no on-call rotation, and no capacity to absorb a novel operational pattern. Anything they run, they run themselves, forever.

Why the Need Arises#

Their users increasingly work through agents and expect the tool to be reachable that way. The small operator has the same incentive as any vendor — a product an agent cannot reach is a product the user must leave the agent to operate.

What they lack is slack. A large vendor can assign an integration to a team. This persona is choosing between the MCP server and every other thing they could build that week, and the decision turns almost entirely on what it costs to keep running, not what it costs to write.

Why 2026-07-28 Is the Persona-Defining Event#

Before the stateless core, hosting a remote MCP server meant sticky sessions, a shared session store, and deep packet inspection at the gateway. For a small operator that is disqualifying — not because it is difficult, but because it is different. It means a session store to run, back up, and monitor; routing that breaks in ways ordinary web hosting does not; and a failure mode nobody else on the internet can help debug at 2am.

After the revision, the server runs behind a plain round-robin load balancer. It is an ordinary stateless HTTP service. It deploys to the same boring platform everything else does, scales to zero if the platform supports it, and fails in familiar ways.

This is the change that put remote MCP inside this persona’s reach at all. S2 argues the revision optimises for server operators; this persona is the sharpest case, because for them the difference was not effort but feasibility.

The Cost That Remains#

OAuth 2.1 with PKCE is mandatory and cannot be skipped for an internet-reachable server. For a small operator this is the single largest remaining barrier — not the concept, but the obligation to run identity infrastructure correctly, including the 2026-07-28 requirements around issuer validation, issuer-bound credentials, and Client ID Metadata Documents replacing Dynamic Client Registration.

The mitigation is real: managed identity providers cover PKCE, Resource Indicators, and Protected Resource Metadata, so connecting can reduce to one Google or GitHub login with no JSON configuration. But that is a dependency, and it is the one place this persona must trust something they do not operate.

Spec churn is a maintenance tax with no team to absorb it. This revision removed sessions, the handshake, server-initiated requests, and SSE resumability, and the Python SDK went to 2.0.0. Deprecated features can go from July 2027. A small operator who builds and then looks away for eighteen months will return to breakage.

The twelve-month deprecation window (SEP-2596) is genuinely valuable here — more so than for larger teams — because it converts “watch the spec continuously” into “check in periodically.”

What Rules Things Out#

Anything requiring bespoke infrastructure. Resolved by the stateless core; would have been fatal before it.

Anything needing per-vendor integration work. One implementation reaching Claude, ChatGPT, Cursor, VS Code and the rest is the entire economic argument. Maintaining separate integrations is not available to this persona at any price.

Anything with unbounded operational surface. They will choose the boring option every time, and should.

What “Working” Means Here#

• Deploys to ordinary stateless hosting; no session store, no sticky routing.
• One implementation, every client.
• Identity delegated to a managed provider rather than hand-rolled.
• Survives eighteen months of inattention, or breaks predictably with warning.
• Marginal cost per user stays near zero.

The Uncomfortable Part#

The authorization grant blocks anonymous first contact, and this persona feels it hardest.

A large vendor has other acquisition channels; MCP deepening existing relationships is fine. A small operator often has no other channel — discovery is word of mouth and the tool speaking for itself. Requiring an OAuth grant before any value is delivered removes the try-before-you- commit path entirely.

So the small operator faces a genuine split: remote MCP serves their committed users well and their prospective users not at all. Survey 2.078 examines what fills that gap — clipboard handoff, prefill links, and the layered posture where a zero-setup path carries first contact and MCP carries the relationship afterwards. The relevant conclusion here is that MCP alone is not a complete answer for anyone whose users arrive as strangers.

S4 Approach — Long-Term Viability#

Survey: 2.074 Pass: S4 Strategic Selection Date: 2026-08-04

The Question#

MCP is barely two years old and already load-bearing for a large part of the agent ecosystem. That combination — young and depended upon — is exactly when a viability assessment is worth doing and hardest to do well.

S4 asks: is MCP safe to build on for the next three to five years, and what would have to happen for that answer to change?

Why the Usual Signals Are Insufficient#

The obvious indicators are all strongly positive and, taken alone, misleading:

• Governance transferred to the Linux Foundation’s Agentic AI Foundation.
• Six official SDKs, ~97M monthly downloads, roughly ten thousand registry-quality servers.
• Adoption by direct competitors — Anthropic and OpenAI both consume MCP.
• A specification revising deliberately, with a formal deprecation policy.

Any one of these would normally settle a viability question. But S2 and S3 surfaced two facts that adoption metrics cannot see: the specification and the deployment reality have diverged (the spec serves the remote governed case; most deployment is local and ungoverned), and the protocol has a documented, unaddressed structural security gap with real incidents attached.

Adoption numbers measure how many people bet. They do not measure whether the bet holds.

The Evaluation Frame#

Each file asks what would have to be true for MCP to still be the answer in three to five years, who decides it, and what the failure mode looks like.

A Note on What This Pass Is Not#

S4 does not recommend whether to adopt MCP for a particular system. It assesses the standard’s durability for any adopter in the category. Where a decision depends on deployment topology or organisational posture, that is S3’s territory and the personas there carry it.

Competitive Position — Layers, Not Rivals#

Verified: 2026-08-04

The Landscape Is Not a Race#

The common framing — MCP versus A2A versus the rest — misreads the situation. The protocols in this space mostly occupy different layers, and the ones that look competitive are usually complementary.

MCP is the vertical integration — agent reaching down to capability. A2A is the horizontal — agent talking across to a peer. They were designed as complements, both now sit under the same Linux Foundation umbrella, and a system can straightforwardly use both.

The gateway layer is downstream infrastructure, and MCP’s 2026-07-28 revision made it substantially easier to build: header-based dispatch means policy enforcement without body parsing, and statelessness means plain load balancing.

What A2A Has That MCP Doesn’t#

One thing, and it is the gap S2 and S3 both flagged: signed, out-of-band capability discovery.

A2A publishes agent cards at /.well-known/agent.json, cryptographically signed since v1.0 so a receiver can verify the card was issued by the domain owner. A2A is at spec v1.2 with 150+ organisations reported in production.

MCP has server/discover — in-band, requiring the URL first, and unsigned. There is no signed capability document, and no .well-known capability URL. The only .well-known usage in the current revision concerns authorization servers (SEP-2351).

This is the single clearest capability gap between the two, and it bears on both open problems: endpoint discovery (how a client finds a server at all) and provenance (how it verifies what it found). A2A demonstrates a governed, working design for both, in a sibling project under the same foundation. That adjacency makes it the most likely template if MCP closes the gap.

What MCP Gave Up#

The 2026-07-28 deprecations narrowed MCP’s ambition deliberately, and the pattern is consistent: every deprecated feature let the server reach into the client’s environment.

• Sampling — a server could ask the client’s model to think for it, without its own API key. Deprecated; integrate with your own provider API.
• Roots — a server could ask about the client’s filesystem. Deprecated; pass paths as parameters.
• Logging — a server could set the client’s log level. Deprecated; use stderr or OpenTelemetry.
• Server-initiated requests generally — replaced by MRTR.

Sampling is the significant loss. It was MCP’s most economically interesting idea: a server could provide intelligence without paying for inference, because the client’s model did the thinking. That inverted the usual cost structure and would have made model-using capability available to operators with no inference budget.

Its removal means servers provide capability and consume nothing. Simpler to secure, simpler to bill, simpler to reason about — and meaningfully less powerful than the original proposal.

Does this cede ground? In principle a protocol willing to keep server-initiated model access could occupy that space. In practice nothing has, and the reason is visible in MCP’s own reasoning: server-initiated capability is exactly what makes the security and billing stories hard. The narrowing looks less like retreat than like the protocol discovering which half of its ambition was tractable.

The Displacement Question#

Could something replace MCP?

Not on technical merit alone. MCP’s position rests on cross-vendor client consumption — Anthropic, OpenAI, Google, Microsoft, GitHub, Vercel, Cursor. A competitor would need to be adopted by clients who have already built MCP support and have no reason to fragment their own integration surface. That is an enormous coordination cost for a marginal improvement.

The realistic displacement path is a security failure, not a better protocol — the scenario in security-trajectory.md, where MCP becomes unapprovable rather than uncompetitive. Even then, a successor would likely be MCP-shaped with provenance added, not a different design.

A quieter risk: absorption. If the major model vendors converged on a first-party agent platform where MCP was one supported input among several, MCP could persist while becoming strategically peripheral. Nothing currently indicates this — the MCP Apps cross-vendor uptake points the other way.

Where MCP Sits Against Its Own Neighbours#

Worth stating explicitly because the surveys interlock:

• vs A2A (2.075): complementary layers, same foundation. A2A is ahead on signed discovery and provenance; MCP is far ahead on client reach and server ecosystem.
• vs WebMCP (2.078): different direction entirely — WebMCP is a page exposing tools to a browser-attached agent, and it borrows MCP’s primitives. As of August 2026 no mainstream agent client consumes WebMCP, so it is a forward bet rather than a live alternative.
• vs agent gateways (2.083): downstream of MCP, and enabled by it.

Three-Year Outlook#

Highly likely: MCP remains the standard for model-to-tool integration, with A2A alongside it for agent-to-agent. The Linux Foundation housing both makes coordinated evolution plausible.

Likely: MCP adopts A2A-style signed capability discovery in some form. The gap is well understood, the template exists in a sibling project, and it addresses two open problems at once.

Watch: whether anything reclaims the Sampling niche — server-provided intelligence without server-side inference cost. It is a real unmet need and currently nobody’s problem.

Unlikely: direct displacement. The coordination cost of moving the installed client base exceeds any plausible technical gain.

Ecosystem Viability — Implementations, Scale, and Fragmentation#

Verified: 2026-08-04

The Indicator That Actually Matters#

For a standard, the load-bearing viability signal is not adoption volume. It is independent implementations by parties with divergent interests.

MCP has that, and it is the strongest single fact in its favour:

• Six official SDKs across Python, TypeScript, Go, C#, Rust, and Java, all under the modelcontextprotocol organisation, five of six pushed to on the day of verification.
• Direct competitors consuming it. Anthropic and OpenAI both implement MCP clients. Google, Microsoft, GitHub, Vercel, VS Code, and Cursor have first-party support.
• Both competitors implementing the same optional extension. ChatGPT, Claude, Goose, and VS Code have all shipped MCP Apps host support — meaning they are tracking the specification’s optional surface, not just the minimum.

That last point is the one to weigh. A vendor implements a competitor-originated protocol’s minimum when the market forces it. A vendor implements the optional extensions when it expects the standard to persist. This is behaviour consistent with real commitment rather than defensive compliance.

Scale, Read Carefully#

The 96,771 figure aggregates five directories with overlapping contents and no deduplication guarantee, and sits an order of magnitude above the official registry’s own count. A defensible reading: ~10k registry-quality servers, tens of thousands published somewhere, a long tail beyond.

Growth from ~50 servers at launch (November 2024) is not in dispute, and ~97M monthly SDK downloads is difficult to explain other than as genuine production use.

But scale is a lagging indicator and a weak one. It measures how many people have bet, not whether the bet holds. A standard can have enormous adoption and still be displaced — the relevant question is whether the implementers stay, and that is answered by the cross-vendor SDK and extension evidence above, not by server counts.

Quality Distribution Is the Counterweight#

The same low entry threshold that produced the ecosystem produced its quality profile. S3’s server-author persona builds in an afternoon, against an existing API, without modelling an adversarial reader of tool descriptions — and the prevalence scans measure exactly that population (43% command injection, 82% path-traversal-prone file operations, 33% of 1,000 scanned with critical vulnerabilities).

These are the same fact seen twice. The ecosystem is large because entry is cheap, and unhardened because entry is cheap. Any intervention that raises the quality floor raises the entry cost, which is a genuine trade-off rather than an oversight.

For viability this means server count should be mentally discounted. The ecosystem’s durable asset is the implementer layer — six SDKs, a registry, cross-vendor clients — not the long tail of servers, most of which are individually disposable.

The Official Registry as Institution#

modelcontextprotocol/registry (7,103 stars, last push 2026-07-29) matters beyond cataloguing.

It is where the endpoint discovery function lives — the thing S2 established the protocol does not provide. server/discover answers “what can this server do?” once you hold the URL; the registry is how you find the URL. That places a load-bearing ecosystem function outside the specification, in infrastructure that is itself a single point of trust.

The registry is also the most plausible venue for the security interventions security-trajectory.md discusses: publisher verification, signing, scanning. npm and PyPI reached the same conclusion for the equivalent problem. And the Smithery incident is the standing caution — an aggregator compromise (3,000+ credentials via path traversal) has a blast radius no individual server can match.

Registry health is therefore a viability signal worth tracking directly, not a detail.

Fragmentation Risk#

The extension mechanism is the right architecture — shrink the mandatory core, formalise the optional — but it changes what compliance means.

A host supporting core MCP but not io.modelcontextprotocol/ui is fully compliant and cannot render an MCP App. “MCP-compatible” has become a matrix rather than a boolean.

The extensions capability field makes that matrix negotiable rather than guessable, which is the correct mitigation and genuinely prevents the worst outcome (silent failure). What it cannot prevent is the ecosystem splitting along extension lines — a world where servers must choose which host families to target.

Current evidence says this is not happening. MCP Apps has support across ChatGPT, Claude, Goose, and VS Code — four hosts from three companies, including competitors. The first extension achieved broad multi-vendor support, which is the best possible early signal.

The risk to watch is a future extension where vendors’ interests diverge — something touching billing, model access, or competitive differentiation. Extensions where everyone benefits get implemented; extensions where one vendor benefits do not.

Protocol Revision as Compatibility Boundary#

A subtler fragmentation vector: 2026-07-28 removed sessions, the handshake, and several core features. “Speaks MCP” is no longer a single claim. A client and server on opposite sides of that boundary are not straightforwardly compatible.

The protocol handles this deliberately — server/discover and per-request io.modelcontextprotocol/protocolVersion exist to negotiate it, and UnsupportedProtocolVersionError makes failure explicit rather than silent. The Python SDK’s jump to 2.0.0 is the honest signal that this was a breaking change.

Well-managed, but it means the ecosystem carries two protocol generations for some time, and the long tail of afternoon-built servers is the part least likely to migrate.

Three-Year Outlook#

Highly likely: MCP remains the dominant model-to-tool integration standard. Cross-vendor SDK and client investment is too broad and too recent to unwind, and no competing protocol has comparable client reach.

Likely: server-count growth decelerates while quality and consolidation improve — registry verification, more first-party vendor servers, fewer disposable ones. The current distribution is what a land-grab phase looks like, and land-grabs end.

Watch: whether extension support stays broad. If a second and third extension achieve MCP Apps-level cross-vendor uptake, the extension model is proven. If one lands with support from only its originator’s host, that is the fragmentation signal.

Unlikely: displacement by a competing protocol. See competitive-position.md — the adjacent protocols occupy different layers rather than competing for the same one.

Governance and Lifecycle — The Process Case#

Verified: 2026-08-04

What Actually Changed at the Foundation Transfer#

Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation (AAIF) in December 2025. Co-founders include Anthropic, Block, and OpenAI; supporters include Google, Microsoft, AWS, Cloudflare, and Bloomberg. The specification is MIT-licensed.

The governance model is worth reading precisely, because it is narrower than “the Linux Foundation runs MCP now”:

The AAIF Governing Board makes decisions on strategic investments, budget allocation, member recruitment, and approval of new projects, while individual projects such as MCP maintain full autonomy over their technical direction and day-to-day operations.

So the foundation owns the institutional layer — trademark, neutrality, funding, a home that survives any single company. Technical direction remains with the MCP project itself, which is still heavily Anthropic-influenced in practice.

This is the standard open-source foundation pattern and it is genuinely valuable — it removes the single-vendor kill switch and the trademark risk, and it makes competitor participation politically possible, which is presumably why OpenAI is a co-founder rather than merely an adopter. It is not the same as multi-stakeholder technical governance in the W3C or IETF sense, and a viability assessment should not claim it is.

The honest characterisation: institutional neutrality achieved, technical neutrality partial.

The Process Maturity Signals#

Three things in the 2026-07-28 revision are, for viability purposes, more informative than any feature:

A formal feature lifecycle policy (SEP-2596) defining Active / Deprecated / Removed states, a minimum twelve-month deprecation window, and a published registry of deprecated features.

A formalised SEP workflow (SEP-1850): markdown files in a seps/ directory, PR-derived numbering, defined sponsor responsibilities, status managed via PR labels.

An error-code allocation policy partitioning the JSON-RPC server-error range, with existing SDK usage grandfathered.

None of these is exciting. All three are things a protocol does only when it has enough independent implementations that coordination costs have become real. Error-code partitioning in particular exists because collisions between implementations started to matter. These are the fingerprints of a genuine multi-implementer ecosystem, and they are much harder to fake than adoption numbers.

The Deprecation Policy Is Doing Heavy Lifting#

The twelve-month window is what makes the current revision defensible rather than reckless.

2026-07-28 deprecated Roots, Sampling, Logging (SEP-2577), the HTTP+SSE transport, RFC 7591 Dynamic Client Registration, and two includeContext values — while also removing sessions, the handshake, server-initiated requests, tasks/list, and SSE resumability outright.

That is an aggressive revision by any standard. Without a guaranteed window it would be a serious strike against viability: a protocol that removes features unpredictably is one you cannot build a product on.

With the policy, implementers get a bounded, published migration schedule. Nothing deprecated in this revision can be removed before July 2027, and the deprecated-features registry means the schedule is discoverable rather than folkloric.

The policy arrived in the same revision as the aggressive deprecations, which is the right order — but it is also new and untested. Its value depends entirely on whether it is honoured under pressure. The first real test is July 2027, when the currently-deprecated features become eligible for removal.

What This Means for Viability#

The process case for MCP is strong. Foundation governance removes single-vendor risk. The SEP process is public and traceable — every claim in this survey’s S2 cites a SEP number, which is only possible because the process produces durable artifacts. The lifecycle policy converts “the spec might break my product” from an unbounded risk into a scheduled one.

The residual risks are two:

Pace. MCP revises fast and removes things. This revision was the largest since launch and landed roughly eight months after the previous one. Implementers carry continuous migration debt, and S3’s small-operator persona feels it worst — no team to absorb it, and an eighteen-month inattention gap now means breakage rather than staleness.

Technical direction concentration. Project autonomy means the technical roadmap is not foundation-governed. If MCP’s direction diverged from what a major implementer needed, the foundation structure provides no formal mechanism for that implementer to force the issue — only the informal leverage of being a large consumer. That leverage is currently substantial (OpenAI, Google, Microsoft all consume MCP), which is why this is a theoretical risk rather than an active one.

Three-Year Outlook#

Highly likely: MCP remains under AAIF, continues the SEP process, and honours the twelve-month window through the July 2027 test. The institutional structure is stable and well-precedented.

Likely: revision pace slows. The 2026-07-28 refactor resolved the protocol’s central architectural question (where state lives). Protocols typically stabilise after their defining refactor, and there is no comparably large question outstanding — the remaining known gaps (trust continuity, endpoint discovery) are additive rather than structural.

Watch: whether technical governance broadens. A2A moved to the Linux Foundation’s Agentic AI Foundation and operates with visibly multi-vendor technical input. If MCP’s technical direction formalises similarly, the last meaningful governance caveat closes.

S4 Synthesis — Strategic Recommendation#

Survey: 2.074 — Model Context Protocol Pass: S4 Strategic Selection Revision assessed: 2026-07-28 Verified: 2026-08-04

The Verdict#

MCP is safe to build on, with one condition that does not expire.

The condition: you are inheriting an unsolved structural security problem, and you must budget for organisational controls that the specification is unlikely to make unnecessary within the assessment window.

Everything else is strong. Governance is institutionally neutral under the Linux Foundation’s Agentic AI Foundation. Six official SDKs exist across six languages. Direct competitors — Anthropic and OpenAI — both consume the protocol and both implement its optional MCP Apps extension, which is the behaviour of parties expecting a standard to persist. The specification revises deliberately, cites its own enhancement proposals, and now carries a formal lifecycle policy with a twelve-month deprecation window.

The Two-Sentence Summary#

MCP’s perimeter is excellent and its interior is unaddressed. Authorization answers “is this the server I think it is?” with mandatory OAuth 2.1, PKCE, RFC 9207 issuer validation, and issuer-bound credentials; nothing answers “should I still trust what it tells my model today?”

Risk Register#

The top row is the whole assessment. Everything below it is ordinary standard-adoption risk.

Adoption Posture#

Adopt for the remote, authenticated, gateway-mediated case — it is what the current specification is written for, and it is well-served. The 2026-07-28 stateless core makes an MCP endpoint an ordinary stateless HTTP service, which is what brought this within reach of small operators as well as enterprises.

Adopt for local stdio with clear eyes. It is the fastest path to value and the majority of real deployment, and it is where the governance and security gaps concentrate. An organisation with an ungoverned local fleet should know that MCP gives them no lever on it — enforcement has to come from endpoint management or procurement.

Budget the controls as permanent, not temporary. Allowlist servers; pin versions; review tool descriptions at registration and on update; require human approval for irreversible actions; scope credentials narrowly. On the most likely trajectory these remain necessary for years. An adoption plan assuming the specification will obviate them is planning on the least likely outcome.

Do not expect MCP to reach strangers. The authorization grant is a floor, not friction — every change in the revision makes it smoother and none makes it optional. MCP is a retention and depth mechanism, not an acquisition one. Anything needing to serve an anonymous first-time user needs a different path alongside it (see 2.078).

Track the protocol revision as a compatibility boundary. 2026-07-28 removed sessions and the handshake; the Python SDK went to 2.0.0. “Speaks MCP” is no longer a single claim, and the long tail of afternoon-built servers is the least likely to migrate.

Signals to Monitor#

In descending order of consequence:

1. A significant supply-chain incident against a widely-installed server. The Postmark pattern at scale is the realistic failure mode, and the outcome would be organisational prohibition rather than technical defeat. This single event determines the downside.
2. Whether major clients ship change detection and provenance UI. The client layer is the only party technically positioned to close the trust gap, and nothing requires them to. This is the most informative near-term signal.
3. Whether the specification adopts signed capability discovery. A2A’s signed agent cards are the template, in a sibling project under the same foundation. Would address provenance and endpoint discovery together.
4. Extension breadth on the next one or two extensions. MCP Apps achieved cross-vendor support from three companies including competitors. If extension #2 lands with only its originator’s host, that is the fragmentation signal.
5. July 2027 — the first real test of the deprecation policy. Whether Roots, Sampling, Logging, HTTP+SSE, and RFC 7591 DCR are actually removed on schedule, and how gracefully.
6. Registry health and any move to publisher verification. The registry carries the endpoint discovery function the protocol lacks, and is the most plausible venue for ecosystem-level security intervention — while also being a concentration risk of its own (cf. Smithery).

What Would Change This Assessment#

Upgrade to unconditional if the specification adopts provenance signing and change detection, or if major clients converge on shipping them.

Downgrade if a high-profile incident produces blanket enterprise prohibitions, or if a second and third extension fail to attract cross-vendor support and “MCP-compatible” fragments into a per-vendor matrix.

Reconsider the layer entirely if model vendors converge on first-party agent platforms where MCP becomes one supported input among several. Nothing currently indicates this — MCP Apps adoption points the other way.

Refresh Posture#

Fast decay class. MCP shipped its largest-ever revision eight months after the previous one, and the ecosystem numbers move monthly.

That said, the pace should ease. The 2026-07-28 refactor resolved the protocol’s defining architectural question — where state lives — and protocols typically stabilise after that. The known remaining gaps (trust continuity, endpoint discovery) are additive rather than structural, so the next revision is more likely to add than to remove.

Next scheduled checkpoints: any announcement of signed capability discovery, and July 2027 for the deprecation-window test.

Security Trajectory — The Gap That Decides the Downside#

Verified: 2026-08-04

Why This Is the Viability Question#

MCP’s process, governance, and ecosystem indicators are all strong. If MCP fails as a standard over the next three to five years, the most plausible mechanism is not abandonment or displacement — it is a serious security incident that makes organisations forbid it faster than the specification can respond.

That is not speculative pessimism. It follows from three facts established in S2 and S3:

1. The trust-inheritance gap is structural, not a patchable bug class.
2. The prevalence data says the median public server is not hardened.
3. Real incidents have already occurred, including against an official server.

What Would Have to Be True for This to Resolve Well#

Someone must close the gap between “a server is authenticated” and “a server’s tool descriptions still deserve the model’s trust.” There are four candidate owners, and they are not equally likely.

The specification. The cleanest outcome. The mitigations proposed in adjacent research — binding tool identity to origin with immutable IDs, lifecycle consistency validation, traceable registration and invocation logs — apply directly and are well understood. A2A demonstrates the provenance half is solvable: signed agent cards at /.well-known/agent.json give cryptographic proof a capability document came from the domain owner.

Arguments for: the SEP process is active and has shown it will take on hard problems (six authorization SEPs in one revision). Arguments against: the revision just spent its security budget on authorization, and the interior problem is harder — it requires deciding what a server may say to a model, which is closer to content policy than protocol design.

Client implementers. The most likely near-term source, because they are technically positioned: the client decides which tool descriptions reach the model, and required ttlMs/cacheScope plus deterministic ordering already make change detection cheap to implement.

The problem is that this produces defence as product differentiation rather than guarantee. A client implementing change detection, provenance display, and human-in-the-loop confirmation is doing unrequired work; one that does not is fully compliant. Users cannot tell the difference from the outside, which is the classic setup for a market that under-supplies safety.

Registries and aggregators. The official registry (7,103 stars, actively developed) could enforce scanning, signing, or publisher verification. This is where npm and PyPI eventually landed for the equivalent problem.

But the Smithery incident is the caution: a path traversal in the aggregator exposed 3,000+ credentials. Registries concentrate blast radius as well as trust, and a compromised registry is worse than a compromised server.

Organisations, individually. What actually happens today — allowlisting, version pinning, description review, human-in-the-loop for irreversible actions. It works, it does not scale, and it means every adopter re-solves the same problem. S3’s security-reviewer persona is carrying this weight now.

The Asymmetry That Makes This Fragile#

The smallest population in the ecosystem holds the only practical lever on its largest risk.

There are tens of thousands of servers, a large population of server authors who are unaware of the threat model, and a few dozen serious client implementations. Only the clients can practically intervene, and nothing requires them to.

That is a fragile equilibrium. It holds as long as the major clients — Anthropic, OpenAI, Microsoft, Google, Cursor — choose to invest in protections they are not obliged to build. Their incentives are decent (a high-profile exfiltration via their client is a reputational problem for them), which is why it has held so far.

The Incident Scenario#

The realistic bad path is specific enough to describe.

A widely-installed MCP server — official, established publisher, thousands of deployments — pushes an update adding exfiltration logic to a tool description or handler. Hosts reload tool definitions without re-prompting. The tools keep working as advertised, so nothing looks wrong. Data leaves for days or weeks before anyone notices.

This is exactly the Postmark pattern (September 2025: maintainer of the official Postmark MCP server added BCC logic copying every sent email to an attacker-controlled address), scaled up. The mechanism is proven; only the blast radius differs.

The consequence would not be that MCP is technically defeated. It would be that enterprise security functions issue blanket prohibitions, and the S3 security-reviewer’s “conditionally yes” becomes “no” across an industry at once. Standards rarely die of technical inferiority; they die of becoming unapprovable.

What Argues Against the Bad Path#

The perimeter is genuinely strong. Authorization is well-specified, hardened, and backed by mature OAuth practice. The attack requires compromising a trusted publisher rather than defeating the protocol — which is a supply-chain problem the whole software industry has, not an MCP-specific weakness.

The ecosystem has institutional attention. OWASP publishes an MCP Security Cheat Sheet; the Cloud Security Alliance has a research note on tool poisoning; multiple independent scanning efforts exist. Threat classes with names, papers, and cheat sheets tend to get tooling.

The mitigations are known and cheap. Unlike some structural security problems, this one has identified solutions that do not require breaking changes — provenance signing and change detection are additive.

Statelessness helps indirectly. Cacheable, deterministically-ordered list results give every client a natural diffing point. The protocol made the fix cheap without requiring it.

Three-Year Outlook#

Most likely (≈55%): incremental, uneven improvement. Major clients ship change detection and provenance UI as differentiators; the registry adds publisher verification; the specification adds optional signing. The gap narrows without ever being formally closed, and organisational controls remain necessary.

Plausible (≈30%): a significant incident forces the issue, followed by rapid specification work — provenance signing becomes mandatory, and adoption takes a visible but temporary hit. Net outcome is a more secure protocol, arrived at expensively.

Less likely (≈15%): the specification closes it proactively, before an incident forces it. This requires sustained attention to a problem that is harder and less legible than the authorization work already completed.

The tail risk — an incident severe enough to make MCP unapprovable in regulated industries for an extended period — is real but small, and would require a failure at a scale not yet seen.

Strategic Implication#

MCP is safe to build on, provided the adopter understands they are inheriting an unsolved problem and budgets for organisational controls.

The controls are not exotic: allowlist servers, pin versions, review tool descriptions on registration and update, require human approval for irreversible actions, scope credentials narrowly. What matters strategically is recognising that these are not temporary workarounds awaiting a protocol fix. On the most likely trajectory they remain necessary for years.

An adoption plan that assumes the specification will solve this is planning on the least likely of the three outcomes.