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

Comparison

UHP vs Agent Plugins

UHP standardizes client-to-complete-harness execution. Agent Plugins standardizes a portable package for reusable Agent Skills and MCP server configuration. They solve different interoperability problems and can coexist.

Verified: UHP: 2026-08-11Agent Plugins: 1.0.0 Published

Different portability boundaries

Section titled “Different portability boundaries”

Unified Harness Protocol (UHP) defines a common HTTP execution contract between an agent product and a server that drives complete harness runtimes. Its portable surface includes discovery, tasks/responses, sessions, progress, files/artifacts, cancellation and structured errors according to conformance class.

Agent Plugins is a separate open, vendor-neutral packaging standard. The published 1.0.0 specification defines a plugin directory with a required root plugin.json and portable component locations for Agent Skills and optional MCP server configuration. The standard intentionally leaves installation sources, registries/marketplaces, enablement UX, permission prompts, trust policy and sandboxing to the client.

QuestionUHPAgent Plugins 1.0.0
What is portable?How a client executes work through a complete harnessReusable extension package structure and supported component discovery
Primary artifactHTTP API plus task/session/event/file semanticsPlugin directory with plugin.json, optional skills/ and optional mcp.json
Runtime task/session lifecycle?YesNo; client/runtime lifecycle remains outside the package standard
Tool/context interoperability?UHP drives a selected harness; the harness may use its own tools and protocolsCan package Agent Skills and MCP connection configuration; MCP remains authoritative for MCP wire behavior
Installation/marketplace contract?Not a plugin distribution standardExplicitly client-managed and outside the portable core
Permissions/sandboxing?Server/runtime security is part of the execution deployment boundaryExplicitly client-managed rather than standardized by the package format
Could they coexist?YesYes; a harness driven through UHP could independently load Agent Plugins if its runtime supports them

Current Agent Plugins status

Section titled “Current Agent Plugins status”

The official specification site identifies Agent Plugins 1.0.0 as Published. The current specification repository also contains a 1.1.0 working draft; its current main at this verification cutoff is ff8ab5e392cc87bd88d87c060815a87490e51003, whose merge starts that working-draft line. The working draft should not be described as the current published release.

The portable core is deliberately small:

  • plugin.json is required at the plugin root and declares the target Agent Plugins schema version.
  • skills/ carries Agent Skills in the separate Agent Skills format.
  • mcp.json can describe MCP servers using stdio, Streamable HTTP and optionally legacy SSE according to client transport support.
  • ${PLUGIN_ROOT} and ${PLUGIN_DATA} provide defined package/data placeholders in supported MCP configuration fields, with filesystem containment requirements.
  • Agent Plugins 1.0.0 defines no OAuth configuration or portable credential-reference fields. Authorization discovery, user interaction and credential storage remain client-managed; configured headers and environment values are explicitly not a portable secret mechanism.
  • Reverse-domain client-extension namespaces allow product-specific behavior without changing the portable core; other clients may ignore those extensions while still processing portable components.

The official compatible-clients page currently lists multiple implementations, including VS Code, Cursor, GitHub Copilot, ChatGPT & Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot and NanoClaw. That page is useful adoption evidence, but it is a client-support registry rather than UHP adoption evidence.

Fresh implementation signal: Cline current main

Section titled “Fresh implementation signal: Cline current main”

Cline merged two related changes on 2 September 2026, after the stable CLI 3.0.61 release published earlier that day:

  • CLI PR #13657 / commit 97b07001 adds Hub-owned Agent Plugin inventory to the interactive configuration surface. Cline distinguishes those packages from Cline Plugins, can toggle an Agent Plugin through the Hub, and refreshes the associated skills and MCP contributions from Hub settings rather than mutating client-local plugin settings.
  • Desktop PR #13658 / commit 9e0af5c0 mirrors that boundary in Customize: Agent Plugins discovered by the Hub are shown separately from Cline marketplace plugins, their contributed skills appear in the Skills inventory, Hub-managed enablement is surfaced, and open Desktop views refresh when Hub settings change.

The implementation deliberately labels these entries as agentPlugin and avoids treating portable Agent Plugins as installed Cline marketplace entries. That is meaningful evidence that Cline is integrating the Agent Plugins package model as a distinct extension family.

Why this matters for UHP

Section titled “Why this matters for UHP”

Agent interoperability has more than one portability layer. A team may want the same reusable skills/MCP configuration available in several agent clients while also wanting one execution API across several complete harnesses. Agent Plugins addresses the first problem; UHP addresses the second.

A plausible composition is therefore:

agent product → UHP server → selected harness → Agent Plugin components → Agent Skill / MCP server

That topology is architectural composition, not protocol adoption. No source reviewed establishes a standardized UHP↔Agent Plugins binding, a UHP requirement to load Agent Plugins, or a HarnessRouter feature that imports an Agent Plugin package as part of the UHP contract. Likewise, a harness supporting Agent Plugins does not thereby implement UHP.

For Cline specifically, keep the two control boundaries separate: HarnessRouter’s released Cline backend remains pinned to CLI 3.0.60 and adapts Cline through its --json headless interface. The newer Agent Plugins work is upstream Cline current-main extension management and is not evidence that HarnessRouter v0.12.1 loads Agent Plugins through its UHP→Cline path.

Primary sources

Section titled “Primary sources”