Workstation Setup leerlijn — Deel 4: De MCP-server aansluiten
Een complete Conduction-workstation heeft minstens één MCP-server aangesloten in de project-root. Deze korte module legt uit wat MCP is, hoe het .mcp.json-bestand werkt, en hoe je de Playwright-browserpool opzet waar de testing-skills van afhangen. Inclusief verwijzingen naar de aparte Conduction MCP-server-tutorial. Vierde van zes korte modules.
MCP — Model Context Protocol — is de standaard-interface waarmee Claude Code naar externe tools praat. Binnen een Conduction-project betekent dat in de praktijk twee dingen: een Playwright-browserpool (browser-1 … browser-7) voor de testing-skills, en de OpenRegister MCP-server voor directe toegang tot je lokale Conduction-datalaag. Een workstation is pas echt af als minstens de browserpool via .mcp.json in je project-root is aangesloten. Dit deel behandelt dat; de OpenRegister MCP-server staat in een eigen tutorial — daar linken we onderaan naar.
In één zin
MCP is een klein open protocol waarmee Claude Code naar buiten kan bellen naar externe services via een uniforme interface. Een "MCP-server" is elk programma dat dat protocol spreekt; Claude behandelt het als een tool-leverancier. Je hangt servers aan een project door ze op te sommen in .mcp.json in de project-root.
Een paar servers die je bij Conduction tegenkomt:
browser-1…browser-7— Playwright-browserinstanties die Claude voor testing-skills kan gebruiken (/test-app,/test-counsel, dehydra-gate-*-familie).- De OpenRegister MCP-server — Claude praat direct met OpenRegister: registers en schema's lijsten, objecten zoeken en lezen, de audit-trail uitlezen. Behandeld in een eigen tutorial.
Deze module stopt bewust bij de Playwright-pool: het is de pool die elke Conduction-developer nodig heeft, en hij werkt zonder extra accounts.
Stap 1: maak .mcp.json in de project-root
In een Conduction-project bestaat het bestand al — open het, scroll, controleer. In een nieuwe map maak je hem zelf aan. De minimumconfiguratie waar alle testing-skills van uitgaan is de zeven-browserpool: zes headless browsers voor parallelle agents, één headed browser voor wanneer je wilt meekijken.
/pad/naar/je-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"]
}
}
}
Let op de asymmetrie: browser-6 laat --headless weg. Dat is bewust — het is de zichtbare browser voor wanneer je Claude wilt zien werken. De andere zes blijven onzichtbaar.
Hoef je niet vanaf nul te typen. De
.github-repo bevat een voorbeeld-.mcp.json die je direct kunt kopiëren.
Stap 2: vertrouw de servers via .claude/settings.json
Elke Conduction-repo heeft een .claude/settings.json (op projectniveau — los van je globale) die de MCP-servers vooraf goedkeurt zodat achtergrondagents niet door prompts geblokkeerd worden. De twee relevante regels:
{
"enableAllProjectMcpServers": true,
"permissions": {
"allow": ["mcp__browser-*"]
}
}
enableAllProjectMcpServers: true— keurt alle servers in.mcp.jsonautomatisch goed, zonder prompt bij elke reload.mcp__browser-*— keurt elke browser-toolaanroep vooraf goed, zodat sub-agents die parallel werken niet stilzwijgend worden geweigerd.
In een lege map zet je deze settings zelf neer. In een Conduction-repo staan ze er al.
Stap 3: VS Code opnieuw laden
Ctrl+Shift+P → "Developer: Reload Window". VS Code leest .mcp.json opnieuw in en start de browser-processen.
Stap 4: verifiëren
Open het MCP-servers-paneel in VS Code. Twee gelijkwaardige manieren:
- Typ
/MCP serversin het Claude Code-chatvenster, of Ctrl+Shift+P→ zoek "MCP servers" → open het paneel.
Alle zeven browsers moeten Connected tonen. Als er één een fout geeft, open dan het output-paneel: Ctrl+Shift+P → "Output: Focus on Output" → kies Claude VSCode in de dropdown — de foutregel vertelt precies wat er misging.
Veelvoorkomende oorzaak als een browser niet verbindt: de Playwright Chromium-binary is niet geïnstalleerd. Draai
npx playwright install chromiumvanuit je WSL-terminal (zou er al moeten staan uit Deel 2 Stap 9). Reload het venster daarna.
Hoe weet Claude welke browser hij moet gebruiken?
Er is geen centrale dispatcher. De skills zelf wijzen browsers toe — bij conventie:
| Browser | Wanneer wordt hij gebruikt |
|---|---|
browser-1 | De standaard; je hoofdsessie gebruikt deze. |
browser-2…browser-5 en browser-7 | Parallelle sub-agents (bijv. /test-app Full mode, /test-counsel). |
browser-6 (headed) | Wanneer je Claude expliciet hebt gevraagd om "laat me het zien" — dat venster popt op zodat je kunt meekijken. |
Als een browser een fout geeft, valt Claude terug op de volgende genummerde. Je hoeft dat niet handmatig te regelen.
Waarom zeven browsers?
Het aantal is afgestemd op de worst case van /test-app Full mode, met één slot gereserveerd voor menselijke observatie:
- Eén main agent (
browser-1) + vijf parallelle sub-agents (browser-2–browser-5enbrowser-7) = zes headless. Dat dekt de zwaarste parallelle run van/test-appFull mode. - Eén headed browser voor observatie — handig wanneer je wilt zien wat Claude doet in plaats van alleen het resultaat lezen.
Andere workspaces gebruiken misschien minder (of meer) browsers afhankelijk van het parallelisme. De Nextcloud-workspace gebruikt deze zeven; voor een eenmalig prototype kun je gerust naar twee terug.
En de OpenRegister MCP-server dan?
Voor Conduction-projecten is de Playwright-pool alleen niet genoeg. De OpenRegister MCP-server — geleverd als endpoint binnen de OpenRegister Nextcloud-app op http://localhost:8080/index.php/apps/openregister/mcp — geeft Claude directe toegang tot de datalaag van je Conduction-stack: registers en schema's lijsten, objecten zoeken en lezen, door de audit-trail lopen.
Het is een aparte installatie met een eigen configuratie en heeft daarom een eigen tutorial:
- Zet de Conduction MCP-server op — de aparte tutorial voor die stap.
Doe je die tutorial, dan voeg je een extra entry toe aan dezelfde .mcp.json en reload je. De Playwright-pool blijft staan.
Een noot over .mcp.json vs. ~/.claude/settings.json
Twee bestanden, verschillende scopes. Houd ze uit elkaar:
| Bestand | Scope | Wat het doet |
|---|---|---|
~/.claude/settings.json | User-niveau, alle projecten | Je safety-policy, write-approval hooks, version-check (Deel 3). |
<project>/.mcp.json | Project-niveau, deze repo | Welke MCP-servers gestart worden voor dit project. Browsers, de Conduction MCP-server, alles wat verder specifiek is. |
<project>/.claude/settings.json | Project-niveau, deze repo | Projectpermissies, MCP-allowlist, vooraf-goedkeuringen. |
De user-configuratie bevat nooit MCP-servers; de project-configuratie wel. Door die scheiding kiest elk project zijn eigen set servers zonder dat je globale safety-policy in de weg zit.
Probleemoplossing
Het MCP-servers-paneel toont 0 verbonden, zonder foutmeldingVS Code heeft .mcp.json niet opgepikt. Reload het venster (Ctrl+Shift+P → Developer: Reload Window). Nog steeds leeg? Controleer dan of het bestand in de project-root staat en geldige JSON is — plak het in jsonlint.com.
Eén specifieke browser geeft een fout 'browserType.launchPersistentContext: Executable doesn't exist'De Playwright Chromium-binary is niet geïnstalleerd. Draai npx playwright install chromium vanuit je WSL-terminal, en reload daarna VS Code.
Een achtergrondagent zegt 'tool call denied' voor mcp__browser-3De .claude/settings.json van het project heeft niet de mcp__browser-* allow-regel, of enableAllProjectMcpServers ontbreekt. Voeg beide toe, reload, probeer opnieuw.
browser-6 start headless ook al heb ik --headless verwijderdControleer of er geen HEADLESS=true in je shell-omgeving staat en dat geen andere --headless-flag is toegevoegd door een extensie-config. Reload en kijk in het output-paneel mee tijdens de start om de doorgegeven args te bevestigen.
Test jezelf
Vijf korte vragen om te checken of je dit deel begrepen hebt. Vastgelopen? Klik Hint. Curieus naar het antwoord? Klik Antwoord.
1. Waarom moet MCP als apart protocol bestaan? Waarom geef je Claude niet gewoon directe API-toegang tot elke tool?
Hint
Denk eens na over hoeveel tools Claude binnen één project kan aanraken (browser, database, GitHub, Slack, je lokale Nextcloud) en hoe dat opschaalt zonder een uniforme interface.
Antwoord
In een Conduction-project laat je Claude misschien een browser besturen (Playwright), uit een lokale Nextcloud lezen, GitHub's API aanroepen, op Slack posten en een database queryen — allemaal in dezelfde sessie. Zonder MCP zou elke integratie een eigen adapter binnen Claude zijn: handgeschreven, vastgeklikt aan Claude's release-schema, en onmogelijk voor derden om toe te voegen zonder te forken.
MCP plaatst die adapters buiten Claude: een kleine server spreekt een standaardprotocol, Claude consumeert het alleen maar. De prijs is één extra hop (Claude → MCP-server → tool), maar de winst is composability — iedereen kan een MCP-server in elke taal schrijven, hem in .mcp.json zetten, en Claude kan hem gebruiken zonder een Claude-release.
Het is hetzelfde idee als het Language Server Protocol voor editors: definieer het wire-formaat één keer, en elke editor + elke taal kan onderling werken zonder N×M aan custom integraties.
2. Waarom heeft de standaard Conduction-pool zeven browsers, en waarom is er één headed?
Hint
Zes headless dekken een specifiek parallelscenario; de zevende heeft een ander doel.
Antwoord
Zes headless browsers dekken het zwaarste parallelle scenario in /test-app Full mode: één main agent plus vijf gelijktijdige sub-agents, elk op een eigen browser (en browser-7 als reserve). De Hydra-pipeline en /test-counsel leunen op dezelfde pool.
De zevende browser is headed (browser-6 — let op: genummerd, niet de laatste) omdat je soms wilt zien wat Claude doet in plaats van alleen het resultaat lezen. Als je Claude vraagt om "laat me het zien" of "kijk mee", schakelt hij over naar dat zichtbare venster. Verder loopt al het echte werk op de zes headless.
3. Zonder enableAllProjectMcpServers: true én de mcp__browser-* allow-regel falen parallelle sub-agents stilzwijgend, zonder foutmelding. Wat doet elke regel, en waarom zijn beide nodig?
Hint
De één bepaalt welke servers Claude bereid is te starten. De ander bepaalt welke tool calls Claude bereid is te doen zonder te vragen. Beide moeten waar zijn voordat een achtergrondagent non-interactief een browser kan gebruiken.
Antwoord
enableAllProjectMcpServers: truekeurt elke server in.mcp.jsonautomatisch goed. Zonder deze regel vraagt Claude elke keer dat.mcp.jsonwordt ingelezen om permissie (bijv. bij elke reload), en een achtergrond-sub-agent kan niet op die prompt reageren — hij blijft hangen of faalt.mcp__browser-*in de allow list keurt elke browser-tool call vooraf goed. Zonder deze regel vraagt Claude vóór elkemcp__browser-3__navigateenz. — opnieuw kan een achtergrond-sub-agent daar niet op reageren.
Dus de ene regel deblokkeert het starten van de server, de andere deblokkeert de uitvoering per call. Een sub-agent die tegen een van deze poorten aanloopt zonder pre-approval faalt stilzwijgend, omdat hij geen UI heeft om op te prompten. Het symptoom is in beide gevallen identiek — "de test draaide niet en er is geen foutmelding" — en daarom moeten beide regels op hun plek staan voordat je parallel testen probeert.
4. Waar staat .mcp.json, en wat is het verschil met ~/.claude/settings.json?
Hint
Twee bestanden, twee scopes. De één is per-user, de ander per-project.
Antwoord
.mcp.json staat in de project-root (naast package.json of composer.json). Het is per-project: welke MCP-servers moet dit project starten — browsers, de Conduction MCP-server, wat dan ook.
~/.claude/settings.json is user-niveau: je safety-policy, write-approval hooks, version-check. Geldt voor elk project dat je opent en bevat zelf nooit MCP-servers.
De splitsing is belangrijk omdat elk project zo zijn eigen MCP-servers kan kiezen zonder je globale safety-configuratie te raken. Het ene aanpassen verandert het andere nooit.
5. Je draait /test-app Full mode en je ziet dat één parallelle sub-agent stilzwijgend faalt — hij produceert gewoon geen test-output. Het MCP-servers-paneel toont alle zeven browsers als Connected. Wat zijn de twee meest waarschijnlijke oorzaken, en waar kijk je?
Hint
Als het paneel "Connected" zegt maar de agent gebruikte de browser niet, zit de breuk tussen agent → tool call, niet Claude → server. Twee dingen op projectniveau bewaken die interactie.
Antwoord
Twee waarschijnlijke oorzaken:
- De
.claude/settings.jsonvan het project mist demcp__browser-*allow-regel. Zonder die regel wordt de tool call van de sub-agent stilzwijgend geweigerd — geen foutmelding, gewoon geen werk gedaan. Open het bestand en check dat depermissions.allowarray"mcp__browser-*"bevat. - De sub-agent koos een browser die al door een andere sub-agent gebruikt wordt. Elke
mcp__browser-Nis exclusief: als twee agentsbrowser-3proberen te pakken, wacht de tweede stilzwijgend en kan een time-out krijgen voordat de eerste hem vrijgeeft. De fix is ervoor zorgen dat je skill een unieke browser per sub-agent toewijst (browser-2,browser-3, etc.) in plaats van dat ze allemaal standaard opbrowser-1uitkomen.
Om te diagnosticeren: open het Output-paneel (Ctrl+Shift+P → "Output: Focus on Output" → kies Claude VSCode). De geweigerde tool-call verschijnt daar, ook als de output van de parent-agent er schoon uitziet.
Volgende stap
De browsers zijn aangesloten. Tijd om een lokale Nextcloud te starten, zodat de apps die je straks bouwt ook ergens kunnen draaien.