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

Comparison

UHP vs MCP Live (MCPL)

UHP standardizes product-to-server execution of a selected complete harness. MCP Live (MCPL) is an independent draft extension to MCP that lets servers participate actively in the host's inference lifecycle through push events, context hooks and server-initiated inference.

Verified: UHP: 2026-08-11MCPL: 0.5.0-draft

The one-sentence difference

Section titled “The one-sentence difference”

UHP is a client-to-server contract for executing work on a selected, configured complete harness. MCPL is an independent experimental extension of the MCP host↔server relationship that gives an MCP server policy-bounded ways to influence or initiate inference.

The boundaries are therefore different. A UHP client asks a UHP server to run a task and receives a Response, events, continuation and artifacts. MCPL keeps the MCP host/server relationship and adds proactive server participation: push/event, inference-lifecycle hooks, inference/request, feature/capability policy and related extension methods.

MCPL is maintained by Anima Research. It is not an official Model Context Protocol project, not a UHP extension, and not a HarnessRouter feature.

Current MCPL status

Section titled “Current MCPL status”

The strongest current version source is SPEC.md, which identifies MCPL 0.5.0-draft, status Draft, dated August 2026. The repository root README still says v0.4.1-draft; that disagreement is itself useful maturity evidence and this guide follows the specification file rather than silently treating the README value as current.

The repository has no GitHub Releases at this cutoff. Current main is actively evolving: its latest observed commit, f684cae, carries RFC-005 revision 3 for bulk-content references, tightening URI exposure, same-origin authentication handling and metadata bounds. RFC-005 is still Draft and targets MCPL 0.5; it is evidence of active protocol work, not a released MCPL version.

MCPL has more implementation evidence than a prose-only proposal. Its project audit enumerates one host implementation, two core libraries and multiple server trees. Its conformance directory freezes manifest-digest vectors and explicitly says the TypeScript mcpl-core-ts and Rust mcpl-core implementations were built independently and checked for convergence. However, the same project’s August audit documented substantial spec/implementation drift across the earlier 0.4.1-draft fleet. That combination supports active implementation and protocol development, not mature multi-vendor interoperability or stable compatibility guarantees.

The important MCP 2026-07-28 compatibility boundary

Section titled “The important MCP 2026-07-28 compatibility boundary”

MCPL describes itself as a backward-compatible MCP extension, but its current 0.5.0-draft wire negotiation is still written for the legacy MCP handshake era. It advertises capabilities.experimental.mcpl during initialize, and its example carries MCP protocol version 2024-11-05.

Released MCP 2026-07-28 changed that lifecycle materially: the official MCP project removed initialize / initialized and Mcp-Session-Id, made requests self-describing, added optional server/discover, and formalized extensions under a negotiated capabilities.extensions map with reverse-DNS identifiers.

That means the current MCPL draft should not be described as already aligned with modern MCP 2026-07-28. A modern mapping could be designed, but no primary source reviewed here updates MCPL’s negotiation model to the released stateless lifecycle or registers MCPL through the official extension framework. The safe classification is: independent MCP-adjacent draft built on the legacy handshake model, with modern-MCP alignment not yet established.

Architectural comparison

Section titled “Architectural comparison”
DimensionUHPMCP Live (MCPL) 0.5.0-draft
Primary boundaryProduct/client ↔ UHP server ↔ complete harnessMCP host/client ↔ MCP server, extended for active inference participation
Primary purposeExecute interchangeable configured harnesses through one task/session contractLet MCP servers proactively signal, shape or request inference under host policy
Core work/state modelResponses, Sessions, Events, Containers, Files and configured HarnessesMCP methods plus push/event, context hooks, inference lifecycle/request, channels, feature sets and capability grants
Who initiates work?Client creates a UHP Response/taskEither side can initiate extension interactions; notably a server can push an event or send inference/request
Context boundaryClient supplies task input; harness owns its loop/tools; server reports results/eventsServer can participate around host inference through negotiated hooks and event/inference lanes
Tool relationshipMCP servers can be part of configured harness state; request-level tools is reserved/ignored in UHP 2026-08-11Extends an MCP server rather than replacing the MCP tool/resource/prompt relationship
Transport modelHTTP over TLS; SSE for task streamingJSON-RPC 2.0 inherited from MCP; current draft assumes handshake-era MCP capability negotiation
Authority modelBearer-authenticated principal scope; configured harness is the authority boundary for server-side capabilitiesHost-computed capability grants plus feature-set selection; server advertisements/testimony do not by themselves create host authority
Maturity2026-08-11 Draft with a runnable 63-check conformance suite0.5.0-draft; no GitHub Release; partial conformance artifacts plus first-party implementation/audit evidence

