Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 23 Sep 2026

Comparison

UHP vs MCP: different layers, complementary roles

UHP standardizes how a product drives a complete agent harness. MCP standardizes how an AI application connects to external tools, resources and prompts.

Verified: Protocol: 2026-09-12Static SSG

The shortest accurate answer

Section titled “The shortest accurate answer”
Product / application
        │
        │ UHP: execute through a harness
        ▼
Complete agent harness
        │
        │ MCP: reach tools / resources / prompts
        ▼
External capabilities

The protocols can be used in the same system. A UHP configured harness may itself be configured with MCP servers; the two standards address different interfaces.

Side-by-side

Section titled “Side-by-side”
DimensionUHPMCP
Primary boundaryClient/product → complete harness runtimeAI host/client → MCP server capabilities
Main purposeExecute agent work consistently across harnessesExpose tools, resources and prompts consistently
Execution lifecycleTasks, sessions, streaming, cancellation, files, errors, resultsStateless core requests plus opt-in extensions; the released Tasks extension supplies durable asynchronous-operation handles, but core MCP has no protocol conversation/session primitive
Protocol stateServer-owned task/session/continuation lifecycle2026-07-28 removes the connection-scoped MCP session and initialization handshake; cross-call state uses explicit application handles or extensions
Core transportHTTP; SSE for streamingJSON-RPC over stdio or Streamable HTTP; protocol metadata is per-request rather than connection-session scoped
Typical participantProduct backend, CLI or CI clientAI application host plus MCP clients and servers
Can coexist?Yes. UHP harness configurations can include MCP servers.Yes. UHP harness configurations can include MCP servers.

Why the confusion happens

Section titled “Why the confusion happens”

Both protocols appear in agent infrastructure discussions and both reduce bespoke integrations. But “integration” happens at several levels. MCP focuses on context and capability exchange. Its official architecture explicitly says it does not dictate how AI applications use LLMs or manage the provided context. UHP is deliberately about the higher execution contract around a complete harness.

MCP 2026-07-28 is stateless at the protocol core

Section titled “MCP 2026-07-28 is stateless at the protocol core”

The released MCP 2026-07-28 revision retired the connection-scoped initialize / notifications/initialized handshake and the Mcp-Session-Id header. Every request now carries its protocol version and client capabilities in _meta; clients SHOULD identify themselves on each request. Servers implement server/discover so clients that want an up-front capability and version snapshot MAY call it before other requests. The result is a request model that can be routed independently across server instances instead of depending on hidden transport-session state.

That is an important UHP boundary, not just an MCP deployment detail. Current MCP has no protocol-level conversation/session primitive equivalent to UHP sessions or UHP continuation state. An MCP server that needs state across calls can mint an explicit application handle and require that handle to be passed back as an ordinary tool argument. MCP Tasks separately provides durable asynchronous-operation handles for operations that adopt the extension, but a Task is not a general MCP conversation/session object.

The same revision also removes server-initiated JSON-RPC requests from the current message pattern. Multi Round-Trip Requests (MRTR) replaces the previous server-initiated elicitation/create, sampling/createMessage, and roots/list pattern: the server returns resultType: "input_required" with the additional inputRequests it needs, and the client retries the original request with corresponding inputResponses. Streamable HTTP additionally mirrors method/name metadata into Mcp-Method and Mcp-Name headers for gateway routing while the message body remains the source of truth.

For the UHP comparison, this sharpens rather than erases the distinction: MCP 2026-07-28 intentionally pushes connection/session state out of the protocol core, while UHP intentionally standardizes server-owned task/session/continuation lifecycle around a complete harness. Both can support stateful applications, but they standardize that state at different layers and with different wire semantics.

MCP OAuth iss validation reaches harness callback relays

Section titled “MCP OAuth iss validation reaches harness callback relays”

