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

Protocol extension

UHP Harness Plugins

UHP 2026-09-12 adds an optional Harness Plugins sub-protocol that installs a portable Agent Plugins package into a hosted harness without redefining the package format.

Verified: Protocol: 2026-09-12Agent Plugins: 1.0.0

UHP 2026-09-12 adds Harness Plugins as an optional protocol surface. A UHP plugin is not a new UHP-specific package format: it is an Agent Plugins 1.0.0 package containing a root plugin.json, optional mcp.json, and optional Agent Skills under skills/.

UHP defines the layer around that package: how it is attached to a harness, transported and stored by a server, exposed through discovery, materialized for execution, exported again, and tested for conformance.

Agent Skills SKILL.md + skill folder one portable skill
Agent Plugins plugin.json + mcp.json + ... portable extension package
UHP Plugins harness binding + HTTP API package installed into a hosted harness

This is an additive change from 2026-08-11. Existing direct harness mcpServers and skills retain their previous shape and meaning. A server that does not implement Harness Plugins can remain conformant; it reports the plugins capability as unsupported and the plugin-specific conformance checks skip rather than pass.

The harness object gains a plugins array. The package itself is supplied through files or a server-side blob handle. The server derives the package-facing state instead of trusting client copies:

  • manifest from validated plugin.json;
  • mcpServers from mcp.json;
  • skills from immediate skills/<name>/SKILL.md children;
  • skipped entries for isolated components that cannot be loaded.

The package is the source of truth. Editing a derived mcpServers or skills projection does not rewrite the plugin package.

Two plugins with the same manifest name in one harness are refused. A rejected plugin write must leave the harness unchanged.

Direct UHP harness mcpServers remain remote-server configuration. Harness Plugins additionally supports Agent Plugins stdio MCP entries because the plugin provides the filesystem roots and files a subprocess needs.

The mapping is explicit:

Agent Plugins MCP typeUHP plugin transport
streamable-httphttp
ssesse
stdiostdio

${PLUGIN_ROOT} and ${PLUGIN_DATA} remain package placeholders. A UHP server reports them as written and expands them only inside the execution environment where the plugin is materialized.

At execution time the effective configuration combines:

  • enabled direct harness MCP servers;
  • MCP servers derived from every enabled plugin;
  • enabled direct harness skills;
  • skills derived from every enabled plugin.

The direct fields are not rewritten to contain plugin-derived components. That preserves read/modify/write round trips and prevents a plugin server or skill from being duplicated into the harness’s direct configuration.

disabledTools continues to apply across the effective tool set.

UHP 2026-09-12 adds harness export as an installable Agent Plugins package. Export is deliberately lossy where carrying a value would be unsafe or non-portable: credentials are omitted and the omission must be recorded rather than silently disappearing.

This gives the new sub-protocol a two-way interoperability boundary:

Agent Plugin package → UHP harness → exported Agent Plugin package

That does not mean UHP now owns the Agent Plugins format. Agent Plugins remains authoritative for package structure and component validation; UHP owns the hosted-harness binding and transport semantics.

A server that implements the sub-protocol advertises the plugins capability and supported plugin_schemas. The version adds five plugin-specific error codes:

  • plugin_invalid
  • unsupported_plugin_schema
  • unsupported_transport
  • plugin_conflict
  • plugin_not_found

The protocol also adds a plugin-files endpoint and a harness-export endpoint so clients can retrieve a stored package and produce a portable package from a configured harness.

Plugins are third-party code and configuration. The new Security section requires hosts to treat them accordingly. In particular, a plugin’s stdio MCP process executes inside the agent sandbox rather than becoming an unsandboxed host process merely because its command was packaged with the plugin.

Agent Plugins 1.0.0 itself does not define portable OAuth or credential-reference fields. UHP export therefore cannot treat visible package headers or environment variables as a portable secret channel.

The official suite advances to package 2026.9.12 and 74 checks:

  • Core: 40
  • Extended: +8
  • Full: +25
  • Full total: 74

The new P-01 through P-10 checks cover plugin package round trips, derivation, refusal behavior and export. They are Full-class but capability-gated. If a server reports plugins: false, those checks skip; a skip is never counted as a pass.

The repository’s checked-in HarnessRouter reference record is still the earlier 64/64 live run from 4 September. PR #165 explicitly states that the Community Edition gateway at that merge point still serves 2026-08-11 and reports no plugins capability. Therefore there is no verified 74/74 HarnessRouter runtime result to claim yet.

Before this release, UHP and Agent Plugins were complementary but had no standardized UHP binding. That boundary changed on 12 September 2026: UHP now normatively adopts Agent Plugins 1.0.0 as the package format for the optional Harness Plugins sub-protocol.

The standards still solve different problems:

  • Agent Plugins defines the portable extension package.
  • UHP defines how a product drives a complete harness and, when this optional capability is implemented, how that package is installed into and exported from the harness.
  • MCP remains authoritative for MCP wire behavior.
  • Agent Skills remains authoritative for skill package semantics.

See UHP vs Agent Plugins for the boundary comparison and Conformance for the measurement rules.