Claude Code MCP Integrations: Hoe tools verbinden met AI Coding Agents

1. Inleiding 

Een coding agent zonder toegang tot externe tools kan maar een beperkt aantal dingen doen. Hij kan code uitleggen, wijzigingen voorstellen of een patch schrijven. Maar als je wilt dat hij een repository controleert, een API aanroept of een logbestand leest, moet hij verder gaan dan zijn context window. Dit is waar de meeste setups beginnen te falen.

Ik heb teams deze verbindingen vanaf nul zien opbouwen. Er is bijvoorbeeld een Python-script op de ene plek en een custom wrapper op een andere. De ene integratie gebruikt JSON over HTTP, een andere voert commando's uit via een CLI, en weer een andere hangt af van een oude adapter van een hackathon. Deze setup werkt met een paar tools, maar naarmate je er meer toevoegt, wordt het een rommeltje. Permissies worden inconsistent en debugging wordt moeilijker.

Claude Code verandert van een eenvoudige assistent in een verbonden agent. Hij wordt veel nuttiger wanneer hij toegang heeft tot bestanden, development tools en externe systemen. Maar als er geen standaardmanier is om alles te verbinden, eindig je met kwetsbare integraties die onverwachts kunnen breken.

Dit is wat MCP aanpakt.

Het Model Context Protocol biedt een standaardmanier om tools beschikbaar te maken voor modellen. In plaats van elke tool aan elke agent te koppelen, gebruik je een gedeeld discovery protocol. Dit lost niet elk probleem op, maar het verschuift de vraag van "hoe verbind ik dit" naar "hoe beheer ik wat er verbonden is."

2. Wat zijn MCP Integrations in Claude Code?

MCP is een protocol, geen product. Dit is belangrijk omdat het bepaalt hoe Claude Code achter de schermen werkt.

Het Model Context Protocol specificeert hoe tools zichzelf beschrijven aan een model en hoe het model ze aanroept. Het standaardiseert de uitwisseling: discovery, schema, request en response. Het implementeert de tool zelf niet. Het regelt geen toegangsniveaus. Het biedt alleen het contract.

Wanneer we spreken over MCP integrations in Claude Code, doelen we op tools die Claude via het protocol kan ontdekken en gebruiken. Het model is niet vastgekoppeld aan elk endpoint. In plaats daarvan ziet het een gestructureerde interface, begrijpt het de parameters en gebruikt het de tool als onderdeel van zijn workflow.

Stel bijvoorbeeld dat je wilt dat Claude een GitHub issue aanmaakt wanneer hij een bug vindt tijdens een code review. Zonder MCP zou je custom code moeten schrijven om de output van Claude te verwerken, in te loggen op GitHub en de API-call uit te voeren. Met MCP registreer je gewoon een GitHub-integratie die de tool create_issue biedt met parameters zoals repository, title, body en labels. Claude kan die tool dan rechtstreeks vinden en gebruiken.

MCP integrations doen meer dan alleen Claude met tools verbinden; ze bepalen vanaf het begin hoe Claude die tools herkent en ermee communiceert.

3. Hoe MCP werkt in Claude Code

Tijdens het uitvoeren kent Claude alleen de tools die via MCP beschikbaar zijn gemaakt. De manier waarop hij ermee communiceert, volgt een vaste volgorde.

Deze stap vindt plaats voordat Claude ergens interactie mee heeft. Een tool wordt geregistreerd bij een MCP server, inclusief zijn naam, beschrijving en input schema. Het schema helpt het model de tool te begrijpen. Als de registratie onduidelijk is, kan Claude de verkeerde tool kiezen.

Een bestandlezer kan een path-parameter tonen. Een GitHub-integratie kan repository, branch en issue_id tonen. Een logging tool kan service_name, time_range en severity_filter accepteren.

Tool discovery

Wanneer Claude verbinding maakt, stuurt hij een tools/list request:

De server stuurt de beschikbare tools en hun schema's terug. Deze lijst wordt de verzameling mogelijke acties van Claude. Claude gokt niet, hij leest een duidelijk gedefinieerde interface.

Invocatie

Wanneer Claude een tool nodig heeft, stuurt hij een call_tool request met argumenten. Stel dat Claude een beveiligingsprobleem vindt tijdens een review. Hij kan de GitHub-integratie als volgt aanroepen:

Als de argumenten onjuist zijn of de tooldefinities niet duidelijk zijn, kan het in deze fase misgaan.

Response handling

De tool draait onafhankelijk van het model en geeft een resultaat terug. Claude leest dit resultaat en gaat verder. Soms is het resultaat duidelijk, maar andere keren is het rommelig of onvolledig. Hoe dan ook, het beïnvloedt wat er daarna gebeurt.

Deze cyclus van registratie, discovery, invocatie en response is hoe MCP binnen Claude Code werkt.

4. Typen MCP Integrations

MCP integrations gebruiken allemaal hetzelfde protocol, maar ze werken niet allemaal op dezelfde manier. Verschillen verschijnen in hoe ze met state omgaan, hoe voorspelbaar hun antwoorden zijn en hoeveel context Claude moet beheren.

Bestandssysteemintegraties

Dit is het eenvoudigste type. Claude leest en schrijft bestanden in snelle cycli. Dit is snel en meestal voorspelbaar, maar ook kwetsbaar. Als een bestandspad ontbreekt of een write onvolledig is, kan de workflow breken zonder duidelijke foutmeldingen. Ik heb agents vast zien lopen omdat het lezen van een bestand een lege waarde teruggaf in plaats van een foutmelding. Repository-integraties

Dit omvat GitHub, GitLab en vergelijkbare tools. Claude kan pull requests lezen, commits controleren, issues aanmaken en wijzigingen pushen. Dit is krachtig, maar kan riskant zijn. Als permissies niet correct zijn ingesteld, kan een agent code mergen die hij niet zou mogen mergen. Je moet voorzichtig zijn met permissies: het lezen van pull requests is niet hetzelfde als schrijven naar branches.

API-integraties

Dit zijn externe diensten die via HTTP worden benaderd. Ze zijn gestructureerder, maar minder vergevingsgezind. Je hebt te maken met network calls, authenticatie, rate limits en timeouts. Schema-mismatches kunnen midden in een run optreden. Ik heb situaties gedebugged waarin Claude een Jira-call bleef proberen die mislukte vanwege een verborgen veldvalidatiefout.

Log- en observabiliteitsintegraties

Claude kan logs, traces of metrics opvragen. Dit zijn voornamelijk leesoperaties met grote hoeveelheden data. De grootste uitdaging is het stellen van de juiste vraag. Een tool die 10.000 logregels teruggeeft is niet nuttig, maar een tool waarmee je kunt filteren op tijdsbereik, ernst en service is veel beter.

Database-integraties

Deze zijn stateful en brengen meer risico met zich mee. Claude bouwt queries op basis van schema's die hij mogelijk niet volledig begrijpt. Hier is nauwkeurigheid belangrijker dan snelheid. De meeste teams stellen deze in als read-only.

Ze gebruiken allemaal hetzelfde protocol, maar hun gedrag in de praktijk kan sterk variëren.

5. MCP Architectuur in Claude Code

Het systeem werkt goed omdat elke laag gescheiden blijft. Als je ze combineert, wordt het snel moeilijker te begrijpen en te beheren.

De agent-laag is Claude zelf. Hij bepaalt wat je wilt, beslist welke informatie hij nodig heeft en of er een tool moet worden gebruikt. Claude voert niets rechtstreeks uit; hij plant, kiest en delegeert taken.

De MCP-laag fungeert als de protocolgrens en standaardiseert hoe tools worden beschreven en aangeroepen. Voor Claude verschijnt elke tool, of het nu een bestandlezer, een database of een externe API is, als een gestructureerde interface, omdat MCP ze er allemaal hetzelfde uit laat zien.

De tool-laag is waar dingen daadwerkelijk gebeuren. Commando's worden uitgevoerd, bestanden worden gewijzigd en API-calls worden gemaakt. Dit is waar de werkelijke effecten plaatsvinden.

Claude voert het denkwerk uit zonder rechtstreekse interactie met het systeem. Tools regelen de uitvoering zonder beslissingen te nemen. MCP zet de intentie van Claude om in concrete acties.

Deze opzet verklaart enkele ontwerpkeuzes. Waarom roept Claude de GitHub API niet rechtstreeks aan? Hij hoeft niet te weten dat het GitHub is. In plaats daarvan ziet hij gewoon een tool genaamd create_issue met een schema. Authenticatie, rate limits en error handling vinden allemaal plaats in de tool-laag, achter het protocol.