Released MCP 2026-07-28 authorization explicitly includes RFC 9207, OAuth 2.0 Authorization Server Issuer Identification, in its standards-compliance set. For HTTP-based MCP authorization, the client records the selected authorization server’s validated issuer alongside the per-request PKCE/state record before the browser redirect. MCP authorization servers SHOULD include the RFC 9207 iss parameter in authorization responses; when they advertise authorization_response_iss_parameter_supported: true, the client MUST reject a response that omits it. When iss is present, the MCP client MUST compare it to the recorded issuer before sending an authorization code to any token endpoint.

The comparison is intentionally strict. MCP says to use simple string comparison after decoding the form value and not to apply scheme/host case folding, default-port removal, trailing-slash normalization or percent-encoding normalization. The validation also applies to authorization error responses: an issuer mismatch must be rejected before the client acts on or displays the returned OAuth error fields. RFC 9207 defines the issuer parameter as a countermeasure to authorization-server mix-up attacks.

That requirement creates a practical relay-integrity boundary inside agent harnesses. A Desktop app, dashboard, browser-loopback listener or remote gateway may receive the authorization redirect on one process and relay the callback fields to the MCP OAuth client in another. If that intermediate layer preserves code and state but drops iss, an otherwise valid RFC-9207-capable MCP login can fail closed — or, in a weaker implementation, lose the issuer provenance the client is required to validate. The safe pattern is to preserve the exact callback field end-to-end and let the OAuth client perform the normative issuer comparison; a relay should not invent, normalize or silently substitute the issuer.

Hermes PR #111628, merged 15 September 2026, is a concrete implementation example. The CLI path already carried iss, while dashboard, Desktop and gateway-loopback relay paths could discard it. The fix threads iss through the shared redirect parser, dashboard callback flow, gateway mcp.servers.oauth.callback RPC/OpenRPC contract and Desktop loopback IPC. Desktop omits the optional field when the authorization server sent none so newer Desktop code remains compatible with older backends whose callback parameter model rejects unknown keys. The PR reports 147 targeted tests passed, 0 failed across six files; its author notes the Electron vitest was not run locally because that worktree lacked node_modules, with the JS lane left to CI.

The same strict rule can also expose authorization-server non-conformance, rather than a harness relay bug. Figma’s live authorization-server metadata currently identifies https://api.figma.com as the issuer and advertises authorization_response_iss_parameter_supported: true. Hermes PR #112059, merged 15 September 2026 as d84ece48, reports that Figma’s authorization redirect nevertheless omits iss, causing the MCP SDK’s RFC 9207 validator to reject otherwise valid authorization codes.

Hermes resolves that provider-specific interop failure with a deliberately narrow compatibility exception: only when the already-discovered issuer is exactly https://api.figma.com, the redirect contains a code, and iss is absent, Hermes fills iss from the validated metadata issuer and logs a warning. A present-but-different issuer is still rejected, and every other authorization server keeps the strict MCP/RFC 9207 behavior. The PR reports a three-case regression invariant passing on the fix branch and 129 passed, 1 skipped across the targeted MCP OAuth tests.

Rotating MCP OAuth refresh tokens need single-owner refresh across processes

Section titled “Rotating MCP OAuth refresh tokens need single-owner refresh across processes”

MCP 2026-07-28 delegates refresh-token security to OAuth 2.1 and requires MCP clients that hold refresh tokens to keep them confidential in transit and storage. The exact OAuth 2.1 draft referenced by MCP, draft-ietf-oauth-v2-1-13, requires authorization servers serving public clients to detect refresh-token replay using sender-constrained refresh tokens or refresh-token rotation. Under rotation, a successful refresh replaces and invalidates the previous refresh token; reuse of the invalidated token can cause the authorization server to revoke the active refresh token and the associated grant. When a refresh response includes a new refresh token, the client must discard the old value and replace it.

That creates a practical single-owner state-transition boundary for multi-process MCP clients. If a Desktop app, gateway worker and CLI share one MCP OAuth token store, two processes must not independently read the same rotating token and POST it concurrently. The safe implementation shape is one cross-process owner for read → refresh POST → persist replacement, with contenders reloading and adopting the fresh pair after the owner commits it. A lock timeout or unverifiable replacement should fail closed rather than replay a credential that may already have been consumed.