Push events are not UHP Responses

Section titled “Push events are not UHP Responses”

MCPL’s most obvious overlap is proactive work. A push/event lets a server notify the host about an external event that may warrant model inference; inference/request lets the server ask the host for inference directly when that capability is granted.

A UHP Response has different ownership. The client calls POST /v1/responses with task input and the selected configured harness. The server then owns the task lifecycle and reports progress/results. UHP streaming is a stream about an already-created Response; it is not a generic server-to-client event bus that can autonomously create new client work.

Mapping an MCPL push event to a UHP Response would therefore require an explicit application bridge that decides whether an event should create work, under which principal, against which configured harness, with what budgets and persistence. Neither protocol currently standardizes that mapping.

Context hooks are a different control surface

Section titled “Context hooks are a different control surface”

MCPL’s context/beforeInference model is designed to make memory, retrieval and personalization servers composable around inference. The host invokes supporting servers before inference and can admit server-provided context according to negotiated capability/policy.

UHP deliberately sits higher. A configured harness can include system prompts, skills, tool restrictions and MCP servers, but UHP does not standardize the harness’s internal inference-hook graph. If a UHP-served harness uses MCPL internally, that would be harness composition beneath the UHP boundary, not a change to UHP wire semantics.

This is analogous to other internal protocols: a harness may use MCP or ACP internally while UHP remains the outer product↔server↔harness execution contract.

MCPL’s useful authority pattern: server testimony, host decision

Section titled “MCPL’s useful authority pattern: server testimony, host decision”

The current MCPL line is increasingly explicit that server-advertised capability is not equivalent to authority. 0.5.0-draft adds a host-computed hierarchical capability grant and feature-set policy. The current RFC-005 draft applies the same pattern to large content references by separating three objects: server testimony, a host-private reference record, and a model-visible stub.

RFC-005 revision 3 makes its strongest disposition: "never" rule unconditional, limits reusable authentication context to the origin actually dialed, and requires host-side bounds before server-supplied metadata reaches model-visible stubs. Those are useful security design signals for agent infrastructure, but RFC-005 remains draft work and does not alter UHP security requirements.

Implementation evidence is real but still project-centered

Section titled “Implementation evidence is real but still project-centered”

The MCPL repository’s own August audit lists a working fleet rather than only examples: a host, Rust and TypeScript core libraries, and multiple MCPL servers. It also records why maturity must not be overstated. Against the then-current 0.4.1-draft, the audit found unreachable or ungated surfaces, policy-delivery failures, inaccurate capability advertisements and other divergences between the specification and implementations.

The subsequent 0.5 work and RFCs are evidence that the project is actively correcting those boundaries. The manifest-digest conformance vectors are also valuable interoperability work. But this guide did not verify a broad independent-vendor compatibility matrix or a released MCPL conformance suite comparable in scope to UHP’s current 63-check server suite.

Coexistence is plausible without protocol fusion

Section titled “Coexistence is plausible without protocol fusion”

A layered deployment could use both:

Product / workflow client
          │
          │ UHP task/session contract
          ▼
UHP server → configured complete harness
                           │
                           │ MCP / MCPL internal capability layer
                           ▼
                    external server(s)

For example, a product could submit a task through UHP while the selected harness internally uses an MCPL-capable memory or event server to shape inference. The product still sees UHP Responses/Sessions/Files; the harness/host internally sees MCP/MCPL methods and grants.

No primary source reviewed here defines a standardized UHP↔MCPL bridge, a HarnessRouter MCPL integration, native MCPL support in UHP, or native UHP support in MCPL.

What not to infer

Section titled “What not to infer”
Section titled “Related pages”

See UHP vs MCP for the official MCP boundary, Harness composition for internal agent/runtime layering, Security for UHP’s own authority model, and UHP architecture for the client↔server↔harness contract.

Primary sources

Section titled “Primary sources”