Workstation Setup tutorial series — Part 4: Connect the MCP server

MCP — Model Context Protocol — is the standard interface Claude Code uses to call out to external tools. Inside a Conduction project, that means two things in practice: a Playwright browser pool (browser-1 … browser-7) for the testing skills, and the OpenRegister MCP server for direct access to your local Conduction data layer. A workstation isn't really complete until at least the browser pool is wired into your project root via .mcp.json. This part covers that; the OpenRegister MCP server has its own tutorial — we link to it at the bottom.

In one sentence

MCP is a small open protocol that lets Claude Code call out to external services via a uniform interface. An "MCP server" is any program that speaks that protocol; Claude treats it as a tool provider. You wire servers into a project by listing them in .mcp.json at the project root.

A few servers you'll meet at Conduction:

• browser-1 … browser-7 — Playwright browser instances Claude can use for testing skills (/test-app, /test-counsel, the hydra-gate-* family).
• The OpenRegister MCP server — Claude can call OpenRegister directly: list registers and schemas, search and read objects, read the audit trail. Covered in its own tutorial.

This module deliberately stops at the Playwright pool: it's the one every Conduction developer needs and it works without any extra accounts.

Step 1: create .mcp.json at the project root

In a Conduction project, the file already exists — open it, scroll, confirm. In a fresh folder, create it. The minimum configuration that all testing skills assume is the seven-browser pool: six headless browsers for parallel agents, one headed browser for when you want to watch.

/path/to/your-project/.mcp.json:

{
  "mcpServers": {
    "browser-1": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--headless", "--isolated"]
    },
    "browser-2": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--headless", "--isolated"]
    },
    "browser-3": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--headless", "--isolated"]
    },
    "browser-4": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--headless", "--isolated"]
    },
    "browser-5": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--headless", "--isolated"]
    },
    "browser-6": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--isolated"]
    },
    "browser-7": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--browser", "chromium", "--headless", "--isolated"]
    }
  }
}

Notice the asymmetry: browser-6 omits --headless. That's deliberate — it's the visible browser for when you want to watch Claude work. The other six stay invisible.

No need to type this from scratch. The .github repo ships an example .mcp.json you can copy directly.

Step 2: trust the servers via .claude/settings.json

Every Conduction repo ships a .claude/settings.json (project-level — separate from your global one) that pre-approves the MCP servers so background agents don't get blocked by prompts. The two relevant lines:

{
  "enableAllProjectMcpServers": true,
  "permissions": {
    "allow": ["mcp__browser-*"]
  }
}

• enableAllProjectMcpServers: true — auto-approves all servers listed in .mcp.json without a per-reload prompt.
• mcp__browser-* — pre-approves every browser tool call so sub-agents working in parallel don't get silently denied.

In a fresh folder, create these settings yourself. In a Conduction repo, they're already there.

Step 3: reload VS Code

Ctrl+Shift+P → "Developer: Reload Window". VS Code re-reads .mcp.json and starts the browser processes.

Step 4: verify

Open the MCP servers panel in VS Code. Two equivalent ways:

• Type /MCP servers in the Claude Code chat input, or
• Ctrl+Shift+P → search "MCP servers" → open the panel.

All seven browsers should show Connected. If any show an error, open the output panel: Ctrl+Shift+P → "Output: Focus on Output" → select Claude VSCode from the dropdown — the error line spells out what went wrong.

Common cause if a browser fails to connect: the Playwright Chromium binary isn't installed. Run npx playwright install chromium from your WSL terminal (you should already have this from Part 2 Step 9). Reload the window after.

How does Claude know which browser to use?

There's no central dispatcher. The skills themselves assign browsers — by convention:

If a browser errors out, Claude falls back to the next numbered one. You don't have to manage this manually.

Why seven browsers?

The count is sized for /test-app Full mode's worst case, with one slot reserved for human observation:

• One main agent (browser-1) + five parallel sub-agents (browser-2–browser-5 and browser-7) = six headless. That covers /test-app Full mode's heaviest parallel run.
• One headed browser for observation — handy when you want to see what Claude is doing rather than just read the result.

Other workspaces may use fewer (or more) browsers depending on parallelism. The Nextcloud workspace uses these seven.

What about the OpenRegister MCP server?

For Conduction projects, the Playwright pool alone isn't enough. The OpenRegister MCP server — shipped as an endpoint inside the OpenRegister Nextcloud app at http://localhost:8080/index.php/apps/openregister/mcp — gives Claude direct access to the data layer of your Conduction stack: list registers and schemas, search and read objects, walk the audit trail.

It's a separate install with its own configuration, so it lives in a dedicated tutorial:

• Set up the Conduction MCP server — the dedicated tutorial for that step.

When you do that tutorial, you add another entry to the same .mcp.json and reload. The Playwright pool stays.

A note on .mcp.json vs. ~/.claude/settings.json

Two files, different scopes. Keep them straight:

The user-level config never lists MCP servers; the project-level config does. That separation means each project picks its own set of servers without touching your global safety policy.

Test yourself

Five short questions to check that this part landed. Stuck? Click Hint. Curious about the answer? Click Answer.