Hermes PR #111186, merged 15 September 2026 as 8ad7ae06, is concrete harness implementation evidence for this failure mode. It adds a cross-process file-lock fence around the MCP OAuth refresh sequence, adopts a peer’s persisted fresh token pair instead of re-presenting the consumed token, re-binds adopted state to the issuer, and fails closed when the fence cannot be acquired. The PR reports 124 targeted MCP OAuth tests passed; the same test set against the pre-fix provider recorded 8 failures.

Remote MCP HTTP/SSE proxy routing must preserve transport security controls

Section titled “Remote MCP HTTP/SSE proxy routing must preserve transport security controls”

MCP defines its protocol transports; it does not standardize how a particular client selects an enterprise HTTP proxy, interprets NO_PROXY, or composes local HTTP-client middleware. Those details still matter for interoperability because a harness can implement MCP correctly at the wire layer and fail to reach a remote server in a proxy-only network — or reach it through a route that accidentally bypasses the client’s own security controls.

Hermes PR #112280, merged 16 September 2026 as 341f8b4d, is concrete implementation evidence for that boundary. Hermes already supplied a custom httpx transport to both Streamable HTTP and SSE MCP clients so it could enforce a 10 MiB wire-body cap. In httpx, however, automatic environment-proxy discovery is disabled when a custom transport is supplied. The practical result was that HTTP_PROXY, HTTPS_PROXY, ALL_PROXY and system proxy configuration could be ignored by remote MCP connections even though ordinary HTTP clients on the same machine used them.

The merged correction makes proxy routing explicit instead of relying on implicit client defaults. Hermes reconstructs proxy mounts from environment configuration first and then operating-system proxy settings, applies the same route to the content-type preflight and the MCP SDK connection, and sends NO_PROXY decisions through its shared bypass matcher so CIDR ranges and wildcard hosts behave consistently with its other outbound transports. Loopback MCP targets (127.0.0.1, ::1, localhost) are never proxied under the repository’s local-trust rule.

The review follow-up also preserves two important security/liveness invariants. A proxy mount takes precedence over the client’s base transport=, so the proxy transport is wrapped in the same 10 MiB body cap rather than silently bypassing that limit. And proxy-construction failure now surfaces as that MCP server’s connection error instead of silently falling back to a direct connection. The PR’s live reproductions show Streamable HTTP and SSE taking configured HTTP/HTTPS proxies after the fix, exact-host and CIDR NO_PROXY bypasses remaining direct, and SOCKS proxy mounts being constructed for ALL_PROXY.

MCP keepalive policy is transport-specific inside a harness

Section titled “MCP keepalive policy is transport-specific inside a harness”

Hermes PR #114222, merged 17 September 2026 as f1df0aa0, provides a fresh implementation example of why MCP liveness policy should follow the transport’s actual failure model. Before the fix, Hermes applied its default 180-second keepalive probe to stdio MCP servers as well as HTTP/SSE. A stdio server that did not tolerate the unsolicited probe could therefore be marked suspect and reconnected even though its child process was still alive.

Current Hermes main keeps the 180-second default keepalive for HTTP/SSE, but stdio now sends no keepalive unless keepalive_interval is explicitly configured. Local child liveness remains covered by process-exit checks at call time and while an RPC is active. An idle stdio connection can still become session-proven after surviving a full default interval with a live child, without sending a ping, and an active RPC releasing after an idle/lifetime deadline wakes lifecycle recycling instead of allowing that deadline to be slept past. keepalive_interval: null is also treated as unset rather than being coerced with float(None).

The PR reports a live before/after reproduction against Hermes 98f758ae7e: default stdio changed from a 180-second wait plus ping to no keepalive ping, HTTP kept the 180-second default, and an explicitly configured stdio interval continued to ping. Its focused lifecycle/MCP validation reported 183 tests passed.

MCP media consumers should bind decoder admission and payload budgets to the bytes

Section titled “MCP media consumers should bind decoder admission and payload budgets to the bytes”

