Wat is MCP, en waarom spreekt elke AI-tool het ineens?
Het grootste deel van het afgelopen decennium betekende het koppelen van een AI-model aan de tools van je bedrijf een maatwerkintegratie voor elk paar. Model Context Protocol, de open standaard die Anthropic in november 2024 introduceerde, verving dat door één stekker die overal past — en OpenAI, Google en Microsoft hebben hem sindsdien allemaal overgenomen. Zo werkt het echt, en dit is een echte checklist voordat je er een koppelt aan de data van je team.
Open de desktopapp van Claude en vraag hem de openstaande pull requests van je team te checken, en hij kan dat gewoon doen. Niet omdat Anthropic een GitHub-integratie in Claude heeft gebouwd. Omdat ergens — je IT-team, een leverancier, een ontwikkelaar op GitHub — iemand een klein programma heeft geschreven dat een protocol spreekt dat MCP heet, en Claude al weet hoe het met alles praat dat dat protocol spreekt. Hetzelfde geldt inmiddels voor ChatGPT, Google's Gemini en Microsoft Copilot. Die convergentie, meer dan welke losse functierelease ook, is waarom MCP het ding is geworden waar bijna elke AI-leverancier het afgelopen jaar ondersteuning voor bouwde.
Wat MCP werkelijk is
MCP staat voor Model Context Protocol. Anthropic ontwierp het en maakte de specificatie samen met de eerste SDK's open source op 25 november 2024. Het eigen lanceringmateriaal beschreef het idee met een analogie die bleef hangen: zie MCP als een USB-C-poort voor AI-toepassingen — één fysieke connectorstandaard in plaats van een andere kabel voor elk accessoire. Bij de lancering noemde Anthropic vroege gebruikers die al MCP-ondersteuning in hun eigen producten bouwden, onder wie de bedrijfssoftwarebedrijven Block en Apollo, plus de makers van ontwikkelaarstools Zed, Replit, Codeium en Sourcegraph. De desktopapp van Claude verscheen diezelfde dag met de mogelijkheid om MCP-servers lokaal op iemands eigen machine te draaien.
Het probleem dat het oplost: N tools maal M databronnen
Het probleem dat MCP oplost heeft een naam die engineers terloops gebruiken: het N-bij-M-integratieprobleem. Stel dat een bedrijf vijf AI-tools gebruikt die op bedrijfsdata moeten handelen — Claude, ChatGPT, GitHub Copilot, Cursor en een interne supportbot — en dat die data op acht plekken staat: Slack, GitHub, een Postgres-database, Salesforce, Notion, Google Drive, Jira en een interne API. Zonder een gedeeld protocol kost het om elke tool op een bruikbare manier aan elke bron te koppelen tot veertig aparte integraties — vijf maal acht — elk met een eigen authenticatieschema, eigen foutafhandeling en een eigen onderhoudslast telkens als een van die API's van vorm verandert. Voeg een zesde AI-tool toe en het aantal springt naar achtenveertig. In de praktijk bouwde niemand alle veertig. Elke AI-leverancier bouwde het handjevol dat de engineeringtijd waard leek, en de rest bleef handmatig: kopiëren, plakken, opnieuw uitleggen, herhalen.
MCP maakt van de vermenigvuldiging een optelling. Een bedrijf dat wil dat Claude uit de Postgres-database leest, bouwt geen Claude-specifieke Postgres-connector. Het bouwt — of hergebruikt er een die iemand anders al heeft gepubliceerd — één MCP-server die Postgres ontsluit, en die server werkt met Claude, ChatGPT, Gemini of elke andere MCP-compatibele agent, zonder verdere code. Anthropics eigen lijst noemde bij de lancering kant-en-klare servers voor Google Drive, Slack, GitHub, Git, Postgres en een browserautomatiseringstool die Puppeteer heet. Het punt was nooit dat Anthropic ze allemaal zou bouwen. Het punt is dat iedereen dat kon, en de catalogus van beschikbare servers is inmiddels ver voorbij wat één bedrijf aan personeel zou kunnen dragen.
Hoe het protocol werkelijk werkt
Haal de verpakking weg en MCP is een tamelijk gewoon client-serverprotocol, bewust onspectaculair ontworpen. Het definieert drie rollen. Een Host is de toepassing die iemand daadwerkelijk opent — Claude Desktop, een IDE zoals Cursor, de ChatGPT-app. De Host bevat een MCP Client, die een directe, stateful verbinding opent met een MCP Server — een klein programma dat één specifiek systeem ontsluit: een database, een tickettool, een bestandssysteem, een interne API. Client en server wisselen berichten uit in het formaat JSON-RPC 2.0, een lichtgewicht remote-procedure-call-formaat dat al gangbaar is in bestaande infrastructuur, over een van twee transporten: stdio, wanneer de server een programma is dat lokaal op dezelfde machine draait, of Streamable HTTP, wanneer het een gehoste dienst is die ergens anders draait.
Wat een server kan ontsluiten komt neer op drie primitieven. Tools zijn functies die het model kan aanroepen om een actie te doen — create_task, run_query, send_message — en het model beslist op basis van het gesprek wanneer het er een aanroept. Resources zijn alleen-lezen context die de Host kan binnenhalen en aan het model kan geven zonder dat het ernaar hoeft te vragen — de inhoud van een bestand, een databaseschema, een supportticket. Prompts zijn herbruikbare, door de gebruiker geactiveerde sjablonen — een kant-en-klaar "vat deze thread samen" of "stel een statusupdate op" dat iemand expliciet aanroept, in plaats van iets dat het model zelf besluit te doen. Een goed gebouwde server is expliciet over welke van de drie hij voor een gegeven vermogen aanbiedt, want precies dat onderscheid bepaalt of een gekoppelde AI-tool iets alleen kan bekijken of ook kan wijzigen.
Wie het nog meer oppakte, en wanneer
De eerste maanden van MCP waren een project van alleen Anthropic. Dat veranderde snel, en op een manier die in AI echt ongewoon is: directe concurrenten kwamen samen op het protocol van één bedrijf, in plaats van hun eigen protocol te verschepen. OpenAI voegde in maart 2025 MCP-ondersteuning toe aan zijn Agents SDK, zodat ontwikkelaars agentworkflows aan elke MCP-server kunnen koppelen in plaats van maatwerk, OpenAI-specifieke toolintegraties te bouwen. De maand erna bevestigde Google DeepMind dat Gemini en de eigen agent-ontwikkelkit MCP ook zouden ondersteunen — een stap die Google koppelde aan een eigen aanvullend protocol, Agent2Agent, bedoeld om onafhankelijke agents met elkaar te laten coördineren in plaats van alleen met tools. In mei 2025 had Microsoft native MCP-ondersteuning naar Windows 11 gebracht via wat het Windows AI Foundry noemt, en de ondersteuning landde ook in GitHub Copilot en Copilot Studio.
Geen van die vier bedrijven is het ergens over eens als het gaat om modelarchitectuur, prijzen of platformstrategie. Alle vier leveren nu producten die hetzelfde protocol spreken om een agent aan een tool te koppelen. Dat is in deze sector zeldzaam genoeg om het eigenlijke verhaal te zijn — meer dan welke losse functie MCP ook mogelijk maakt.
Waarom dit een vertrouwensvraag is, niet alleen leidingwerk
Die convergentie is echt nuttig, en precies daarom verdient MCP onderzoek in plaats van blind vertrouwen. Een protocol dat het triviaal maakt voor een agent om verbinding te maken met de systemen van je bedrijf, is een protocol dat het triviaal maakt voor een slecht gebouwde of slecht geconfigureerde verbinding om diezelfde systemen te bereiken. MCP zelf voorkomt dat niet. De specificatie definieert hoe een client en een server met elkaar praten — ze zegt niets over wie een verbinding mag verlenen, wat die verbinding mag aanraken, of iemand het merkt als er iets misgaat. Die keuzes liggen volledig bij wie de concrete server of client voor je heeft gebouwd of geconfigureerd. Sommige leveranciers bouwen dat allemaal zorgvuldig. Sommige bouwen het helemaal niet, en het protocol zal hen niet tegenhouden.
MCP is een draadprotocol, geen toegangscontrolesysteem. Het standaardiseert hoe een agent een tool vraagt iets te doen. Of die vraag begrensd, gelogd en intrekbaar is, is een beslissing die iemand erbovenop heeft genomen — of niet.
Een checklist voordat je er een koppelt
Voordat je team een MCP-server koppelt — of het nu een product van een leverancier is, een open-sourcetool die iemand op GitHub vond, of iets dat intern is gebouwd — scheiden zes vragen een bestuurde verbinding van een open deur. Geen ervan vereist het lezen van de specificatie. Ze vereisen alleen dat iemand vraagt voordat er op goedkeuren wordt geklikt, en het antwoord dat het verbindingsscherm teruggeeft ook echt leest.
| Vraag dit | Zo ziet goed eruit | Let op |
|---|---|---|
| Welke scopes of tools vraagt het? | Gespecificeerd Een benoemde, concrete lijst die je kunt lezen voordat je goedkeurt — "taken aanmaken, berichten in dit kanaal lezen." | Allesomvattend "Volledige accounttoegang" zonder gespecificeerde lijst van wat het echt kan doen. |
| Is het alleen-lezen, of kan het schrijven en handelen? | Gescheiden Leestoegang als standaard; elke actie die data wijzigt heeft een eigen zichtbare toestemming nodig. | Gebundeld Schrijftoegang automatisch inbegrepen, zonder manier om te zien welk vermogen wat doet. |
| Is het per persoon of teamwijd gedeeld? | Per persoon Elke persoon meldt zich aan met de eigen login; de agent ziet alleen wat die persoon kan zien. | Gedeeld Eén API-sleutel of serviceaccount voor het hele team, waarmee individuele rechten worden omzeild. |
| Is er een auditlog van wat het deed? | Gelogd Elke tool-aanroep vastgelegd — wie hem koppelde, wat hij aanraakte en wanneer. | Ongelogd Geen vastlegging behalve wat de AI-tool zelf kiest te vertellen dat er gebeurde. |
| Kan het direct worden ingetrokken? | Direct Eén schakelaar, meteen van kracht, vanaf een instellingenpagina die jij beheert. | Vertraagd Intrekken vereist een supportticket, een belletje met de leverancier, of is helemaal niet mogelijk. |
| Breekt intrekken iets anders? | Geïsoleerd Beperkt tot die ene verbinding; uitzetten raakt alleen die. | Verstrengeld Deelt een credential met andere tools, zodat het intrekken van één er stilletjes drie andere breekt. |
Hoe een goed gebouwde verbinding er werkelijk uitziet
FabricLoops eigen MCP-opzet is één concreet antwoord op die checklist — niet omdat die ongewoon is, maar omdat elk stuk direct op een van de zes vragen hierboven past, en het de moeite waard is de echte mechaniek te benoemen in plaats van de marketingversie. FabricLoop draait tegelijk in beide rollen: het is een MCP-server waar externe tools op aansluiten, zodat Cursor, Claude of ChatGPT een taak kan aanmaken, een opmerking kan toevoegen of een notitie kan lezen met de eigen FabricLoop-rechten van een specifieke persoon — en het is een MCP-client die naar buiten verbindt, zodat een kanaal de MCP-app van een leverancier, zoals GitHub of Linear, kan binnenhalen en die met een @mention kan aanspreken als een teamgenoot.
Elke verbinding, in beide richtingen, begint bij een persoon, niet bij een workspace. Een externe client zoals Cursor koppelen opent een OAuth-toestemmingsscherm op app.fabricloop.com/oauth/consent, waar die persoon een workspace kiest en de specifieke tools goedkeurt die de client vraagt — de client kan daarna alleen handelen met de scopes die op dat scherm zijn verleend, onder de rechten van die ene persoon, nooit via een gedeeld serviceaccount. De omgekeerde richting werkt hetzelfde: een beheerder kan de MCP-app van een leverancier voor het hele team inschakelen, maar elke persoon rondt nog steeds de eigen aanmelding af voordat het voor hem of haar werkt, en een beheerder kan die app op alleen-lezen zetten of beperken tot een allowlist van specifieke tools in plaats van alles wat de leverancier ontsluit.
Elke gekoppelde client verschijnt op een instellingenscherm naast een Revoke-knop die hem direct verbreekt — op de eigen pagina van de persoon, niet in een supportticket. Op Enterprise-plannen belandt die activiteit — inclusief MCP-verleningen en wat een gekoppelde agent echt deed — in een auditlog die een beveiligingsteam op verzoek kan nalopen, in plaats van screenshots die achteraf uit een chatthread worden getrokken.
Niets daarvan is exotische engineering. Het is een kleine, bewust onspectaculaire reeks beslissingen, consequent herhaald: begrenzen, aan een persoon koppelen, loggen, intrekbaar maken zonder nevenschade. Dat is hetzelfde argument dat deze site breder maakt over Leesbaarheid — toegang die je kunt benoemen, loggen en intrekken wint van toegang waar niemand over hoeft na te denken — en MCP levert dat alleen als iemand het zo bouwt. Het protocol maakt de leiding standaard. Het maakt het bestuur niet automatisch.
De beslissing die er werkelijk toe doet
MCP gaat niet weg, en je er nu tegen verzetten lijkt een beetje op je tegen USB verzetten. Elke grote modelaanbieder levert het inmiddels, de lijst beschikbare servers blijft groeien, en een agent die je tools niet kan bereiken is, voor het meeste echte werk, een agent die niet veel kan. De interessante beslissing is niet of je een AI-tool aan je systemen laat koppelen — steeds vaker wordt een versie van die beslissing al voor je genomen, één integratie tegelijk, terwijl tools die je team al gebruikt stilletjes MCP-ondersteuning toevoegen onder een functie waar je op klikte zonder de kleine lettertjes te lezen. De beslissing die nog echt van jou is, is wat je controleert voordat je op goedkeuren klikt.
MCP standaardiseerde hoe een AI-agent een tool vraagt iets te doen. Het deed niets om te standaardiseren of die vraag veilig is om te verlenen — dat deel is nog steeds, en blijft, een beslissing van de persoon die op "goedkeuren" klikt.