Agent Plugins: submit OpenHands for the Compatible Clients page

Part of OpenHands/software-agent-sdk#4405 — the last unchecked deliverable on that issue: "Reach out to the Agent Plugins project to get OpenHands listed on the Compatible Clients page once conformance is met."

Current state (verified 2026-09-17)

• OpenHands is not listed. lib/compatible-clients.ts in agentplugins/agent-plugins-site currently holds nine entries — VS Code, Cursor, GitHub Copilot, ChatGPT & Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot, NanoClaw. (#4405's body says five; the list has grown since it was written.)
• The listing is a pull request, not an email. CONTRIBUTING.md in the site repo defines a "Compatible Client Submissions" process: add a record to lib/compatible-clients.ts, add logo assets under public/images/logos/<client>/, describe the evidence for each claimed capability and transport in the PR body, and run pnpm build before submitting.
• The implementation is essentially in place. AgentPluginsFormat is registered in _FORMATS ahead of ClaudeCodePluginFormat on main (openhands-sdk/openhands/sdk/plugin/format/__init__.py) as of #5093 (merged 2026-09-17), so a root plugin.json package resolves to the portable format through the public path. #4450, #4451, #4452 and #4453 are closed.
• Not everything the submission needs exists yet. The ADR/design doc and the conformance test sweep (#5156) are still open, and there is no user-facing documentation page describing Agent Plugins support to use as instructionsUrl.

Eligibility constraints that actually affect us

From the site repo's CONTRIBUTING.md:

• "Listings are for user-facing clients. An SDK or library is not a client by itself." The record must therefore name the user-facing OpenHands product, not software-agent-sdk. The repo belongs in the optional sourceUrl, not in name/homepageUrl.
• "Agent Plugins support must be available to users when the listing is published. Announced or planned support alone is not sufficient." So the submission is gated on a release that carries the format into the shipped product surface, not merely on main.
• "The claimed support must be verifiable. Public documentation is preferred." This is what makes the docs page a prerequisite rather than a nicety.
• "Prefer one listing for a recognizable product family." One OpenHands entry, not separate CLI/app/cloud rows, unless their compatibility materially differs.
• The page is explicitly curated and not a directory — maintainers may also weigh whether the client is publicly available, actively maintained, and used beyond its authors. Acceptance is not guaranteed by conformance alone.

Desired Behavior

OpenHands appears on https://agent-plugins.org/compatible-clients with an accurate capability record, landed via our own PR to agentplugins/agent-plugins-site.

The record follows the CompatibleClient type in lib/compatible-clients.ts. Draft:

{
  name: "OpenHands",
  description: "<short, neutral, plain-text description — no Markdown, links, emoji or promotional wording>",
  homepageUrl: "<user-facing product homepage>",
  instructionsUrl: "<docs page documenting Agent Plugins support>",
  sourceUrl: "https://github.com/OpenHands/software-agent-sdk",
  logo: {
    lightSrc: "/images/logos/openhands/light.svg",
    darkSrc: "/images/logos/openhands/dark.svg",
  },
  supports: {
    skills: true,
    mcp: {
      transports: ["stdio", "streamable-http"],
    },
  },
}

sse is deliberately omitted: #4405 question 1 was resolved as "not supported" (entries are reported and skipped, which §7.2.2 rule 4 allows), and the guidance is to enumerate only supported capabilities. There is precedent — ChatGPT & Codex, Hermes Agent and NanoClaw all list stdio + streamable-http only.

Scope

• Confirm conformance against the client conformance checklist before submitting, using the per-item test mapping produced by #5156, so the PR's evidence section can cite tests rather than assertions.
• Write the user-facing documentation page that instructionsUrl will point at: how to install/enable an Agent Plugins package in OpenHands, which component types are honoured (skills, MCP servers), which transports, and the dev.openhands extension namespace.
• Prepare logo assets (official SVG, light and dark variants) and record their provenance for the PR description.
• Open the PR against agentplugins/agent-plugins-site, run pnpm build, and include the evidence the maintainers ask for: supported product surfaces and versions, homepage, setup docs or release notes, and logo provenance. Be ready to supply a screenshot or demo on request.
• Tick the final checkbox on #4405 once the listing is live, which closes out that umbrella issue's deliverable list.

Out of scope

• Any further conformance work — that belongs to #5156, #4453 and the ADR.
• Changes to the portable spec itself; those go through agentplugins/agent-plugins-spec.

Acceptance Criteria

• A user-facing documentation page describing Agent Plugins support in OpenHands is published and linkable as instructionsUrl.
• Agent Plugins support is available in a released, user-facing OpenHands surface (not just on main), and the release/version is recorded here.
• Every item on the client conformance checklist is confirmed, with the covering test named for each.
• Light and dark OpenHands logo assets are prepared with documented provenance.
• A PR adding the OpenHands record to lib/compatible-clients.ts is open against agentplugins/agent-plugins-site, passes pnpm build, and states the evidence for each claimed capability and transport.
• The record names the user-facing product (not the SDK) and claims only skills plus the stdio and streamable-http MCP transports.
• The listing is live on https://agent-plugins.org/compatible-clients and the corresponding checkbox on #4405 is ticked.

Open questions

1. Which surface and homepage URL does the listing name, and what is the neutral one-or-two-sentence description?
2. Who owns and approves the logo assets, and which variants are we cleared to hand to a third-party site?
3. Do we announce anything on our side (blog, release notes) alongside the listing, or let the docs page carry it?

Refs

• Compatible Clients
• Site contribution guide — "Compatible Client Submissions"
• lib/compatible-clients.ts
• Client conformance checklist

Start with the site repo's CONTRIBUTING.md and lib/compatible-clients.ts, then review the client conformance checklist and the test mapping from #5156. In the OpenHands repo, verify the released user-facing support and the documentation page, then prepare the logo provenance and external PR evidence. Done means the site PR passes pnpm build, the listing is live with only verified capabilities, and #4405 is checked off.