MCP can carry base64 binary content through tool results and Resources together with MIME metadata, but that metadata is not itself a host-side parser or resource-budget guarantee. Resource MIME metadata can also be absent. A harness therefore needs to keep two questions separate: what the server says the payload is, and what the host is willing to decode, transform or resend to a model.

Qwen Code PR #12567, merged 23 September 2026 as d3fc3acaf044fab69963cd9e885707995c06d76d, is concrete evidence. Before the fix, Qwen’s MCP path used the declared MIME label to decide whether image bounding ran and which MIME reached downstream converters. The same image bytes could therefore bypass bounding under a mis-cased or inaccurate label, an untyped image resource could remain application/octet-stream and be discarded as unsupported, and GIF/SVG-labelled payloads could enter an image-renderer path even though the renderer’s output allowlist is JPEG/PNG/WebP. Oversized non-image inline parts such as audio also escaped the image-only clamp and could be resent in full.

The merged path makes payload bytes authoritative for decoder admission while retaining the declared label as metadata rather than trust. A short magic-byte sniff admits only JPEG, PNG or WebP to image bounding; a validated in-budget image keeps its bytes but adopts the sniffed MIME; bounding happens before the tool-result envelope is rendered, so envelope metadata describes the bytes actually delivered to the model. Qwen also applies its inline-media ceiling to every inline MCP result part, and its omni-media fallback applies the same clamp when it declines to upload a part.

Transferable harness rules:

  1. Treat content-type metadata as a claim, not sufficient parser authority. Decoder admission should use a positive allowlist backed by byte-level identification.
  2. Keep transformation and metadata atomic: if bytes are resized, converted or otherwise identified, downstream metadata must describe the representation actually delivered.
  3. Apply byte ceilings to the payload class that consumes memory or model context, not only to a preferred modality. Oversized audio or opaque blobs can be as costly to replay as images.
  4. Keep unsupported or ambiguous formats out of heavyweight decoders unless explicitly supported; an opaque or omitted representation is safer than parser selection from a label alone.
  5. Regression-test wrong-case, wrong-type, missing-type, in-budget, oversized and unsupported-format cases across conversion and fallback paths.

Upstream reports 188/188 focused tests passing on the fixed branch; transplanting the new regression tests onto the pre-fix production code produced 12 failures out of 188. The contributor also exercised a real stdio MCP server end-to-end on macOS; Windows and Linux were CI-only. Qwen’s default inline-media limit on this path is 10 MiB, and the reviewed image path bounds rendered images within its 1568×1568 visual budget. These are Qwen implementation limits, not MCP protocol limits.

Current overlap: MCP extensions reach lifecycle, resource persistence, interactive UI, discovery, skills, enterprise authorization, middleware, and events

Section titled “Current overlap: MCP extensions reach lifecycle, resource persistence, interactive UI, discovery, skills, enterprise authorization, middleware, and events”

The released MCP 2026-07-28 specification formalizes an opt-in extensions framework. The released Tasks extension (io.modelcontextprotocol/tasks) moves long-running operations beyond a simple synchronous tool call: a server can return a durable task handle and the client can poll and update the task lifecycle. This creates real overlap with part of UHP’s execution-lifecycle problem space, even though the ownership boundary remains different.

Released MCP 2026-07-28 also deprecates three core features

Section titled “Released MCP 2026-07-28 also deprecates three core features”

SEP-2577 is Final and the released MCP 2026-07-28 specification marks Roots, Sampling, and Logging as Deprecated. Their existing methods, types and capability flags remain wire-compatible during the deprecation window, and the specification keeps them functional for at least twelve months after this revision before they become eligible for removal. New implementations SHOULD NOT add support except where backward compatibility requires it.

The migration direction is explicit: replace Roots with tool parameters, resource URIs or server configuration; replace server-initiated Sampling with direct LLM-provider integration; and use stderr for stdio logging or OpenTelemetry for structured observability instead of protocol Logging. The same release also reclassifies the legacy HTTP+SSE transport as Deprecated in favor of Streamable HTTP.

