Livepeer Agent · Operations

Onboard a community capability — from a chat message

A provider self-tests their capability and sends you five things. You paste one message into Claude Desktop. Their capability is routable on the agent seconds later — no VM edits, no JSON, no curl. The admin MCP does the wiring.

Where Claude Desktop (or Cowork) with the admin MCPVerb orch_onboardGate admin role

One-time setup. In Claude Desktop → Settings → Connectors, add the Livepeer Agent admin MCP with your mgmt_live_* key. Ask Claude "what's my console role?" — it should say admin. If it says none, your key isn't an admin key.

Step 1 — What the provider sends you

The provider does the technical part on their side and hands you five plain values. If any are missing, ask for them before onboarding — the automation can't proceed without the first two.

They send	Example
Discovery URL ·required	`https://caps.kiloutcorp.link:11112/discovery`
Contact email ·required	`ops@example.com`
Capability name(s) + "I self-tested each one"	`kokoro-tts` — returns real audio
On-chain address (their staked orchestrator)	`0x…`
Network	`arbitrum-one-mainnet`

"Self-verified" is their job, not yours. Before they reach out, the provider self-tests each runner with the app-examples client and confirms it returns a real result. You don't reproduce that — you trust it, onboard, and spot-check once (Step 3). An advertised-but-unhealthy runner is the one thing that fails onboarding, and it's on them to have cleared it.

Step 2 — Onboard it (one message)

Scenario: the provider serves kokoro-tts, which another vetted provider already offers — so this is extra capacity for a shared capability, and they've self-tested it. Paste this into Claude Desktop, filling in their two required values:

You → Claude Desktop

A community orchestrator wants to onboard. Discovery URL https://caps.kiloutcorp.link:11112/discovery, contact Livepeer88@proton.me. They serve kokoro-tts and have self-tested it. kokoro-tts is a shared capability we already offer — add them as extra capacity. Email them the outcome.

Claude (runs orch_onboard)

Onboarded "kilout" — 1 capability registered + routable:

  • kokoro-tts

Registered and routable now via merit + admission. I emailed Livepeer88@proton.me a summary. To promote it to verified-live, run a quick verification pass, then mark it live.

That's the whole onboarding. You never told it "shared" vs "new" or touched routing — orch_onboard reads their /discovery, classifies each capability, and records it in the registry, which is the routing config. A shared capability automatically joins the merit pool for that name, gated by a per-capability admission list so only vetted providers serve it.

If a capability comes back skipped

Claude will list any it couldn't onboard with the reason — almost always a fixable provider-side issue (a scaffold livepeer-example/* app name, a null price, or capacity 0). Forward the reason to the provider; nothing to do on your side.

Step 3 — Confirm and mark it live

Onboarding leaves the capability at registered — already routable. Promoting to live is your "I've seen it work" stamp. One more message:

You → Claude Desktop

Run kilout's kokoro-tts once to confirm it's serving, then mark it live.

Claude

kokoro-tts returned audio from kilout in ~3s. Marked kilout / kokoro-tts live. It now shows as verified-live in orch_list.

Note on verification. The confirm render is paid through a pymthouse key (community capabilities only settle on that plane). If your admin connector can't run capabilities, either connect the agent MCP with a pymthouse key or just spot-check the provider's own health URL, then say "mark kilout live."

That's it — why there's no step 4

No VM edit, ever. The registry is the single source of truth for live-runner routing, so recording a provider in it via orch_onboard is the wiring — the SDK picks it up on its next refresh. The old "SSH in and edit LR_OFFERINGS_JSON" step is gone. Routing among admitted providers is by merit (price + capacity + latency); the per-capability admission list is what stops a shared name from ever routing to an unvetted node.

The verbs Claude uses (reference)

You speak plain English; Claude picks the verb. For the record:

Say something like…	Verb
"Onboard this discovery URL, contact X, email them"	`orch_onboard` — probe + classify + register (+ notify)
"List the community orchestrators / who's live"	`orch_list`
"Show me everything about kilout"	`orch_get`
"Mark kilout's kokoro-tts live" / "deactivate moudi"	`orch_update`
"Email pon that flux-dev is live"	`orch_email` (dry by default; send on confirm)

Proven on Kilout (9/9 live), FastAgents, Pon, moudi. Routing safety (merit + per-capability admission) and the cold-handshake timeout fix (LR_HANDSHAKE_TIMEOUT_S, 2026-08-12) live in the SDK live-runner selector. The same orch_onboard pipeline also powers the Discord /announce self-serve flow — see the Discord setup + go-live guides.