6. Beperkingen van Claude Code MCP Integrations

MCP maakt connectiviteit schoner. Het maakt het op zichzelf niet enterprise-ready voor productie.

Geen gecentraliseerd beheer

MCP maakt tools beschikbaar, maar het controleert niet wie wat kan zien binnen verschillende teams of omgevingen. Naarmate je meer integraties toevoegt, wordt dit een uitdaging. De ene agent ziet mogelijk te veel tools, terwijl een andere er te weinig ziet. Er is geen centrale plek om consistentie te bewaren.

Als je bijvoorbeeld drie Claude-implementaties hebt — één voor code review, één voor incident response en één voor documentatie — heeft elke implementatie verschillende tool-toegang nodig. De code review agent zou geen productiedatabase-tools moeten zien, en incident response zou niet naar de hoofdrepository moeten schrijven. Met native MCP moet je elke implementatie afzonderlijk configureren en hopen dat er niets uit sync raakt.

Beveiligingslacunes

Tool-toegang is gebaseerd op de gebruikte credentials. Veel MCP-setups gebruiken permissies op serviceniveau die te breed zijn. Als je ze aanscherpt, kunnen workflows breken. Als je ze open laat, voeg je risico toe. Het protocol lost dit probleem niet op.

Geen observabiliteit

Claude roept tools aan en gaat verder, waardoor wat er tussendoor is gebeurd onzichtbaar blijft. Welke tool is geselecteerd, waarom, met welke argumenten en wat de response was, is onbekend. Zonder traces wordt debugging gokwerk. Ik heb uren geprobeerd te achterhalen waarom een agent een bepaalde toolkeuze maakte, om er vervolgens achter te komen dat er helemaal geen verslag van de beslissing was.

Schalingsproblemen

Een klein aantal integraties is beheersbaar, maar het hebben van tientallen wordt ingewikkeld. Namen veranderen, schema's verschillen en teams definiëren tools op hun eigen manier. Claude moet werken met deze inconsistente opzet, wat de betrouwbaarheid schaadt. Als bijvoorbeeld zowel github_create_issue als gh_new_issue zijn geregistreerd, moet Claude gokken welke hij moet gebruiken.

Gerefragmenteerde tool-blootstelling

Er is geen duidelijke grens voor wat een agent zou moeten zien. Tool-lijsten worden in de loop van de tijd langer. Sommige tools raken verouderd, terwijl andere te krachtig zijn. Een rommelige lijst verslechtert de prestaties en controle.

7. Waarom teams verder kijken dan native MCP Integrations

MCP beheert verbindingen, maar het beheert de controle niet.

Naarmate teams overstappen van een paar integraties naar volledige productie, veranderen hun behoeften. Tools moeten worden beheerd, niet alleen gevonden. Welke agent kan welke tool gebruiken? Onder welke voorwaarden? Met welke limieten? Native MCP geeft geen duidelijke antwoorden op deze vragen.

Dit is waar gateways nuttig worden. Ze zijn niet zomaar extra overhead, ze helpen bij het beheren van de toenemende complexiteit.

Een gateway bevindt zich tussen Claude en de MCP servers. Het beperkt de zichtbaarheid van tools op basis van agent-identiteit. Het dwingt auth af voordat requests downstream tools bereiken. Het past rate limits toe, logt invocaties en wijst beleidsschendingen af.

Auditing werkt op dezelfde manier. Wanneer agents interactie hebben met productiesystemen — zoals het aanmaken van issues, het query'en van databases of het lezen van logs — moeten teams weten wat er is gedaan, door wie en waarom. Zonder dit zijn debugging en compliance reactief: je komt pas achter problemen nadat ze zijn opgetreden.

Een eenvoudige integratie wordt iets meer: een controlelaag tussen agents en tools die vormgeeft hoe toegang werkt in echte situaties.

8. Best Practices voor MCP Integrations

MCP integrations werken het beste wanneer je ze behandelt als interfaces, niet als snelkoppelingen.

Inperken van tool-toegang.

Toegang moet passen bij de taak. Als een integratie alleen repository-metadata hoeft te lezen, zou deze geen credentials moeten hebben waarmee branches kunnen worden verwijderd. Dit klinkt voor de hand liggend, maar het wordt vaak genegeerd omdat bredere permissies sneller op te zetten zijn. Het is in het begin sneller, maar je kunt weken bezig zijn met het herstellen van dingen nadat een agent iets heeft verwijderd dat hij niet had mogen verwijderen.