For the UHP comparison, this matters because MCP is simultaneously expanding through extensions such as Tasks and pruning low-adoption core primitives. In particular, deprecated Sampling should not be cited as evidence that current MCP core is converging on a durable complete-model or complete-harness execution contract. The wire surface still exists during the compatibility window, but the standards direction is away from new implementations depending on it.

MCP also has a released MCP Apps extension, identified as io.modelcontextprotocol/ui. MCP Core Maintainers announced it on 26 January 2026 as the first official MCP extension, and the 2026-07-28 release carries it inside the formal extensions model. MCP Apps lets a tool associate itself with a predeclared UI resource using the preferred _meta.ui.resourceUri metadata; UI resources use the ui:// scheme and the extension’s HTML profile so a compatible host can render an interactive interface instead of reducing every interaction to text.

The ownership boundary remains MCP-host specific. The host renders the app in a sandboxed iframe and app↔host communication uses JSON-RPC over postMessage. The extension can support UI-initiated server-tool calls and model-context updates subject to the host’s advertised capabilities and policy, while the security model keeps the embedded app behind sandbox/CSP and auditable host mediation rather than granting it unrestricted host authority.

For UHP, MCP Apps broadens the human interaction surface around MCP capabilities; it does not define how a product selects or drives a complete harness, and it does not replace UHP task/session/continuation/file/artifact semantics. A UHP-driven harness can use an MCP server whose tools expose MCP Apps without turning the MCP app itself into a UHP harness or establishing native UHP adoption by the MCP server/client.

The official MCP Agents Working Group now makes that agent-facing direction more concrete. Its charter says agent-backed systems are commonly exposed today as ordinary tools or through framework-specific integrations, leaving durable execution, capability discovery, delegation and multi-turn interaction to ad hoc conventions. The group stewards Tasks as MCP’s foundation for durable asynchronous execution, is working to stabilize it and promote it into core MCP, and is evaluating whether an Agents Extension is needed for patterns such as agent-as-tool, remote-agent and supervisor/sub-agent interaction.

That is active standards work, not a released Agents Extension. The charter lists Tasks stabilization/core promotion, Agents Extension evaluation and a two-level-agent proof of concept as In Progress. It also explicitly keeps general-purpose agent frameworks/runtimes — including internal planning, memory, model selection and orchestration — out of scope; transport/session mechanics remain with the Transports WG and general callback/event delivery with Triggers and Events. The current evidence therefore shows MCP formally evaluating a broader agent interoperability surface without yet standardizing a complete harness runtime contract.

Skills Over MCP is now a Final Extensions Track SEP with a released stable extension specification. SEP-2640 reached Final on 11 September 2026, PR #2640 merged on 13 September at 1eb5bbe8, and PR #3353 immediately added official Skills extension documentation and client-support tracking at 2997f33b. The canonical docs define extension identifier io.modelcontextprotocol/skills, use MCP Resources plus skills/list / skills/get to serve Agent Skills, and optionally expose resources/directory/read. On 16 September, ext-skills PR #146 removed the repository’s former Experimental incubation framing and made specification/stable/skills.mdx the explicit source of truth for the released extension. The released MCP base specification nevertheless remains 2026-07-28, and the official client matrix still lists only partial Skills support for ChatGPT, fast-agent and MCP Inspector, so this maturity correction is not a new core-spec revision or universal host/SDK support. See Skills Over MCP for the dedicated transport, security and maturity boundary.

The official MCP Filesystems Working Group now owns a separate bidirectional-Resources track. PR #3282 merged its charter on 8 September 2026. The WG intends one Extensions Track SEP covering Resource create, update, delete and metadata/stat, optimistic concurrency and lost-update avoidance, create-if-absent semantics, and consistent interaction with notifications/resources/updated, ttlMs, cacheScope and lastModified.

That is active standards work, not released Resource-write behavior. The charter lists “SEP: Filesystem Operations for Resources” as Ideating. Current MCP 2026-07-28 Resources still standardize list/read/templates and notifications/subscriptions; file:// identifies filesystem-like Resources but does not itself add write methods or imply direct host-disk access. See MCP Filesystems for the dedicated maturity and UHP file/artifact boundary.

