Builder surface

Use Prompt Switchboard alongside Codex, Claude Code, OpenCode, and OpenClaw MCP workflows.

Prompt Switchboard is not a generic AI assistant and not a raw browser automation port. It is a local-first compare workspace that exposes a governed MCP surface for compare, retry, export, session, analyst, and next-step workflow actions inside the browser workflow you already trust.

Codex and Claude Code are the strongest repo-specific bindings in this release. OpenCode and OpenClaw can now use repo-shipped starter kits through their generic MCP client surfaces, but they still stay outside the main verified-host story.

What local agents can do here

  • Check whether supported model tabs are ready before a compare run
  • Queue one compare turn from a single prompt
  • Retry only the failed model cards
  • Export compare results as Markdown or summary text
  • Read session state, run AI Compare Analyst, and inspect the built-in next-step workflow

What this surface does not become

  • Not arbitrary browser automation
  • Not a provider-neutral SDK
  • Not a hosted relay
  • Not a write-capable MCP control plane for unrelated sites

Know the boundary at a glance

Codex and Claude Code are the official coding products. Prompt Switchboard is the browser-side orchestration layer that helps those workflows stay compare-first and local-first.

Surface What it is strongest at What Prompt Switchboard adds
Official coding agent surface Reading repos, editing files, running commands, and owning the coding task loop. Prompt Switchboard does not replace that layer.
Prompt Switchboard browser orchestration layer Managing already-open browser sessions, compare turns, retries, exports, and analyst runs. Codex and Claude Code can call this governed product surface over MCP.

Current builder-facing contract

Today the builder-facing contract is the local MCP sidecar plus the shared bridge protocol inside this repository. Prompt Switchboard does not ship a public HTTP API or a general-purpose SDK in this release.

The current transport is stdio for the MCP client and a localhost bridge for the extension runtime. Native Messaging remains a scaffold and future hardening path, not the active transport in this release.

Current MCP tools

  • prompt_switchboard.check_readiness
  • prompt_switchboard.open_model_tabs
  • prompt_switchboard.compare
  • prompt_switchboard.retry_failed
  • prompt_switchboard.get_session
  • prompt_switchboard.list_sessions
  • prompt_switchboard.export_compare
  • prompt_switchboard.analyze_compare
  • prompt_switchboard.run_workflow
  • prompt_switchboard.list_workflow_runs
  • prompt_switchboard.get_workflow_run
  • prompt_switchboard.resume_workflow
  • prompt_switchboard.bridge_status

Current MCP resources

  • prompt-switchboard://analysis/providers
  • prompt-switchboard://builder/support-matrix
  • prompt-switchboard://models/catalog
  • prompt-switchboard://models/readiness
  • prompt-switchboard://sessions/current
  • prompt-switchboard://workflows/templates

If you are evaluating the real integration contract, start with mcp/server.ts for the public tool and resource surface, then read src/bridge/protocol.ts for the shared command and payload contract that the extension and sidecar both use.

The resource layer now tells the same truth as the docs: use prompt-switchboard://analysis/providers when you need the current analyst-lane catalog and runtime boundary, use prompt-switchboard://builder/support-matrix when you need the machine-readable host tiers, starter asset paths, placeholder path, and first-call sequence, and use prompt-switchboard://workflows/templates when you need the built-in workflow template order, supported tool flow, and session-scoped durability note without guessing from prose.

Prompt Switchboard now also ships starter integration kits for the strongest current host bindings. Use the integration-kits folder when you want repo-owned Codex, Claude Code, OpenCode, or OpenClaw starter assets instead of building those snippets from scratch. That folder now also includes companion starter skill templates for all four documented hosts.

If the product lane itself is not proven yet, use the first compare guide before you spend time on the builder lane.

A healthy agent loop is simple: call prompt_switchboard.bridge_status, then prompt_switchboard.check_readiness, then queue a turn with prompt_switchboard.compare, then use prompt_switchboard.analyze_compare and prompt_switchboard.run_workflow when you want the built-in compare-analyze-follow-up path, inspect the latest session-scoped workflow snapshot with prompt_switchboard.get_workflow_run, list recent workflow snapshots with prompt_switchboard.list_workflow_runs, and continue a waiting run with prompt_switchboard.resume_workflow once you have the external step result.