Beperk tool-zichtbaarheid per agent

Het model mag alleen zien wat het nodig heeft. Als een agent alleen bestanden leest en issues opzoekt, heeft hij geen toegang nodig tot deployment-bediening of schrijfrechten voor de database. Minder opties betekenen minder fouten.

Ontwerp duidelijke tooldefinities.

Expliciete namen. Afgebakende verantwoordelijkheden. Voorspelbare schema's. Als één tool vijf dingen doet, leidt Claude te veel af. Goede integraties zijn saai. Elke tool doet één ding op een schone manier.

In plaats van een GitHub-operationstool met veel parameters te hebben, splits je deze bijvoorbeeld op in GitHub_read_pr, GitHub_create_issue en GitHub_add_comment. Dit maakt het doel van elke tool duidelijk en beperkt.

Voorkom wildgroei

Het hebben van te veel vergelijkbare tools maakt het moeilijker om de juiste te kiezen en vertraagt debugging. Het is beter om een kleinere, welgeorganiseerde set tools te hebben dan een grote, rommelige verzameling. Controleer toolregistraties regelmatig, verwijder ongebruikte tools en voeg overlappende tools samen.

9. MCP Integrations vs APIs vs SDKs

Deze lossen gerelateerde problemen op op verschillende lagen.

API's zijn de basisinterface in de meeste systemen, en SDK's maken die API's eenvoudiger te gebruiken. MCP bevindt zich bovenop beide en zet tool-toegang om in een consistent formaat dat agents kunnen gebruiken.

MCP vervangt geen API's of SDK's. Je GitHub-integratie gebruikt nog steeds de GitHub API. MCP standaardiseert alleen hoe Claude die integratie vindt en gebruikt.

10. Conclusie

MCP brengt orde in wat voorheen een rommelig proces was. Het standaardiseert hoe modellen tools tonen, ontdekken en gebruiken. Dit maakt het eenvoudiger om verbonden agents te bouwen.

Maar het is nog steeds pas een startpunt. Het geeft geen antwoord op vragen over controle, zichtbaarheid of beleid. Het bepaalt niet welke agent toegang krijgt tot welke tool of hoe interacties worden geauditeerd. Dit is waar de architectuur van je systeem moet evolueren. Je stapt over van eenvoudige integraties naar het toevoegen van een beheerde laag die er voor staat. MCP maakt verbindingen mogelijk, maar wat je eromheen bouwt, bepaalt of die verbindingen beheersbaar blijven.

Veelgestelde vragen

Wat gebeurt er als een MCP tool call mislukt?

Claude ontvangt de error response en beslist hoe hij verdergaat. Hij kan het opnieuw proberen, een andere tool proberen of de foutmelding tonen. Het probleem is dat error handling varieert tussen integraties. Sommige geven gestructureerde codes terug. Andere geven vage berichten terug. Zonder consistente error-schema's wordt herstel onvoorspelbaar.

Kan ik beperken welke tools een Claude-implementatie ziet?

Niet via MCP zelf. Het protocol regelt discovery en invocatie. Toegangsbeheer vindt extern plaats. Je configureert elke MCP server afzonderlijk of voegt een gateway toe die zichtbaarheid filtert op basis van agent-identiteit.

Hoe gaan MCP integrations om met auth?

In de tool-laag, niet de protocol-laag. Elke MCP server beheert credentials voor de services die hij omvat. Claude ziet die credentials niet. Hij roept gewoon tools aan. Je beveiligt elke integratie afzonderlijk.

Wat is de prestatie-overhead van MCP?

Minimaal in de meeste gevallen. MCP voegt protocol-overhead toe voor discovery en invocatie, maar de daadwerkelijke uitvoering verloopt nog steeds via wat de tool gebruikt — meestal directe API-calls of lokale commando's. De overhead zit in de standaardisatie, niet in het uitvoeringspad.

Hoe debug ik een verkeerde toolselectie?

Moeilijk zonder observabiliteit. Log elke tools/list response en elke call_tool request, en reconstrueer vervolgens handmatig de beslissingen. Een gateway-laag automatiseert deze logging en vereenvoudigt debugging.

‍