The WG also says to reconcile open SEP-2571 (resources/create / resources/delete) and open Draft SEP-2532 (resources/stream), rejects a parallel files/* family, and leaves host sandbox/local-disk semantics plus new authorization policy outside its scope.

A separate discovery effort is MCP Server Cards. The Server Card Working Group is developing a static, pre-connection document that describes a remote MCP server’s identity, transport endpoints and supported protocol versions. An AI Catalog entry can link to or embed a Server Card for domain-level discovery, while the card itself remains MCP-specific connection metadata. The current design intentionally omits tool/resource/prompt listings and local-installation metadata because those surfaces can be dynamic or belong to the MCP Registry.

The maturity boundary is important. SEP-2127 is still an open, unmerged proposal, and the official experimental Server Card repository explicitly says the work is for prototyping and feedback and is not an accepted or official MCP extension. That repository reserves <streamable-http-url>/server-card as the recommended card location and describes graduation into the main MCP specification as future work. The Server Card Working Group’s own roadmap also lists graduation as its first priority, gated on SDK reference implementations and related readiness work.

Server Cards complement rather than replace live MCP discovery. Static cards let a client or registry learn where and how to reach a remote MCP server before sending protocol requests; server/discover can provide an up-front supported-version/capability/identity snapshot, while per-request metadata and live list/read results remain authoritative for dynamic behavior. This is also why Server Cards fit naturally beside AI Catalog/ARD without turning those discovery layers into execution protocols.

A separate experimental MCP effort targets cross-cutting middleware. The official Interceptors Working Group charter says the group is standardizing a new interceptor primitive for context operations at trust-boundary lifecycle points such as tool calls, resource reads, prompt handling, sampling and elicitation. Its target model has validators that inspect and make pass/fail decisions and mutators that transform payloads, with in-process, sidecar and remote-service deployment models.

Current primary sources make the maturity boundary especially important. The WG charter still lists the Interceptors SEP as Draft and makes an accepted SEP a success criterion. The experimental reference repository explicitly says the work is for prototyping and feedback and is not an accepted or official MCP extension. The charter currently names SEP-1763, while the experimental repository says it tracks the newer SEP-2624 proposal; SEP-2624 remains open and proposes protocol-level discovery/invocation methods including interceptors/list and interceptor/invoke. This guide therefore tracks MCP Interceptors as an active experimental standardization effort, not as released 2026-07-28 behavior, and does not treat either draft identifier as finalized.

The official Triggers and Events Working Group targets another distinct gap: proactive server-to-client delivery when server-side state changes. Its charter covers a standardized callback mechanism such as webhooks, subscription lifecycle, delivery semantics, event ordering, and coordination with the Agents Working Group where Tasks completion notifications intersect with event triggers.

That work is not released MCP behavior. MCP 2026-07-28 already moved subscribed protocol change notifications to the in-protocol subscriptions/listen stream; Triggers and Events is incubating callback-style delivery beyond that existing stream model. The WG charter still lists “SEP: Events in MCP v1 RFC” as Ideating, and its success criteria require an accepted SEP, implementations in at least two Tier-1 SDKs, and conformance-test coverage. The official incubation repository is explicitly Experimental and says its contents do not represent official MCP specifications or recommendations.

Transport roadmap: a formal WG now owns HTTP-native convergence

Section titled “Transport roadmap: a formal WG now owns HTTP-native convergence”

The official MCP documentation now publishes a charter for the Transports Working Group. Its scope is deliberately below application semantics: transport bindings, framing/delivery, request and envelope metadata, cancellation/termination, connection lifecycle, multiplexing, load distribution, reconnection/resumption, request association, stateless operation, and transport wire security. Tools, resources, prompts, Tasks, agents, events, authorization policy, and other application-layer behavior remain owned elsewhere.

The WG’s current roadmap targets the 2026-12-15 MCP specification release and makes three tracks Priority work:

  1. Tool/Primitive Versioning — an opaque ETag-like identifier for primitive definitions so clients can invoke against a known definition version and servers can preserve compatible behavior, reroute, or reject with a distinct version-mismatch error.
  2. HTTP over STDIO — carrying Streamable HTTP semantics over a subprocess’s stdin/stdout so local and network deployments can share one transport model instead of duplicating transport metadata across legacy stdio and HTTP paths.
  3. Pluggable Transports — keeping Streamable HTTP as MCP’s primary/reference binding and the only transport every client must support, while defining an optional custom-transport interface and conformance criteria for specialized environments.

The same roadmap puts Error Standardization, Incremental Tool Results, Content Language Negotiation, and Tool Capability Requirements in Best Effort. It explicitly marks protocol-level Sessions / Conversation IDs as Not Planned for 2026-12-15. That roadmap position is consistent with the released 2026-07-28 direction, which already removed the prior connection-scoped protocol session and initialization handshake; the roadmap says session-like state should only be reconsidered if concrete use cases cannot be addressed by narrower mechanisms such as client-carried state, Tasks, caching, or server-minted handles.

For the UHP comparison, the important signal is narrower than “MCP is becoming UHP.” Released MCP already uses per-request stateless semantics, while its transport roadmap continues converging local/remote transport behavior and considers versioned primitives, standardized errors and incremental results without planning to reintroduce a protocol-level session/conversation primitive for the target release. UHP, by contrast, standardizes sessions, continuation, task lifecycle, files/artifacts and a complete client→server→harness execution boundary. Transport convergence may reduce implementation differences inside MCP without erasing that higher-level scope distinction.

Another released extension has already moved MCP beyond the future-roadmap stage in enterprise identity: Enterprise-Managed Authorization (EMA) (io.modelcontextprotocol/enterprise-managed-authorization) is a stable MCP extension. It introduces an enterprise Identity Provider (IdP) as the centralized policy point and uses an Identity Assertion JWT Authorization Grant (ID-JAG) so an MCP client can obtain a scoped access token from an MCP server’s authorization server without a separate interactive authorization flow for every server.

The underlying OAuth work has a different maturity level from the MCP extension. draft-ietf-oauth-identity-assertion-authz-grant-04 is an active OAuth Working Group Internet-Draft and identifies Cross-App Access (XAA) as the application-ecosystem name for this pattern. Its base identity-chaining specification, draft-ietf-oauth-identity-chaining-17, is still an Internet-Draft but has advanced to the RFC Editor queue. Those IETF statuses should not be collapsed into MCP’s own stable extension status.

On 24 August 2026, Okta announced General Availability of Agent SSO, powered by XAA, and says it can govern agent access to applications, APIs, tools, and MCP servers with short-lived identity-governed tokens. That is concrete implementation/adoption evidence for the XAA/EMA authorization pattern, not evidence of UHP adoption. Okta’s developer guidance also scopes XAA to delegated access originating from an active signed-in user context and explicitly says not to use it for autonomous/background/M2M workflows without an end-user context.

Enterprise deployment gaps now have a formal MCP Interest Group

Section titled “Enterprise deployment gaps now have a formal MCP Interest Group”

On 29 August 2026, MCP merged the charter for its Enterprise Interest Group (Enterprise IG). This is an Interest Group, not a standards Working Group: it does not write or own SEPs. Its mandate is to collect enterprise deployment gaps as vendor-neutral problem statements and recommendations, then route them to the Working Groups that own specification work.

The charter makes several agent- and harness-adjacent requirements explicit: enterprise authentication and identity; identity propagation and session context across spawned or delegated agents, including identity lineage, least-privilege child authority, descendant revocation and multi-agent auditability; standardized audit/compliance evidence; gateway/proxy handoff and policy enforcement; multi-region resilience; enterprise-architecture integration; configuration portability; and interceptor/middleware requirements such as PII redaction and compliance validation.

Why this does not collapse UHP into MCP: MCP Tasks applies to operations exposed through an MCP server, and the Agents WG is explicitly evaluating how far agent-backed MCP interoperability should extend beyond Tasks; MCP Apps standardizes interactive UI associated with MCP tool capabilities; Server Cards describe how to discover/connect to remote MCP servers before invocation; EMA governs enterprise authorization to MCP servers; Skills Over MCP distributes reusable skill material; the Filesystems WG is standardizing bidirectional Resource persistence; the proposed Interceptors layer governs or transforms context flowing through MCP boundaries; Triggers and Events targets proactive callback/event delivery around MCP server state and task completion; the Enterprise IG gathers non-binding production requirements for the groups that own specification work; the Transports WG is evolving how MCP messages are carried and associated. The Agents WG itself excludes general-purpose agent framework/runtime internals, and no accepted Agents Extension currently standardizes selecting/configuring interchangeable complete harness runtimes, UHP sessions/containers/files/artifacts across those harnesses, or the server-to-harness execution boundary. The overlap is now substantive enough to track, but the architectural scopes are still distinct.

Roadmap signal: MCP is moving toward more agent-facing primitives

Section titled “Roadmap signal: MCP is moving toward more agent-facing primitives”

The MCP Core Maintainers’ 22 August 2026 roadmap materially broadens the direction of future MCP work. Its priority areas include Agentic Messaging Primitives, HTTP-native transport unification/hardening, and further agent identity and enterprise-ready security work such as DPoP, Workload Identity Federation, and standard token exchange. The now-formally documented Agents Working Group turns part of that direction into active standards work: Tasks stabilization/core promotion and an in-progress evaluation of whether agent-as-tool, remote-agent and supervisor/sub-agent use cases need an Agents Extension. The Transports Working Group separately makes the transport direction concrete through its 2026-12-15 roadmap for primitive versioning, HTTP over stdio and pluggable transports. The same ecosystem also has active Filesystems, Server Card, Interceptors, and Triggers and Events Working Groups pursuing bidirectional resource persistence, pre-connection discovery, middleware, and proactive event delivery, while the Enterprise Interest Group feeds enterprise deployment requirements into the relevant standards tracks. Those roadmaps and work items should be read alongside — not instead of — current released extensions such as Tasks, MCP Apps and Enterprise-Managed Authorization.

Why this matters for UHP: overlap already exists around long-running operations, interactive UI, skill distribution, and enterprise authorization at the MCP extension layer, while active work may deepen overlap around resource persistence, agent-backed delegation/multi-turn interaction, pre-connection discovery, middleware/governance, server-initiated events, transport/versioning/error semantics, messaging, enterprise requirements and identity/delegation. The architectural boundary is still different today — UHP standardizes client-to-harness execution, while MCP standardizes an AI application’s connection to external capabilities plus opt-in extension surfaces; MCP’s Agents WG is now explicitly evaluating how much additional agent-facing behavior belongs at that interoperability boundary.

Example

Section titled “Example”

Imagine a product that lets users ask an agent to inspect a repository, query an issue tracker and produce a patch. The product could send the job through UHP to a configured Claude Code or Codex harness. Inside that harness, MCP could expose GitHub, Sentry or internal database tools. UHP gives the product a stable task/session/file lifecycle; MCP gives the harness a stable capability interface.

When UHP adds value

Section titled “When UHP adds value”
  • You need to switch or compare complete harness runtimes without rewriting product execution logic.
  • You need common task states, session continuation, artifacts and cancellation across those runtimes.
  • You are building infrastructure that manages harnesses as shared execution backends.

When MCP adds value

Section titled “When MCP adds value”
  • You want an AI application to discover and use external tools or context through a standard interface.
  • You want tool providers to expose focused capabilities independently of the AI host.
  • You need a broad ecosystem of interoperable external integrations.

Primary sources

Section titled “Primary sources”

Related: dedicated MCP Filesystems coverage tracks bidirectional Resource standards work and its UHP file/artifact boundary; Skills Over MCP tracks SEP-2640’s maturity and security boundary; independent UHP clients are catalogued on UHP clients; editor/UI-to-agent integration is compared in UHP vs ACP.