Copy the right MCP setup without guessing what MultiAiPanel really supports.

MultiAiPanel is a compare-first browser workspace with a governed repo-owned MCP server. These starter kits remove setup friction for the strongest current host flows and keep the weaker ecosystem paths honest.

If you are brand new here, get one compare run working first, then come back for the coding-host setup layer. This page is meant to shorten host setup after the compare-first path already makes sense.

The supported install path today is the packaged GitHub Release zip. Browser-store submission materials are being kept ready, but GitHub Releases remains the supported install surface today. Start with the install guide and keep the trust boundary close when you wire a coding host.

If you need a containerized helper instead of running the MCP server directly on the host, read the Docker integration guide. It packages the repo-owned MCP server and operator helper, not a hosted MultiAiPanel service.

What the kits connect to

These kits are not just config snippets in a vacuum. They connect to a real coding-host browser surface, a real workflow panel, and the built-in analyst lane that already ships in the repo.

Current support matrix

Codex and Claude Code remain the repo's strongest documented host bindings. OpenCode and OpenClaw are real MCP-capable ecosystem surfaces, and this repo now ships public-ready packets for them, but they still live below the “verified host lane” bar.

The machine-readable version of this matrix lives in mcp/integration-kits/support-matrix.json and is also exposed by the MCP resource multi-ai-panel://builder/support-matrix.

The public-facing bundle and listing truth now also lives on the public distribution matrix and the MCP resource multi-ai-panel://builder/public-distribution, so you can quickly tell the difference between “copyable now” and “officially listed already”.

When you want a one-host install packet instead of the whole matrix, use the host packets page.

When host setup looks correct but a compare still feels brittle, use multi-ai-panel://sites/capabilities alongside multi-ai-panel://builder/support-matrix. One answers “which file goes where”; the other answers “which site surface is MultiAiPanel really prepared to drive today.”

Always start here

1. Run npm run mcp:operator -- doctor to check the local bridge state.
2. Start the MCP server with npm run mcp:operator -- server.
3. Load the unpacked extension in the same browser profile.
4. Use a client-specific starter kit only after the MCP server path is healthy.
5. Run npm run release:host-kits when you need the current host packets packed into local artifacts.

Smallest useful flow vs full follow-through

If you are wiring MultiAiPanel for the first time, do not force every tool into the very first test. Start with the shortest truthful loop, then layer workflow tools on top after compare is healthy.

Codex and Claude Code

These remain the repo's strongest host bindings because the current MCP surface, docs, and starter kits all line up here.

Replace /absolute/path/to/MultiAiPanel with the real path to your own MultiAiPanel clone before you save any of these snippets.

Codex snippet

[mcp_servers.multi-ai-panel]
command = "npm"
args = ["run", "mcp:server"]
cwd = "/absolute/path/to/MultiAiPanel"

Claude Code snippet

{
  "mcpServers": {
    "multi-ai-panel": {
      "command": "npm",
      "args": ["run", "mcp:server"],
      "cwd": "/absolute/path/to/MultiAiPanel"
    }
  }
}

OpenCode and OpenClaw

These are still compatibility-note paths, not verified repo-owned host lanes. The value of these examples is speed: they give you the right config shape faster, without pretending MultiAiPanel already owns a first-class integration story there.

OpenCode generic MCP client example

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "multi-ai-panel": {
      "type": "local",
      "command": [
        "npm",
        "--prefix",
        "/absolute/path/to/MultiAiPanel",
        "run",
        "mcp:server"
      ],
      "enabled": true
    }
  },
  "permission": {
    "multi-ai-panel_*": "ask"
  }
}

OpenClaw MCP registry example

{
  "mcp": {
    "servers": {
      "multi-ai-panel": {
        "command": "npm",
        "args": [
          "--prefix",
          "/absolute/path/to/MultiAiPanel",
          "run",
          "mcp:server"
        ]
      }
    }
  }
}

OpenCode's official docs support local MCP server configuration under mcp. OpenClaw's official docs support both openclaw mcp serve and an OpenClaw-managed MCP registry under mcp.servers. These examples cover the generic config path, and the same folder also carries public-ready bundle packets plus companion skill templates for all four documented hosts. None of these files claim a verified MultiAiPanel host lane, published plugin package, or deeper workflow proof.

If you want the quickest honest reading of current support, use the starter-kits README for prose and the support-matrix JSON or MCP resource for automation-friendly truth, including per-host asset paths, placement hints, and the first MCP calls to make after setup.

Additional starter assets

First calls after setup

1. multi-ai-panel.bridge_status
2. multi-ai-panel.check_readiness
3. multi-ai-panel.compare
4. multi-ai-panel.analyze_compare
5. multi-ai-panel.run_workflow

Workflow follow-through stays on the same session-scoped lane: multi-ai-panel.get_workflow_run reads the latest snapshot, multi-ai-panel.list_workflow_runs lists recent snapshots, and multi-ai-panel.resume_workflow continues a waiting run once you have the external step result.