---
title: "The MCP Lesson"
date: "2026-08-10T13:00:00-07:00"
lastmod: "2026-08-10T13:00:00-07:00"
description: "MCP became the leading cross-vendor tool-integration seam before it had mature governance, not because coordination disappeared, but because one developer could run a complete useful loop from a distributed host. That adoption wedge is the test every contestable seam in the agent stack must pass."
summary: "The control-points series argues that distribution determines defaults and standard seams determine whether those defaults remain contestable. MCP adds the clock. It launched with a specification, SDKs, a distributed host, and reference servers, and one developer could run the whole loop before the ecosystem coordinated. Mature authorization and governance followed the adoption pressure. The lesson is not that ratification is obsolete or that protocols can be adopted unilaterally. It is that a seam needs a small first coordination radius, immediate utility, low exposed implementation cost, running code, and a path from one controlled deployment to multilateral interoperability. This essay runs the series\u0026rsquo; seam table through that test, uses AAuth as the clean-sheet stress test, and explains what would produce an enterprise \u0026lsquo;SAML moment\u0026rsquo; for agents."
slug: "the-mcp-lesson"
tags:
  - "Standards"
  - "MCP"
  - "OAuth"
  - "Agentic Identity"
  - "Interoperability"
---


One of the fastest standards trajectories in the identity-adjacent world began without formal ratification. Anthropic [introduced the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) on November 25, 2024 with a specification, SDKs, local support in Claude Desktop, and reference servers. By April 2025, GitHub had shipped an [official MCP server and native support in VS Code](https://github.blog/changelog/2025-04-04-github-mcp-server-public-preview/). In May, OpenAI added [remote MCP support to the Responses API](https://openai.com/index/new-tools-and-features-in-the-responses-api/) and Microsoft made MCP [generally available in Copilot Studio](https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/model-context-protocol-mcp-is-now-generally-available-in-microsoft-copilot-studio/). Mature project governance and the later [donation to the Agentic AI Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) followed the first wave of adoption.

That sequence matters to [the control-points series](/series/agent-control-points/). Its couplet says distribution determines the default and standard seams determine whether the default can be challenged. But standards work moves on a different clock from agent products. If a seam, the interface where independently governed systems exchange identity or authority, delivers value only after an ecosystem has coordinated around it, the products with distribution will set the default while the seam is still being specified. MCP's answer to that timing problem is the coordination radius of the first useful deployment.

The common description of MCP's escape, that one developer could adopt it unilaterally, skips a step: a protocol between a client and a server always needs two implementations. MCP's real achievement was to make that pair, the **adoption wedge**, small enough for one developer to control both sides.

> Running code creates the wedge. Distribution widens it. Governance consolidates what survives.

## What MCP Actually Proved

At launch, Claude Desktop supplied a distributed host and MCP client. SDKs and reference servers made the other endpoint cheap to build or install. The local `stdio` transport let one person run the whole loop on one machine, without waiting for a remote service, an enterprise trust agreement, or another vendor's roadmap. The protocol still had two sides. Distribution had already delivered one, and the project made the second a same-afternoon decision.

Five properties made that an effective adoption wedge, the smallest deployment that creates real value while holding the coordination radius down:

1. **Immediate utility.** A developer connected a real data source or tool and got a visible result.
2. **A complete local loop.** One operator could run the host, client, and server without a flag day.
3. **Low implementation cost.** SDKs, reference servers, and a simple JSON-RPC data layer reduced the amount of protocol work exposed to adopters.
4. **Distribution on one side.** Claude Desktop, and soon IDEs and other agent hosts, arrived with the client capability already present.
5. **An ecosystem payoff.** A server written once could reach every compatible host, making the second implementation more valuable with every new client.

The familiar rails story needs one correction. MCP launched on JSON-RPC with local `stdio` and HTTP/SSE transports. A comprehensive OAuth-based authorization framework was added in the [March 2025 specification revision](https://modelcontextprotocol.io/specification/2025-03-26/changelog), after the first adoption wave. That sequence strengthens the lesson rather than weakening it. The local wedge proved the integration model. Production use exposed the missing authorization surface. The protocol then composed established OAuth machinery instead of inventing a new authorization substrate.

The stdio wedge also did one more thing quietly. It bypassed the security boundary entirely. A local loop needs no network trust, no token exchange, and no firewall traversal, which is part of what made the first deployment cheap, and it means the coordination the wedge skipped was deferred rather than eliminated. When the loop went remote, the radius ballooned, and the deferred costs arrived together, an authorization surface, enterprise trust decisions, and security review. The deferral also moves the bill to a different desk. By the time the loop goes remote, adoption gravity makes prohibition impractical, so security teams retrofit governance onto a pattern already in production, which is why the gateway and enterprise-authorization markets around MCP exist at all. Every local-first wedge faces that second-phase shock, and it is worth naming because it is exactly the terrain the control-points series maps. The seams a wedge skips on day one become the contested layers afterward.

MCP therefore does not prove that governance is unnecessary. It proves that governance can mature around a useful running seam, provided the seam reaches developers before coordination cost kills it.

## The Discriminator Is Coordination Radius

"Unilaterally adoptable" collapses several different situations. Publishing a DNS record is unilateral. Verifying it is unilateral. Getting any interoperable value from the two still requires a publisher and a verifier that understand the same semantics. The better test is the **coordination radius**, the number of independently governed participants that must move before a deployment produces real value. Measure it for the first useful deployment:

- **Component-local:** one product can adopt the mechanism internally.
- **Operator-local:** one organization controls every participant needed for a useful loop.
- **Bilateral:** two independent parties must agree before either gets value.
- **Ecosystem-wide:** the benefit appears only after many independent implementers converge.

The radius is measured in administrative boundaries, not org charts. Inside one company, a deployment that needs the AI platform team, the identity team, and network security to move together is bilateral or worse in everything but name. The wedge exists only when the specific adopter controls every participant in the first loop without filing a ticket to another department.

Coordination radius is not implementation cost. A loop can fit inside one operator and still fail because that operator must build every component from a draft. Conversely, a three-vendor loop can feel operator-local to the buyer when products and integrations already supply every side. A useful adoption test therefore asks both how many independent parties must move and how much protocol work remains exposed to the adopter.

A seam can grow into an ecosystem standard even when its first deployment is operator-local. The danger is a design whose *first* useful result is ecosystem-wide coordination. MCP began operator-local and expanded outward. Email authentication followed a related shape. A domain could publish SPF or DKIM material without negotiating with every receiver, while receivers could add verification under their own policy. Each side could deploy independently, and interoperability appeared wherever the two deployments met. The test reads other histories just as cleanly. Let's Encrypt turned certificate issuance operator-local, one server and one cron job for immediate value, and encrypted most of the web. WebAuthn's first useful loop needed relying parties, authenticators, and platforms to move together, and it waited a decade for the platform vendors to supply the missing sides as passkeys.

There is a third way to shrink the buyer's radius when the loop is irreducibly multi-party. Pre-assemble it. Cross App Access illustrates the move. A protocol extension can go stable while the first production deployment is still a beta and the wider partner coalition is still rolling out, three different stages compressed into one launch announcement. [The worked companion tracks that rollout, stage by stage.](/notes/cross-app-access-is-the-layered-play-shipping/) For a supported joint customer, the remaining work becomes operator-local configuration rather than a bilateral protocol project. A launch coalition does not make the seam unilateral. It moves coordination cost from every buyer into the participating vendors' roadmaps before rollout.

The standardization question is therefore not "Can one party adopt this protocol alone?" Most protocols fail that literal test. The useful questions are:

1. What is the smallest group that can get real value?
2. Does one buyer or product owner control that group?
3. What adapter, SDK, gateway, or profile gets the seam from that first deployment to the next one?
4. Which multilateral dependency remains after the wedge succeeds?

> A fast seam makes the first useful loop small and the multilateral tail incremental. A slow seam asks the ecosystem to move before anyone gets paid back.

## A Draft Is a Shape, Not a Delivery Vehicle

The IETF's long-running phrase, [rough consensus and running code](https://www.rfc-editor.org/rfc/rfc7282), was never a promise that deployment waits for the RFC number. Nor does the MCP story show that formal standards should always trail products. Standards venues supply security review, stable semantics, change control, intellectual-property commitments, neutrality, and conformance language, properties an early vendor-led project cannot simply declare into existence.

The mistake is treating publication as distribution. OAuth extensions become deployable when libraries, authorization servers, profiles, test suites, and products turn them into a paved road. A folder containing PKCE, Rich Authorization Requests, token exchange, DPoP, and five new drafts is not an integration. A product or reference architecture that composes them behind one interface can be.

That is also how enterprises consume standards. They rarely assemble every wire primitive themselves. They buy a product category whose suppliers share an interoperability floor. "A SAML for agents" usually means that package: multiple credible implementations, a stable vocabulary, a conformance story, and a procurement test. The document is necessary to make the floor durable. It is not sufficient to create the category.

The control-points series already ends its identity-binding and approved-work essays with tests a buyer can run. Those tests are not substitutes for standards. They are the bridge between a draft's shape and a product claim.

## The Seam Table, Run Through the Better Test

Apply coordination radius rather than unilateral adoption to the seams in [the identity-binding essay](/notes/the-runtime-mints-the-identity/) and the record in [the approved-work essay](/notes/agent-authority-has-no-system-of-record/), and the rollout problem becomes clearer.

| Seam | First useful deployment | Why the wedge can work | Multilateral tail |
| --- | --- | --- | --- |
| **Portable runtime evidence** | One platform emits evidence and one enterprise verifier evaluates it | A single buyer can control both ends and compare runtimes under one policy | Common agent claims, trust profiles, and third-party verifier acceptance |
| **Instance distinct from software** | One Authorization Server requires instance assertions from its own clients | The AS can enforce the distinction at its existing token endpoint | Shared subject and actor semantics across issuers and resources |
| **External enterprise binding** | One enterprise maps evidence from several runtimes into its own Agent and Agent Deployment records | The value exists inside one estate before outside services recognize the binding | Portable binding semantics and acceptance by independent SaaS resources |
| **Credential projection** | One operator deploys token exchange between an issuer and its resources | RFC 8693 and sender-constrained tokens are already supported building blocks | Independent resources must accept the projected identity and authority semantics |
| **Cross-domain issuer trust** | A domain publishes issuer authorization and a verifier resolves it under local policy | DNS reduces discovery and domain-control proof to infrastructure both sides already run | Verifiers still need shared metadata semantics, trust policy, and resource acceptance |
| **Approved-work record** | One issuer records approved tasks and gates its own token issuance and refresh on them | The issuer already owns issuance, so the record has an enforcement point on day one without any resource changing | Shared task semantics, cross-issuer record portability, and resources willing to consult a record minted elsewhere |

None of these rows is coordination-free. Each has a plausible first deployment under one operator or one existing administrative relationship. That is the wedge. Each also has a tail where independent parties must agree. That is the standards work.

The hardest tail remains acceptance at the resource. An upstream identity, binding record, credential, or approved-task object cannot command an independent resource to trust its issuer or permit an action. DNS can prove that a domain authorized an issuer. It cannot make the relying party trust that domain's policy. Token exchange can project authority. It cannot make a Resource Server understand the projected semantics. The rollout strategy is to make acceptance an incremental extension of the OAuth validation and policy machinery the resource already operates, not to pretend acceptance can be made unilateral.

The radius explains the start. Leverage explains the finish. A multilateral tail moves when someone the tail-side party cannot ignore demands it, and in the enterprise that someone is procurement. SaaS vendors did not add SAML and SCIM out of protocol enthusiasm. They added them because enterprise buyers made support the price of the deal, and the same lever is how token-exchange acceptance and enterprise-managed authorization reach the resources. A small radius starts the seam. Asymmetric incentives finish it.

That also clarifies the DNS move in [the open-world trust work](/notes/trusting-issuers-in-open-world-oauth/). DNS is useful because it lowers discovery and domain-control coordination, the way SPF did. It does not eliminate the relying party's trust decision. The seam succeeds only if the published object is simple to resolve, the verifier can apply its own policy, and the resulting credential still lands on an authorization path the resource knows how to enforce.

## AAuth Is the Clean-Sheet Stress Test

The August 2026 [AAuth protocol draft](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/) makes the coordination question more interesting than a simple clean-sheet counterexample. It defines four progressively richer resource-access modes: signed identity, resource-managed authorization, Person Server assertions, and Person Server–Access Server federation. Mission, permission, audit, and interaction functions form an orthogonal governance layer. The draft explicitly designs for incremental adoption rather than requiring the full constellation on the first call.

Its smallest wedge is identity-based access. An Agent Provider binds an agent identifier to a key, the agent signs a request, and a resource verifies the signature and applies local policy. No Person Server or Access Server is required. One organization can operate the provider, agent, and resource itself, making the first loop operator-local. Across independent domains it is bilateral. It is therefore inaccurate to say that AAuth produces no value until resources, Access Servers, and Person Servers all move together.

But independent implementability is not independent value. A signature can be added unilaterally and ignored unilaterally. Identity appears only where a resource recognizes the format and trusts the Agent Provider. Unlike MCP at launch, AAuth does not yet have a widely distributed host supplying one endpoint. Its TypeScript, .NET, Python, and Java implementations are exploratory, and agent applications still have to expose identity, signing, discovery, and challenge handling. The theoretical radius can be small while the implementation cost exposed to the first adopter remains high.

The richer capabilities each carry their own coordination tail:

| Capability | Smallest useful loop | Multilateral tail |
| --- | --- | --- |
| **Signed agent identity** | One operator runs an Agent Provider and a resource that verifies its agents | Independent resources need common verification, provider trust, and policy semantics |
| **Resource-managed authorization** | One resource adds its own challenge, interaction, and account policy | Agents and harnesses need interoperable challenge and deferred-interaction support |
| **Person Server governance and Missions** | One person or enterprise uses a Person Server to govern its agents and local actions | Remote resources need to recognize the governance context if it is to affect their decisions rather than remain correlation |
| **PS–AS federation** | One Person Server and one Access Server establish trust | Cross-domain discovery, issuer trust, policy composition, and conformance become ecosystem work |

That leaves three credible adoption paths:

1. **Distribution.** A popular harness or Agent Provider ships signed identity and challenge handling as the default, supplying one side of many loops.
2. **A bounded deployment profile.** One enterprise or ecosystem operates enough roles to prove value, then federates outward capability by capability.
3. **Absorption.** The clean sheet contributes its strongest ideas to profiles on the OAuth and MCP stack that products already expose: explicit agent identity, Mission context, mediated approval, resource challenges, or signed exchanges.

SPDY's influence on [HTTP/2](https://www.rfc-editor.org/rfc/rfc7540) is the familiar patron-and-absorption example. Deployment supplied evidence, while standardization turned the surviving ideas into a neutral protocol. Absorption is not failure. It is often how an architectural idea crosses a coordination boundary its original wire format could not.

The fair objection is impedance. AAuth argues that independent agent identity, resource identity, Person Server governance, and cross-domain federation are more coherent as one design than as extensions to OAuth's client and authorization-server model. The incumbent stack has nevertheless absorbed token exchange, sender constraint, rich authorization, and backchannel approval. The useful burden is therefore specific. Which AAuth property loses its security or interoperability when profiled onto deployed rails, and which merely becomes less elegant? That answer determines whether the winning wedge needs a new protocol, an adapter, or both.

For AAuth, the practical question is not merely whether the protocol is cleaner or whether one mode can be demonstrated locally. It is which product hides the first implementation, which capability pays the adopter back before unrelated resources change, and how each successful local mode reaches its multilateral tail. Answer those questions and the clean sheet has an adoption strategy rather than only a specification.

## Where the SAML Moment Comes From

Standards bodies have not moved to the back of one universal pipeline. Different venues and artifacts solve different timing problems. MCP's extension and working-group process can evolve a seam already present in hosts. An OpenID Foundation profile can combine specification work with public interop and conformance. AuthZEN followed that path, with early drafts supporting implementer work before the [AuthZEN Authorization API 1.0](https://openid.net/specs/authorization-api-1_0.html) became Final in January 2026. The IETF works more slowly when the output must become durable Internet substrate, and that slower review can be the feature.

The enterprise's SAML moment arrives when four things meet:

1. **A stable category:** buyers and suppliers agree on the problem being purchased.
2. **Multiple implementations:** the interface is a seam, not one vendor's API.
3. **A conformance floor:** tests distinguish real interoperability from compatible branding.
4. **A migration wedge:** one deployment can start before every counterparty upgrades.

Formal ratification strengthens all four, but it cannot manufacture distribution or immediate utility. Product adoption demonstrates demand, but it cannot by itself guarantee neutrality or interoperability. The durable result needs both.

That gives anyone trying to keep the agent stack contestable a more precise order of operations. Specify the seam early enough to argue about semantics and security. Build the smallest complete loop. Ship it through a product, SDK, adapter, or profile that already reaches one side. Publish a conformance test before "compatible" becomes a marketing adjective. Move governance into a venue that can preserve the seam after the first distributor no longer controls it. Then consolidate the primitives that survive contact with real deployments.

Underneath the sequence is the compression this companion adds to the series. Every standard faces two coordination problems, the first useful deployment and ecosystem interoperability. They are won with different tools, on different clocks, and conflating them is how elegant seams die waiting for the ecosystem.

The control-points couplet holds, but MCP adds a third line and a better test:

> Distribution sets the default. Standards keep the default contestable. The adoption wedge decides whether the seam arrives in time.