seller-tool-onboarding

Follow the routing decision tree: check if the tool needs auth, whether the vendor issues job-scoped tokens, whether auth travels in one replaceable header, and whether a CLI must hold login state. The first matching route (Public, Direct token, Proxy swap, or Holder) determines the configuration steps.

Use the Proxy swap route with a `[[sandbox.mcp_tools]]` table in config.toml pointing at the vendor's MCP endpoint and a host credential file. The credential proxy swaps the real token in at egress, so the job container only ever holds a worthless per-job placeholder.

The Holder route runs a persistent holder container per tool that keeps the vendor CLI's login and exposes operations to jobs over a private socket. It is configured via `[[sandbox.held_tools]]` entries and is the only fully automated route shipping today, proven live with two tools.

Only when auth travels in a single replaceable header and request semantics are constrainable. Body-dispatched APIs like GraphQL or MCP tool calls are not constrainable by path alone, and vendors that reflect the Authorization header into response bodies must not be onboarded on this route.

Browser logins are not supported because the enroll-once model requires a persistent, refreshable login the holder can maintain without a browser. A short-lived non-refreshable login would force per-job re-login, so the skill instructs you to state this plainly and stop.

Run `cargo test -p maxplayer-core --features wallet,acp --lib -- --ignored --nocapture held_tool::live_tests::live_two_tools` with docker and the kit image. It starts two holders, runs jobs against both, refuses an escape attempt, and proves logins persist across restarts.