The workflow tools stay product-bound. They stage or inspect the built-in local compare follow-up path; they do not turn Prompt Switchboard into a DAG engine, a hosted orchestrator, or a generic browser automation plane.

How to think about ecosystem fit

The strongest public bindings are MCP, OpenAI Codex, and Claude Code, because current repo evidence and official docs line up there.

OpenCode, OpenClaw, and other MCP-capable agent runtimes can still connect, but Prompt Switchboard should describe them as starter-kit generic MCP paths, not as the core verified-host story.

That also means names like OpenCode and OpenClaw stay in the generic-MCP lane for now. They are real MCP-capable ecosystem surfaces, and this repo now ships starter assets for them, but Prompt Switchboard still does not claim a fully verified repo-owned host lane there.

Surface Current truth
Local MCP sidecar + product actions Supported now
Codex / Claude Code browser workflow lane Supported now as the strongest repo-specific host flow
Repo-shipped integration kits Supported now for Codex and Claude Code, with starter-kit generic MCP assets for OpenCode and OpenClaw
OpenCode / OpenClaw host paths Starter-kit only through generic MCP client flows until a tested repo-owned host lane exists
Repo-local operator helper Maintainer-only and intentionally not a public CLI
Workflow snapshots Session-scoped runtime cache with explicit run/list/get/resume tools, not a durable workflow ledger
Switchyard runtime-backed model source Maintainer-local / partial for the analyst lane when a local Switchyard service is reachable; it does not replace browser-tab compare
Public HTTP API / SDK / plugin ecosystem Planned only, not supported now

Current host setup routes

Host Current truth Official client path Repo-owned starter asset
Codex Repo-specific strongest path config.toml or codex mcp add mcp/integration-kits/codex.config.toml.example
Claude Code Repo-specific strongest path .mcp.json or claude mcp add mcp/integration-kits/claude.mcp.json.example
OpenCode Starter-kit only / generic MCP client flow project-root opencode.json / opencode.jsonc mcp/integration-kits/opencode.jsonc.example
OpenClaw Starter-kit only / generic MCP registry flow openclaw mcp set <name> <json> mcp/integration-kits/openclaw.prompt-switchboard.json.example

The OpenCode and OpenClaw assets are intentionally narrower than the Codex and Claude Code kits. They are real repo-owned starter paths for generic MCP use, but they do not mean Prompt Switchboard already has a fully verified repo-specific host lane there.

If you want the copy-paste page instead of the deeper contract page, use the MCP starter kits guide.

Repo-local operator helper

  1. Run npm run mcp:operator -- doctor to inspect the local bridge state.
  2. Start the sidecar with npm run mcp:operator -- server.
  3. Use npm run mcp:operator -- smoke to prove the tool and resource surface, including the workflow tools.
  4. Use npm run mcp:operator -- live-probe or live-diagnose when the maintainer-local live browser lane needs structure instead of ad hoc inspection.
  5. Use npm run mcp:operator -- live-support-bundle when a live compare still needs screenshots, HTML, and diagnosis captured together.

The operator helper is mixed on purpose: doctor, server, and smoke are executable maintainer commands, while bridge status and workflow staging templates stay inside the governed MCP tool contract instead of inventing a second operator protocol or a public CLI surface.

  • npm run mcp:operator -- bridge-status
  • npm run mcp:operator -- readiness --models ChatGPT,Gemini (cached readiness snapshot)
  • npm run mcp:operator -- workflow-run --session-id session-1 --turn-id turn-1 --prompt "Stage the next move" --models ChatGPT,Gemini
  • npm run mcp:operator -- workflow-list
  • npm run mcp:operator -- workflow-get --run-id workflow-run-123

Workflow snapshots stay session-scoped. If prompt_switchboard.get_workflow_run or prompt_switchboard.list_workflow_runs stops returning a snapshot after the browser session ends, restage the workflow from the compare turn instead of assuming durable cold-start resumability. Use prompt_switchboard.resume_workflow only while that session-scoped run still exists.

For Codex and Claude Code setup details, use their official MCP documentation as the source of truth for client-side configuration:

The repo-specific rule of thumb is simple: Codex uses the official config.toml flow, Claude Code uses the official .mcp.json / claude mcp add flow, and Prompt Switchboard stays the local MCP server plus browser-side product surface.

For the exact trust boundary and transport story, keep the trust boundary page and the README as the canonical public references.