n8n MCP Server + Claude Code: TypeScript verandert alles
Ik negeerde de n8n-update bijna.
De Slack DM kwam op woensdag om 07.42 uur binnen van een vriend die een klein AI-bureau runt. Twee regels, geen context: "Ze hebben create-workflow toegevoegd aan de officiële MCP. Probeer het voordat je weer onzin over n8n praat." Ik had het grootste deel van het voorgaande kwartaal op n8n gedoken - niet omdat het product slecht was, maar omdat elke keer dat ik probeerde Claude Code erop aan te sluiten, de heen- en terugreis er als volgt uitzag: Claude genereert een gigantische klodder n8n JSON, ik kopieer het, plak het in de n8n-editor, druk op import, kijk hoe een knooppunt mislukt, plak de fout terug in Claude en brand nog eens vier minuten, biddend dat de tweede passage zou parseren.
Twee van mijn laatste drie n8n-experimenten eindigden met het rippen van de workflow en het herschrijven ervan als een Node.js-script. Dus toen n8n MCP op instanceniveau uitbracht en de create-workflow-mogelijkheid algemeen werd, was mijn eerlijke eerste gedachte: Ik kom er volgende week op terug.
Toen las ik de regel in n8n's MCP server-aankondiging die mij deed denken: de MCP server genereert nu een TypeScript-weergave van de workflow in plaats van onbewerkte JSON. Het model moet code produceren die typecontroles uitvoert en compileert voordat iets uw instance raakt. Geen JSON-soep meer. Geen onzichtbare validatiefouten van Unicode-tekens meer. Geen "knooppuntparameter X verwacht enum, kreeg string" meer.
Ik sloot Slack, opende mijn terminal en wees Claude Code naar mijn zelf-gehoste n8n. Vier uur later had ik drie werkende automatiseringen die ik wekenlang had uitgesteld, één bijna-ramp die ik opliep omdat de TypeScript-laag een fout aan het licht bracht die mijn oude op prompts gebaseerde workflow zou hebben verzonden, en een veel scherpere mening over waar n8n eigenlijk thuishoort in een 2026-stack.
Dit is wat de n8n MCP server is, wat hij feitelijk verandert als je hem aansluit op Claude Code, de drie workflows die ik achter elkaar heb gebouwd, de enige plek waar ik nog steeds tegen een muur bots, en waar ik denk dat directe codering in Claude Code nog steeds beter is dan n8n, hoe goed de MCP ook is krijgt.
Wat "n8n MCP Server" feitelijk betekent in 2026
Er bestaat echte verwarring over welke n8n MCP we het zelfs over hebben, omdat er nu twee bekende projecten zijn met vergelijkbare namen, en het samenvoegen ervan kost je een middag.
De eerste is n8n-mcp door Romuald Czlonkowski — het gemeenschapsproject gepubliceerd op GitHub op czlonkowski/n8n-mcp. Het werd gelanceerd in 2024, wordt geleverd als een npx-pakket en biedt gestructureerde toegang tot meer dan 1.500 n8n-knooppunten met documentatie op eigendomsniveau, zodat een AI-agent workflows correct kan schrijven. Het was de facto de brug tussen Claude Code en n8n gedurende het grootste deel van 2025.
De tweede is de officiële n8n MCP server, rechtstreeks in het n8n-product gebakken. n8n heeft oorspronkelijk MCP-toegang op instanceniveau geleverd als bètafunctie, en volgens de n8n blogpost op de MCP server en de officiële documenten op docs.n8n.io, wordt deze nu via de cloud verzonden, zelf gehost community- en enterprise-edities. De grote update (de reden dat dit artikel bestaat) is dat de officiële server nu de mogelijkheden create-workflow en update-workflow biedt, en niet alleen ontdekken en uitvoeren.
Volgens de n8n community-aankondiging zijn deze mogelijkheden in n8n versie 2.14.0 als bèta terechtgekomen, en 2.18.4 of hoger is de aanbevolen minimumleeftijd voor stabiel workflow-ontwerp. Ik zat op 2.19 toen ik testte.
De officiële server en het community-n8n-mcp-pakket sluiten elkaar niet uit. Je kunt beide uitvoeren. In de praktijk doe ik dat wel: het communitypakket is nog steeds het beste hulpmiddel om "mijn agent encyclopedische knooppuntkennis te geven", en de officiële server is wat feitelijk workflows creëert en bijwerkt in mijn live-instantie. Als ik in de rest van dit bericht "de n8n MCP server" zeg, bedoel ik de officiële, tenzij ik het communitypakket bij naam noem.
Het stukje dat er stilletjes het meest toe doet: de officiële server gebruikt TypeScript als de tussenrepresentatie voor alle schrijfbewerkingen met workflow Claude Code. Het model zendt TypeScript uit. De TypeScript compileert op basis van de knooppunttypedefinities van n8n. Als het compileert, wordt het geconverteerd naar JSON en rechtstreeks naar uw exemplaar gepusht via de API. Als het niet compileert, komt de fout terug naar Claude Code als een echte typefout (knooppuntnaam, parameternaam, verwacht type) en Claude kan hierop herhalen zonder dat u ooit uw terminal hoeft te verlaten.
Die laatste zin is het hele artikel. Al het andere zijn consequenties.
Waarom TypeScript-as-IR stilletjes het slechtste deel van n8n + LLM heeft opgelost
Voordat ik bij de workflows kom, wil ik eerlijk zijn over waarom mijn oude n8n-plus-Claude-pogingen mislukten, want als jouw ervaring overeenkwam met de mijne, had je n8n MCP waarschijnlijk ook helemaal afgeschreven.
Dit is hoe het genereren van onbewerkte n8n JSON met een LLM in 2025 aanvoelde. n8n workflows zijn JSON-documenten met diep geneste knooppuntconfiguraties. Elk knooppunt heeft een type, een typeVersion, een parameters-object dat per knooppunt varieert, en een referentiereferentie die moet overeenkomen met een bestaande referentie-ID binnen uw exemplaar. De JSON is meedogenloos. Een ontbrekend typeVersion-veld creëert stilletjes een knooppunt dat importeert maar niet kan worden uitgevoerd. Een verkeerde enumwaarde in parameters.method (POST versus post) zorgt ervoor dat het knooppunt kapot gaat op een manier die de import niet opvangt - je komt er pas achter als je op Uitvoeren klikt. En het schema is zo groot dat geen enkele LLM, hoe goed ook, de parametervorm van elk knooppunt in het geheugen kan vasthouden.
U zou dus het volgende vragen: "Maak een n8n workflow die 5 RSS-feeds ophaalt, items van de afgelopen 24 uur filtert, ze samenvat met een LLM en de samenvatting per e-mail verzendt." U krijgt 350 regels JSON terug. Je zou het importeren. Drie knooppunten zouden op subtiele wijze worden verbroken. U kopieert de importfout terug naar het model. Het model zou één probleem oplossen, een nieuw probleem introduceren, en de lus zou veertig minuten van je leven in beslag nemen, wat twaalf hadden moeten zijn.
De TypeScript IR doorbreekt die rommel op een structurele manier. Wanneer Claude Code TypeScript uitzendt, schrijft het tegen de werkelijke knooppunttypedefinities. RssFeedReadNode, IfNode, OpenAINode, EmailSendNode — elk is een reëel type met een echte parametervorm. Als Claude method: 'post' probeert in te stellen op een knooppunt waar het type 'POST' | 'GET' verwacht, weigert de TypeScript-compiler. De fout is niet "uw workflow is geïmporteerd maar is tijdens runtime kapot" - de fout is "letterlijke tekenreeks 'post' is niet toewijsbaar aan de unie 'POST' | 'GET'", en Claude ziet die fout voordat een van de workflow ooit in n8n belandt.
Het samengestelde effect is dat de eerste poging van het model aanzienlijk waarschijnlijker zal zijn, omdat de compiler doet wat voorheen door uw ogen moest worden gedaan na een handmatige import. Je bent niet langer de validatielaag.
Ik heb dit getest met een workflow waarvan ik wist dat deze kapot zou zijn gegaan onder het JSON-regime. Daarover meer in de tweede build.
De n8n MCP-server instellen met Claude Code (mijn werkelijke configuratie)
Ik ga de installatie doorlopen zoals ik het feitelijk deed op een zelf-gehoste n8n-instantie, omdat de officiële documenten zowel de cloud als de zelf-gehoste versie bestrijken, maar een paar voetwapens begraven die de moeite waard zijn om vooraf te markeren.
Stap 1: Update n8n naar 2.18.4 of hoger
Als u dit overslaat, zult u zich een uur lang afvragen waarom "create-workflow" nooit in de MCP-mogelijkhedenlijst verschijnt. Ik ging van 2.16 naar 2.19 met een enkele Docker-trekkracht op mijn zelf-gehoste box:
docker compose pull n8nio/n8n
docker compose up -d
Als u n8n Cloud gebruikt, gebeurt dit automatisch. Bevestig uw versie onder Instellingen → Info in de gebruikersinterface van n8n voordat u verder gaat.
Stap 2: Schakel MCP op instanceniveau in
Ga in de gebruikersinterface van n8n naar Instellingen → MCP (de menunaam is verplaatst tussen kleinere versies - op 2.19 bevindt deze zich onder de workflow-uitrusting, niet onder de werkruimteuitrusting). Schakel MCP-toegang op instanceniveau in. Dit genereert de MCP server-URL die u in de configuratie van Claude Code plakt, en een langlevend bearer-token dat is gekoppeld aan de gebruiker waarmee u bent aangemeld.
Een voetwapen dat in de documenten niet wordt benadrukt: MCP op exemplaarniveau is ingeschakeld op de instantie, maar volgens [de n8n MCP-documenten] (https://docs.n8n.io/advanced-ai/mcp/accessing-n8n-mcp-server/) heeft elke individuele workflow ook de MCP-toegang nodig als u wilt dat deze als hulpmiddel kan worden ontdekt. Om create-workflow te laten functioneren, heb je geen bestaande workflow nodig om MCP te ondersteunen - Claude maakt nieuwe - maar als je wilt dat Claude Code ook workflows leest en wijzigt die al bestaan, moet je de per-workflow omdraaien schakel ze allemaal in. Ik heb dit de eerste dertig minuten gemist en kon niet achterhalen waarom mijn prompt "lijst bestaande workflows" een lege array retourneerde.
Stap 3: Sluit het aan op Claude Code
Dit is het gedeelte waarin ik overstapte van de community-n8n-mcp-installatie die ik gebruikte naar de officiële server. Het communitypakket gebruikt de opdracht claude mcp add met stdio-modus, zoals deze (dit is de juiste syntaxis per het n8n-mcp Claude Code installatiedocument):
claude mcp add n8n-mcp \
-e MCP_MODE=stdio \
-e LOG_LEVEL=error \
-e DISABLE_CONSOLE_OUTPUT=true \
-e N8N_API_URL=http://localhost:5678 \
-e N8N_API_KEY=your-api-key-here \
-- npx n8n-mcp
Dat commando werkt nog steeds en is wat ik gebruik voor de documentatietools van het communitypakket. Voor de officiële server heb ik een tweede MCP-vermelding toegevoegd die verwijst naar de instantie-URL en het dragertoken, beide verschenen in de n8n-gebruikersinterface vanaf stap 2. Bij mijn laatste ~/.claude/claude_desktop_config.json (ontdaan van inloggegevens) zijn beide servers geregistreerd. Claude Code somt hun mogelijkheden samen op bij het opstarten, en prompt routing om "een workflow te maken" komt terecht op de officiële server omdat die mogelijkheid niet bestaat op de gemeenschapsserver.
Een opmerking over het bereik van referenties. Het token op exemplaarniveau is breed. Ik heb een speciale n8n-gebruiker gemaakt met de naam claude-mcp met de rol Member en een strak gedefinieerde referentieset, en heb het token van die gebruiker gebruikt. Ik geef Claude Code niet mijn admin-token, omdat Claude Code op dit punt in 2026 niet alleen vragen beantwoordt - het doet API-oproepen naar een systeem met mijn klantgegevens erin. Behandel het token als een implementatiesleutel, niet als een chatwachtwoord.
Stap 4: Gezondheidscontrole
Binnen Claude Code, na opnieuw opstarten:
List the MCP servers currently connected.
Je zou n8n-mcp (community) en je officiële inzending moeten zien (de mijne is geregistreerd als n8n-instance). Dan:
What MCP capabilities do you have for n8n workflow creation?
Het antwoord moet create_workflow, update_workflow en de Discovery/execution-tools vermelden. Als create_workflow ontbreekt, is uw n8n-versie te oud of is MCP op exemplaarniveau niet ingeschakeld. Los dat op voordat u verder gaat.
De eerste prompt die ik op een werkende opstelling uitvoerde, was de domst mogelijke test. Ik wil het markeren omdat het een nuttige stap uit het gezond verstand is.
De eerste build: dagelijkse weer-e-mail (de "Hallo wereld")
Ik gaf Claude Code deze prompt:
Bouw een n8n workflow die elke ochtend om 7 uur 's ochtends wordt uitgevoerd, haalt de weersvoorspelling voor Dhaka op van een gratis weer-API, formatteert deze in een korte leesbare samenvatting en e-mailt deze naar mijn persoonlijke adres. Gebruik de mogelijkheid workflow-create op de n8n-instantie. Laat me de TypeScript zien voordat je erop drukt.
Claude Code reageerde met een TypeScript-bestand gestructureerd in vier knooppunten: een Cron-trigger op 0 7 * * *, een HTTP-verzoekknooppunt dat api.open-meteo.com raakt met latitude=23.8103&longitude=90.4125, een codeknooppunt dat de volgende 24 uur aan voorspellingen per uur ophaalde en deze opmaakte in een Markdown-samenvatting, en een knooppunt voor e-mail verzenden met mijn adres als ontvanger.
Wat mij opviel bij het lezen van TypeScript: elk knooppunt had bovenaan expliciete type-importen. De HttpRequestNode is geïmporteerd uit de knooppunttypen van n8n. De Cron-expressie is getypt als een letterlijke tekenreeksvereniging van geldige cron-patronen. De inloggegevensreferentie voor het e-mailknooppunt was een getypte tekenreeks die verwees naar mijn bestaande gmail-personal-inloggegevens-ID - waarvan Claude op de hoogte was omdat deze de inloggegevenslijst van mijn instantie had opgevraagd voordat deze werd geschreven.
Ik zei tegen Claude dat hij erop moest drukken. De TypeScript gecompileerd. De conversie naar JSON gebeurde aan de serverzijde. De workflow verscheen in mijn n8n gebruikersinterface onder een naam die Claude had gekozen: Daily Weather Forecast — Dhaka. Ik klikte op Activeren en wachtte.
Om 7.00 uur de volgende ochtend belandde de e-mail in mijn inbox. Netjes opgemaakt. Uitsplitsing per uur. Inclusief de tijden voor zonsopgang en zonsondergang, waar ik niet om had gevraagd, maar waarvan Claude had afgeleid dat het nuttig zou zijn. Totale verstreken tijd vanaf prompt tot werkende productieautomatisering: ongeveer drie minuten, waarvan het grootste deel mijn Docker-container opnieuw opstartte na de versiehobbel van eerder.
Pauzeer even. Die zin hierboven – "Totale verstreken tijd vanaf prompt tot werkende productieautomatisering: ongeveer drie minuten" – is het soort bewering dat rondgaat in virale demo's en is meestal een leugen. Ik wil er voorzichtig mee zijn. De drie minuten zijn reëel voor deze specifieke workflow, op een systeem dat al was geconfigureerd, tegen een API waarvoor geen verificatie vereist was, met inloggegevens die al bestonden. De opstelling die ik in de vorige sectie beschreef, de n8n-versiebump, de referentiescoping, de MCP-bedrading - dat alles kwam op de eerste plaats en kostte me bijna negentig minuten, inclusief het lezen van de documenten. Het getal van drie minuten is het getal per workflow zodra uw omgeving is ingebeld, en niet het koudestartnummer.
Als uw benchmark is "hoe snel kan ik van nul naar de eerste automatisering gaan", budget dan twee vaste uren.
Nu de tweede build, waar de TypeScript-laag zijn waarde verdiende.
De tweede build: AI Nieuwsbriefoverzicht (waar TypeScript een echte bug tegenkwam)
Dit is degene die ik al maanden wilde. De prompt:
Bouw een n8n workflow die dagelijks om 6 uur 's ochtends wordt uitgevoerd en items van de afgelopen 24 uur uit deze vijf RSS-feeds haalt - Anthropic, OpenAI, Hugging Face papers, Replicate en TechCrunch AI - filtert alles eruit dat ouder is dan 24 uur, stuurt de kop en samenvatting van elk item naar GPT-5.5 met een prompt om de enige praktische afhaalmaaltijden voor een werkende AI-ingenieur eruit te halen, en deze vervolgens samen te stellen in een enkele Markdown-samenvatting en deze naar mijn leesadres te e-mailen. Gebruik mijn OpenAI-referentie.
Claude Code bleef ongeveer veertig seconden weg en kwam terug met een TypeScript-bestand van misschien 220 regels lang. Vijf RSS-feedknooppunten die worden ingevoerd in een samenvoegknooppunt, vervolgens een codeknooppunt dat het 24-uursfilter uitvoert met behulp van JavaScript-datumberekeningen, vervolgens een Iterator-knooppunt, een OpenAI-chatknooppunt geconfigureerd met GPT-5.5 (geverifieerd volgens [OpenAI's GPT-5.5-modeldocumentatie] (https://developers.openai.com/api/docs/models/gpt-5.5) - het model werd beschikbaar in de API op 24 april 2026 volgens [TechCrunch's lanceringsdekking] (https://techcrunch.com/2026/04/23/openai-chatgpt-gpt-5-5-ai-model-superapp/), dus het is de juiste beslissing voor een workflow die in mei 2026 wordt gebouwd), een Set-knooppunt dat resultaten verzamelt en een E-mailverzendknooppunt dat de lus sluit.
Vervolgens pauzeerde Claude voordat hij pushte en zei iets als: "Het Iterator-knooppunt hier is geconfigureerd om synchroon te werken, wat betekent dat de OpenAI-aanroepen serieel worden uitgevoerd. Met vijf feeds van gemiddeld tien items elk, zijn dat vijftig sequentiële GPT-5.5-aanroepen per run. Bij de huidige latentie is dat ongeveer zes minuten uitvoeringstijd en zou de time-out van workflow kunnen worden geactiveerd. Wil je dat ik dat doe? overschakelen naar een Split In Batches-knooppunt met parallelle uitvoering, batchgrootte 5?"
Ik had hem niet gevraagd daarover na te denken. De community-documentatietool n8n-mcp had Claude voldoende inzicht gegeven in de uitvoeringssemantiek van n8n, zodat het latentieprobleem werd opgemerkt tijdens ontwerptijd, voordat de workflow ooit werd uitgevoerd. Ik zei ja, verander het. Claude heeft de TypeScript opnieuw gegenereerd met parallelle batching, de typecontrole bevestigde dat de nieuwe knooppuntconfiguratie geldig was en de workflow werd naar n8n gepusht.
Dit is het gedeelte dat ik specifiek wil noemen. In de oude JSON-prompt-wereld zou die fout zijn ontstaan. De workflow zou met succes zijn geïmporteerd. Het zou zijn uitgevoerd, een n8n-uitvoeringstime-out van 5 minuten hebben bereikt op de derde of vierde dag met een zware nieuwscyclus, en ik zou om 06:08 uur een foutmeldingsmail hebben gekregen zonder duidelijke indicatie waarom. Ik zou dertig minuten hebben besteed aan het debuggen voordat ik besefte dat de synchrone iteratie het probleem was. De TypeScript-laag plus het documentatiebewuste schrijven voorkwamen niet alleen een typefout; het bracht ook een runtime-probleem aan het licht voordat de workflow zelfs maar werd gepusht.
Ik heb het een week laten draaien. Vijf van de zeven ochtenden belandde de samenvatting netjes in mijn inbox. Twee ochtenden was een van de RSS-feeds onbereikbaar en de workflow registreerde de fout zonder te crashen, wat het gewenste gedrag is. De extractiekwaliteit van de OpenAI was de variabele waar ik het meest sceptisch over was, en eerlijk gezegd was deze misschien 80% van de tijd solide en de andere 20% agressief oppervlakkig - generieke uitspraken als "dit is een belangrijke ontwikkeling voor AI-ingenieurs." Dat is een prompt-engineeringprobleem, geen n8n-probleem, en het is iets dat ik bij mijn volgende iteratie zou aanscherpen.
Als je wilt gaan hoe ver je kunt gaan met de auteurslus van Claude Code, dan heeft dit soort workflow de juiste vorm: meerstappen, meerdere referenties, met minstens één plek waar de semantiek van de uitvoering ertoe doet. Het is ook de vorm waarin mijn must-have MCPs voor Claude post relevant wordt, omdat hetzelfde multi-MCP compositieprincipe van toepassing is: de ene MCP geeft Claude de kennis om correct te schrijven, een andere geeft het het uitvoeringsoppervlak en de waardeverbindingen.
De derde build: een klantgerichte workflow (en waar n8n nog steeds beter is dan directe code)
Dit is de build die mijn mening heeft doen veranderen over waar n8n thuishoort in 2026.
Ik heb een terugkerend gesprek met bureauklanten dat grofweg gaat: "Kun je deze automatisering zo instellen dat mijn niet-technische team het later kan bewerken?" Mijn eerlijke antwoord van het afgelopen jaar was nee: ik zou dezelfde logica bouwen als een Node.js-script of een Cloudflare Worker, omdat het sneller te schrijven was, gemakkelijker te testen en ik de implementatie onder controle had. Maar het "zodat mijn niet-technische team het later kan bewerken" van het verzoek was altijd het onbeantwoorde stuk. Code overleeft het contact met een marketingmanager niet die dinsdag een Slack-melding moet toevoegen.
Dus bouwde ik dezelfde workflow op twee manieren. Eén in TypeScript binnen Claude Code als een zelfstandig knooppuntscript. Eén in n8n via de MCP server. Dezelfde bedrijfslogica: een webhook ontvangt een nieuwe lead van de landingspagina van een klant, de lead wordt verrijkt met een zoekopdracht naar openbare gegevens API, gescoord op basis van een door een prompt gedefinieerde ICP en wordt in een Slack-kanaal geplaatst voor verkoopopvolging of wordt stilletjes ingelogd op een Google-blad als deze niet aan de lat voldoet.
Het Node-script kostte me ongeveer zeventien minuten in Claude Code en was strakker, schoner en performanter dan de n8n-versie. Ik zou de Node-versie elke dag verzenden als het resultaat alleen maar de automatisering was.
Het kostte me ongeveer vierentwintig minuten om de MCP server-versie te schrijven, en nog eens vijftien minuten om te verfijnen nadat ik door de visuele weergave had geklikt. Per uitvoering was het iets langzamer. De latentie van de webhook was hoger. De foutafhandeling was uitgebreider dan ik met de hand zou hebben geschreven. Volgens elke op de ontwikkelaar gerichte maatstaf won het Node-script.
Maar de n8n-versie had iets waar het Node-script niet aan kon tippen: een visueel canvas dat de marketinglead van de klant kon openen, zien en erover kon redeneren. Toen ze mij drie dagen later vroeg "kunnen we ook een kopie naar onze HubSpot sturen als de lead boven de 80 scoort", kon ze naar de IF-node in het n8n-canvas wijzen en zeggen "deze branch, maar ook daar." Ik heb het HubSpot-knooppunt toegevoegd door Claude Code te vertellen "voeg een HubSpot Create Contact-knooppunt toe aan de high-score tak van de leadscorende workflow, druk erop." Het gebeurde binnen een minuut. Ze zag het nieuwe knooppunt voor haar op het doek verschijnen.
Dat is de n8n-use case in 2026, aangescherpt door de MCP server. Niet "n8n is beter voor automatisering." Niet "n8n vervangt code." n8n is het juiste antwoord wanneer de workflow de ingenieur moet overleven die hem heeft gebouwd, en de MCP server maakt die build zo goedkoop dat u n8n zou kiezen voor clientwerk, zelfs als een script technisch superieur zou zijn.
Als uw werk overdracht aan een niet-ingenieur met zich meebrengt – bureauklanten, interne operationele teams, marketing – verandert de n8n MCP server de economie. Als uw werk puur technische automatisering is die in uw repo leeft, wilt u vrijwel zeker nog steeds het script rechtstreeks schrijven. De eerlijke mening is dat het verschillende instrumenten zijn voor verschillende levensduur van dezelfde logica.
Wat nog steeds slecht is (omdat een deel ervan nog steeds werkt)
Ik wil specifiek zijn over de ruwe kantjes, want de demo's online slaan daar voorbij en daardoor raak je gefrustreerd.
Inloggegevensbeheer is nog steeds het grootste knelpunt. Wanneer Claude Code een workflow schrijft waarvoor een OpenAI-referentie, een Slack-referentie en een Google Spreadsheets-referentie nodig is, kan deze alleen bij naam ernaar verwijzen als deze al in uw n8n-referentiekluis aanwezig zijn. Claude kan geen inloggegevens voor u aanmaken. Dat moet in de gebruikersinterface gebeuren, handmatig, met de daadwerkelijke OAuth-stroom of met het plakken van de API-sleutel. Voor multi-tool workflows stuiter je tijdens de eerste installatie drie keer terug naar de n8n gebruikersinterface. Nadat de inloggegevens bestaan, is dit geen probleem. De eerste keer dat u bouwt, is ruwer dan de documenten impliceren.
Langlopende workflows bereikt nog steeds dezelfde plafonds. Als uw workflow twaalf uur moet wachten voordat een externe taak is voltooid, is het wachtknooppunt van n8n geen goed antwoord. De MCP server verandert niets aan het onderliggende uitvoeringsmodel van n8n; het verandert alleen de manier waarop de workflow wordt geschreven. Voor agentisch werk met een lange horizon verslaan de eigen planningsprimitieven van Claude Code of een echte taakwachtrij nog steeds n8n.
De foutfeedbacklus in Claude Code is redelijk, maar niet geweldig. Wanneer een geïmplementeerde workflow faalt, is de fout van n8n gestructureerd maar uitgebreid, en het terugvoeren ervan naar Claude Code voor een iteratieve oplossing werkt meestal, maar levert af en toe "oplossingen" op die nieuwe problemen introduceren. Ik ben één geval tegengekomen waarin Claude een n8n-referentie-toestemmingsfout verkeerd interpreteerde als een syntaxisfout en een nutteloze herschrijving voorstelde. U moet nog steeds de daadwerkelijke fout lezen en niet alleen plakken.
Het community n8n-mcp-pakket en de officiële server overlappen elkaar op vreemde manieren. Beide kunnen knooppunten weergeven. Beide kunnen mogelijkheden beschrijven. Soms stuurt Claude een zoekopdracht naar de verkeerde en krijgt een minder volledig antwoord. Ik heb geen andere manier gevonden om routering te forceren dan door de server expliciet een naam te geven in de prompt - "Gebruik de officiële n8n MCP, maak..." — wat lastig is.
Er is hier sprake van een echt beveiligingsoppervlak. Ik heb dit eerder gezegd en ik herhaal het omdat het ertoe doet: een MCP-token op instanceniveau plus een autonome agent staat gelijk aan een serviceaccount dat dingen in uw bedrijfssystemen kan bouwen en uitvoeren. Behandel het zo. Gebruik een toegewijde gebruiker. Bereikreferenties. Controleer de workflows die de agent maakt voordat u deze activeert. Ik heb nu een audit-before-activate-regel in mijn prompt ingebakken: "roep nooit activatie aan op een workflow die je maakt - laat hem inactief totdat ik het bevestig." Dat is een redelijke standaard.
Waar de n8n MCP-server nu in mijn stapel staat
Een maand nadat ik het dagelijks gebruik, mijn eerlijke beslisboom:
Als de automatisering zichtbaar moet zijn voor een niet-ingenieur die deze later zal bewerken: n8n via de MCP server. De laag TypeScript maakt het schrijven op basis van Claude Code zo betrouwbaar dat ik niet terugdeins voor de bouwkosten.
Als de automatisering intern is, zich in een repo bevindt en deel uitmaakt van een implementatiepijplijn: directe code. Ofwel een script dat Claude Code in mijn project schrijft, of, in toenemende mate, een Cloudflare Worker als het een webhook-oppervlak nodig heeft.
Als de automatisering agentisch gedrag met een lange horizon, recursieve taakdecompositie of het soort werk omvat waar mijn [Claude Code geavanceerde workflow-handleiding] (https://www.mejba.me/claude-code-advanced-workflow-guide) over spreekt - Claude Code op zichzelf, met tools, niet n8n.
Als de automatisering het product zelf is en wordt geleverd aan een klant wiens team operationeel eigenaarschap nodig heeft: elke keer n8n, omdat de MCP server uiteindelijk de bouwkosten heeft doen dalen, en het visuele canvas het daadwerkelijke resultaat is, en geen bijeffect.
Wat de MCP server voor mij heeft veranderd, is dat ik n8n niet langer behandel als een hulpmiddel voor "automatiseringen die ik in code zou hebben geschreven als ik meer geduld had gehad." Ik behandel het als een hulpmiddel voor 'automatiseringen waarvan de levensduur groter is dan de ingenieur die ze heeft gebouwd'. Dat is een ander soort probleem, en het is een probleem waar de meeste ingenieurs – inclusief ikzelf, zes maanden geleden – te weinig aandacht aan gaven.
Veelgestelde vragen
Werkt de n8n MCP server met Claude Code?
Ja – de officiële n8n MCP server maakt verbinding met Claude Code via de standaard MCP-configuratie, en de mogelijkheid om workflow te maken, geleverd in n8n 2.14.0 met stabiele ondersteuning vanaf 2.18.4. U voegt de server-URL en het dragertoken van de instantie toe aan uw Claude Code MCP-configuratie en vraagt vervolgens in natuurlijke taal. Voor het volledige installatieoverzicht, zie "De n8n MCP-server instellen met Claude Code" hierboven.
Wat is het verschil tussen n8n-mcp en de officiële n8n MCP server?
n8n-mcp (Czlonkowski's gemeenschapsproject over GitHub) geeft Claude encyclopedische kennis van de meer dan 1.500 knooppunten van n8n voor nauwkeurig schrijven. De officiële n8n MCP server, ingebakken in het product, is wat feitelijk workflows creëert en bijwerkt in uw live-instantie. De meeste serieuze gebruikers gebruiken beide: het communitypakket voor knooppuntkennis, het officiële pakket voor uitvoering.
Werkt de n8n MCP server op n8n Cloud?
Ja. Volgens de n8n-blog en -documentatie is MCP-toegang op exemplaarniveau plus de mogelijkheid om workflow te maken beschikbaar in n8n Cloud, de zelf-gehoste Community Edition en Enterprise. De installatiestappen zijn vrijwel identiek: Cloud-gebruikers slaan de Docker-versie-bump-stap over omdat n8n Cloud automatisch wordt bijgewerkt.
Waarom gebruikt de n8n MCP server TypeScript in plaats van JSON?
TypeScript dwingt de AI-agent om code te produceren die typecontroles uitvoert op basis van de knooppunttypedefinities van n8n voordat deze ooit uw exemplaar raakt. Verkeerde parametervormen, ontbrekende velden en ongeldige enumwaarden mislukken tijdens het compileren met gestructureerde fouten waar de agent op kan herhalen, in plaats van te importeren als stilletjes afgebroken JSON. Het vermindert dramatisch de ‘scheeps kapot’-foutmodus die JSON-promptende workflows in 2025 teisterde.
Moet ik n8n gebruiken met Claude Code of gewoon rechtstreeks code schrijven?
Gebruik n8n wanneer de workflow een visueel canvas nodig heeft dat een niet-ingenieur later kan lezen en aanpassen – klanten van bureaus, operationele teams, marketing. Gebruik directe code wanneer de automatisering intern is, zich in een repo bevindt of agentisch gedrag met een lange horizon met zich meebrengt. De MCP server verandert de economie zodanig dat "klantgerichte automatisering" nu op betrouwbare wijze een n8n-beslissing is.
Laten we samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (ondernemingsoplossingen): ramlit.com
- ColorPark (ontwerp en branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
