MCP uitgelegd: zo werkt Model Context Protocol

LLM’s kunnen al een tijdje tools aanroepen, maar Model Context Protocol (MCP) biedt een gestructureerde, gestandaardiseerde manier om dat te doen.

Toch is er nog steeds verwarring over wat MCP eigenlijk is.

Veel mensen denken dat MCP een app, een API of een tool is, maar dat is het niet. Het is een protocol, en dat betekent iets heel specifieks.

Laten we het stap voor stap bekijken.

Als je alleen wilt zien wat MCP in de praktijk mogelijk maakt, bekijk dan deze korte video:

Wat is een protocol?

Een protocol is simpelweg een set regels die bepaalt hoe twee of meer systemen met elkaar communiceren.

Het doet zelf niets. Het definieert alleen de structuur en verwachtingen van een gesprek tussen twee entiteiten. Zie het als een gedeelde taal met strikte grammaticaregels die computers volgen om informatie uit te wisselen.

Postsystemen doen iets vergelijkbaars. Alle postkantoren in een bepaald land volgen een gestandaardiseerde adresindeling om brieven te versturen.

Of zie het als USB-C voor AI-tools. Twintig jaar geleden werd de markt overspoeld met verschillende soorten laad- en datakabels. Op dezelfde manier hebben AI-ecosystemen meerdere manieren gehad om tools door te geven aan taalmodellen. Frameworks zoals LangChain, Haystack en Pydantic AI definieerden allemaal hun eigen indelingen voor het integreren van tools. Dat betekende dat als een developer een toolset voor Google Maps wilde schrijven, die dat voor elke specifieke technologie moest doen.

Om dit concreter te maken, kijken we naar het bekendste protocol, HTTP (Hypertext Transfer Protocol), dat websites mogelijk maakt. HTTP definieert onder andere hoe een browser (client) een webpagina opvraagt bij een webserver en hoe de server moet reageren.

Hier is een voorbeeld van een HTTP request-response-cyclus:

1. Browser doet een HTTP-request

Wanneer je https://example.com in je browser typt, stuurt de browser een gestructureerd HTTP-request naar de webserver:

Dit zijn de HTTP-parameters en waarden die in ons voorbeeld worden gebruikt:

"GET" – Dit is de actie (een webpagina opvragen).
"/index.html" – De specifieke webpagina die wordt opgevraagd.
"HTTP/1.1" – De versie van het protocol die wordt gebruikt.
"Host: example.com" – De domeinnaam van de website.
"User-Agent: Mozilla/5.0" – Informatie over de browser die het request doet.

De webserver weet hoe hij dit request moet interpreteren omdat HTTP deze indeling standaardiseert. Hij begrijpt deze “taal.”

2. Server reageert met het HTTP-protocol

De server verwerkt het request en stuurt een gestructureerde HTTP-response terug:

"HTTP/1.1 200 OK" – De responsecode (200 betekent succes).
"Content-Type: text/html" – Het type content dat wordt teruggestuurd.
"Content-Length: 512" – De grootte van de response.
HTML-content – De daadwerkelijke content van de webpagina (er staat alleen een kop "Welkom bij Example.com")

Belangrijk: HTTP zelf bewaart geen webpagina’s en toont ze ook niet. Het definieert alleen de regels voor hoe webbrowsers en webservers mogen communiceren. Elk systeem dat die regels volgt, kan communiceren via het door HTTP gedefinieerde internet.

Hoe MCP werkt als protocol

Laten we dezelfde manier van denken nu toepassen op MCP (Model Context Protocol).

MCP is een protocol waarmee AI-agents met externe tools en databronnen kunnen praten. Net als HTTP slaat het zelf geen data op en voert het zelf geen taken uit. Het definieert simpelweg een gestandaardiseerde manier waarop AI informatie kan opvragen en ophalen bij tools.

Wat zijn die “tools” precies?

In de context van LLM’s zijn tools externe systemen, API’s of services waarmee AI kan communiceren om de mogelijkheden uit te breiden voorbij alleen tekstgeneratie. Ze laten AI-agents realtime data ophalen, afspraken boeken of je vrienden een bericht sturen, waardoor ze veel nuttiger worden voor praktische toepassingen.

Stel dat je een AI-agent vraagt:

“Hoe laat is het nu in Londen?”

Omdat de AI zelf het juiste antwoord niet weet, aangezien AI-modellen een kennis-cutoffdatum hebben (oktober 2023 voor OpenAI’s modellen), moet deze live data ophalen bij een tijdservice. Maar in plaats van HTTP te gebruiken om een webpagina op te vragen, gebruikt de AI MCP om tijdgegevens op te vragen.

Dit gebeurt er:

1. AI-agent doet een MCP-request naar de tijdservice (voorbeeld)

"method": "tools.call" → De AI roept een externe tool aan.
"tool": "get_time" → De naam van de tool die hij wil gebruiken.
"args": { "location": "London" } → De specifieke invoerparameters.

Net als bij HTTP volgt dit request een strikte indeling, zodat elke MCP-compatibele tool precies weet hoe het moet worden geïnterpreteerd.

2. MCP-tijdserver reageert

De externe tool (tijdserver) volgt de responsregels van MCP en stuurt terug:

"status": "success" → Bevestigt dat het request correct is verwerkt.
"result" → Bevat de daadwerkelijke tijdgegevens.

Nu kan de AI-agent deze data gebruiken en een echt antwoord aan de gebruiker formuleren:

“De huidige tijd in Londen is 12:20 PM (GMT).”

Samengevat, om de verwarring weg te nemen:

“MCP is een app.” → Nee, MCP is een set regels. Je hebt AI-software en tools nodig die MCP implementeren om het daadwerkelijk te gebruiken, net zoals de Instagram-app live Instagram-servers nodig heeft om op HTTP-requests te reageren en data te leveren.

“MCP is een database.” → Nee, MCP slaat geen data op. Het helpt AI-agents om met databases of API’s te praten.

“MCP is als een API.” → Niet precies. Een API is een specifieke manier om met één systeem te communiceren, terwijl een protocol (zoals MCP of HTTP) een universele manier definieert waarop veel verschillende systemen kunnen communiceren. MCP is een taal die een AI-systeem kan gebruiken om met veel daadwerkelijke API’s te communiceren (tijd, databases, Stripe, Slack, enzovoort).

Waarom MCP interessant is

Nu we weten dat MCP een gestandaardiseerde manier is waarop AI-software met externe tools en apps kan communiceren, en dat MCP geen API is, kunnen we bekijken waarom de community van AI-developers (waaronder wij) er enthousiast over werd.

Omdat MCP geen API is, maar AI-apps juist in staat stelt om op schaal met echte API’s te communiceren, helpt het projecten die verbinding met veel externe systemen vereisen sneller van de grond te krijgen. Tools geven een model ook bereik, en wat er gebeurde bij het OpenAI Hugging Face-incident laat zien hoe dat bereik eruitziet wanneer het de taak overstijgt. Hiervoor moesten developers soms een volledige ontwikkelcyclus voor API-integratie doorlopen, maar tegenwoordig gebruiken ze meestal bestaande libraries of open-sourceprojecten (bijvoorbeeld beschikbaar op GitHub) die de benodigde functionaliteit bieden.

Het gebruik van deze libraries versnelt de ontwikkeling, maar ze goed integreren met je systeem (als het niet compatibel is met de implementatie die je op GitHub hebt gevonden) kost nog steeds moeite om de tool met de AI te laten werken.

Met MCP kan het toevoegen van een nieuwe integratie (bijvoorbeeld Google Drive integreren), zodra het framework aanwezig is, neerkomen op verbinding maken met de Google Drive MCP-server met een paar regels code. Je krijgt geen compatibiliteitsproblemen omdat jullie allebei hetzelfde protocol gebruiken: MCP.

Laten we beide benaderingen vergelijken om de verschillen duidelijker te zien.

Standaardintegratie versus Model Context Protocol (MCP) gebruiken

Om deze vergelijking concreet te maken, lopen we door het toevoegen van toegang tot Google Drive-bestanden aan een AI Agent, eerst handmatig en daarna met een MCP-compatibele tool.

Standaardintegratie

1. Een library vinden en aanpassen: Je zoekt naar een Google Drive API-client of open-sourceproject. Google biedt clientlibraries (bijvoorbeeld Google Drive API voor Python). Je neemt deze op in je project. Je moet nog steeds controleren of die werkt met de omgeving van je AI.

2. De logica implementeren: Je schrijft functies om bijvoorbeeld bestanden te zoeken of een document uit Drive op te halen. Wanneer de AI iets nodig heeft, moet deze die functies aanroepen. Je zet het request van de AI om naar Google Drive-specifieke API-calls. Nadat je een response van Google hebt ontvangen, haal je de content eruit om die terug te geven aan de context van de AI.

3. Fouten en randgevallen afhandelen: Voeg code toe voor situaties zoals “bestand niet gevonden”, rechtenfouten of API-rate limits. Als Google’s API een fout retourneert, vang je die af en reageer je misschien met een verontschuldigend bericht of vraag je de AI om te herformuleren. Je moet ook voorkomen dat je AI te snel te veel requests verstuurt.

4. Onderhouden: Als Google na verloop van tijd de API of de library bijwerkt, moet je je code bijwerken. Als je een bug in de library vindt, moet je mogelijk patchen of een andere bron zoeken. Je wordt feitelijk de maintainer van deze Google Drive-integratie binnen je AI-applicatie.

Dit proces geldt ook voor andere tools: wil je Slack of een database toevoegen aan je AI? Dan moet je het hele proces voor elke tool herhalen.

MCP-integratie

Laten we nu bekijken hoe dat proces eruitziet wanneer je MCP gebruikt.

Eerst definiëren we de kernbegrippen:

Client – een AI-applicatie (ChatGPT, Claude app, Quickchat AI) die verbinding maakt met een of meer servers en informatie of acties opvraagt om taken uit te voeren die door een gebruiker zijn gevraagd.

Server – Elke server kan verbinding maken met bijvoorbeeld een database of een API (Google Drive) en een set “tools” of data definiëren die hij kan leveren. In dit geval is een server een programma dat deze tools en mogelijkheden beschikbaar maakt voor de Client (AI-app).

Developers kunnen, afhankelijk van wat ze willen doen, aan beide kanten zitten: een server bouwen om data beschikbaar te maken, of een AI-client bouwen die met elke server kan praten. De meeste willen de tweede optie, maar laten we toch beginnen met de serverkant om stap voor stap te begrijpen hoe MCP werkt:

• Een MCP-server initialiseren. Een developer of systeembeheerder zet een MCP-server op voor een bepaalde tool of databron. Een MCP-server is meestal gewoon een klein programma dat de MCP-specificatie implementeert. Er is bijvoorbeeld een vooraf gebouwde Google Drive MCP-server beschikbaar die weet hoe hij documenten moet zoeken en ophalen.

  Wanneer je de server initialiseert, geef je deze toegang tot het doelsysteem (Google Drive). De server maakt vervolgens een set tools beschikbaar die overeenkomen met acties of queries die hij kan afhandelen. Het is in wezen een API-adapter die aan de ene kant MCP spreekt en aan de andere kant de native service.

  Zodra de server draait, wacht hij op requests.

• Een LLM (client) verbinden met een MCP-server. Vervolgens moet de AI-applicatie (de “client”-kant) verbinding maken met die server. In de praktijk configureer je, als je een AI-platform gebruikt dat MCP ondersteunt (zoals Claude Desktop), het platform met het adres of de opdracht om de server te starten. Zodra er verbinding is, maakt de client een sessie met de server op volgens de handshake van MCP. Als je de interface van Claude gebruikt, zie je dat Claude “connected” is met bepaalde MCP-servers (de UI kan beschikbare connectors tonen).

Zo ziet het eruit in Claude UI

• Beschikbare tools ontdekken. Zodra de verbinding is opgezet, is het eerste wat je doet achterhalen wat de server aanbiedt (soms gebeurt dit automatisch nadat je verbinding met de server hebt gemaakt). De MCP-client stuurt een tools/list-request naar de server (dit is gedefinieerd in het protocol). De server antwoordt met een lijst van beschikbare tools, elk met details zoals naam, beschrijving en invoerschema.

  Een server kan bijvoorbeeld antwoorden dat hij de tools create_file(path, content), read_file(path) en search_files(query) beschikbaar heeft. De client maakt deze informatie vervolgens beschikbaar voor de LLM. In veel implementaties zal de client deze toolbeschrijvingen formatteren en opnemen in de context van het model (bijvoorbeeld door toe te voegen aan de system prompt: “Je hebt toegang tot de volgende tools… [tool list]”).

Hier is een AI-system prompt samen met het bericht van de gebruiker waarin om de huidige tijd wordt gevraagd

Met geïmplementeerde MCP-tools wordt een tool met de naam “get_current_time” geïntegreerd, waardoor de AI toegang krijgt tot een externe resource en de exacte tijd in Londen kan ophalen

Dit betekent dat je niet vooraf alle mogelijke acties hoeft te bedenken en programmeren die je AI-app nodig kan hebben om een taak uit te voeren. Met MCP kan de AI alle mogelijke acties on the fly ontdekken door een MCP-server te vragen en kiezen wat nodig is.

• Een tool gebruiken via MCP. Wanneer de AI een actie moet uitvoeren of data moet ophalen, roept deze een tool aan via MCP. Vanuit het perspectief van de AI (vooral bij modellen zoals Claude die toolgebruik native ondersteunen) beslist hij in zijn redenering: “Ik moet tool X met deze parameters aanroepen.” De MCP-client vangt die intentie op en stuurt een tools/call-request in MCP-indeling naar de juiste server (Google Drive MCP-server).

• De MCP-server fungeert als brug. Hij ontvangt een gestructureerd MCP-conform request van de AI-agent, koppelt het aan het juiste Google Drive API-endpoint, herschrijft het request naar een daadwerkelijke Google Drive API-call, voert het request uit, verwerkt de response en formatteert die opnieuw als een MCP-conforme response voordat hij deze terugstuurt naar de AI-agent.

  Het is de moeite waard om op te merken dat MCP-servers een gestructureerde aanpak volgen voor het afhandelen van fouten, zodat AI Agents die effectief kunnen interpreteren en erop kunnen handelen.

  Stel dat een AI Agent een MCP-tool gebruikt om een bestand in Google Drive te vinden. Als het request een ongeldig bestands-ID bevat (bijvoorbeeld een string van vijf tekens in plaats van de verwachte indeling), retourneert de MCP-server een foutmelding:

  In plaats van simpelweg te falen, kan de AI Agent deze gestructureerde response gebruiken en omzetten in gebruiksvriendelijke feedback:

  “Het lijkt erop dat het bestands-ID dat je hebt opgegeven te kort is. Google Drive-bestands-ID’s zijn meestal 28 tekens lang. Kun je dit controleren en het opnieuw proberen?”

  Deze aanpak zorgt ervoor dat fouten niet tot doodlopende situaties leiden, maar kansen worden voor de AI Agent om de gebruiker naar een succesvolle oplossing te begeleiden.

• De vraag/het verzoek van de gebruiker beantwoorden. Zodra de MCP-server een resultaat retourneert, geeft de MCP-client die data terug aan de AI-app. Het model verwerkt het resultaat vervolgens in zijn redenering of direct in de output die het voor de gebruiker genereert.

  Als de gebruiker vraagt om een nieuw Google Sheets-bestand te maken, wordt de respons van de server (met het bestands-ID en een gegenereerde link) aan het model doorgegeven. Het model reageert dan aan de gebruiker met: “Goed nieuws! Je nieuwe Google Sheets-bestand is klaar. Je kunt het hier openen: [link].”

Tijdens dit hele proces houdt de AI controle over de flow: hij beslist wanneer hij een tool aanroept en hoe hij het resultaat gebruikt om zijn antwoord te vormen. Ondertussen hoeft de developer deze stappen niet handmatig te orkestreren, het MCP-framework en het AI-model handelen dit af. Het eindresultaat is dat de gebruiker de AI complexe vragen of taken kan geven waarvoor externe informatie of acties nodig zijn, en dat de AI die via MCP autonoom kan uitvoeren en een resultaat kan teruggeven.

Voordelen van het gebruik van MCP

Merk op hoe deze aanpak veel details abstraheert: de client hoefde geen API-sleutels of HTTP-statuscodes af te handelen, dat doet de MCP-server.

Het belangrijkste punt is de eenvoud op het integratiepunt: we “vragen” om klanten en krijgen ze. De logica om ze op te halen is elders ingekapseld. Dit betekent dat een developer die aan de AI-kant werkt geen nieuwe HTTP-calls hoeft te schrijven voor elke nieuwe actie, maar tools gewoon op naam aanroept. Het zware werk (auth, Google Drive-endpoints aanroepen, de response formatteren) gebeurt in de MCP-servercode, die herbruikbaar en gestandaardiseerd is.

Hier is een samenvatting van de belangrijkste voordelen:

• Vermindert API-specifieke glue code. Vóór MCP vereiste het laten gebruiken van een externe service door AI meestal veel “glue”-code: de API aanroepen, de response omzetten naar tekst die het model kan verwerken, vervolgens de output van het model parsen om mogelijk een andere API aan te roepen, enzovoort. Met MCP verdwijnt veel van die glue code. De client van het model en de server handelen data-uitwisseling gestructureerd af, zodat je andere indelingen (zoals JSON) niet handmatig naar tekst hoeft om te zetten of andersom, het protocol doet dat. Je hoeft ook geen logica te schrijven om te bepalen wanneer wat moet worden aangeroepen. De AI (geleid door de toolbeschrijvingen en zijn eigen redenering of prompt) doet dat.

• Herbruikbare, gedeelde connectors in plaats van eenmalige API-wrappers. Met MCP schrijf je een integratie één keer en kun je die hergebruiken in veel projecten en AI-systemen. Je kunt bijvoorbeeld een MCP-server maken voor de interne wiki van je bedrijf. Elke AI-app die MCP ondersteunt, kan verbinding maken met die ene server om de wiki te bevragen. Je hoeft “wiki search” niet opnieuw te implementeren voor elke nieuwe AI-chatbot of elke andere LLM-leverancier. Deze herbruikbaarheid is een verschuiving ten opzichte van vroeger, toen elk team misschien zijn eigen iets andere integratie voor dezelfde API schreef. MCP stimuleert een bibliotheek van connectors die gedeeld en gezamenlijk verbeterd kunnen worden.

• Plug-and-play-integratie met verschillende LLM’s. MCP is modelagnostisch. Het protocol maakt het niet uit of de client Claude, GPT-4, DeepSeek of een toekomstig model is, zolang de client de MCP-interface kan afhandelen. Als je in de toekomst naar een ander model wilt overstappen, kan dat zonder al je integraties te herschrijven.

• Eenvoudiger onderhoud. Omdat het een open standaard is, is er een groeiende community die vooraf gebouwde servers bijdraagt (voor databases, populaire API’s, enzovoort) die je kunt gebruiken in plaats van alles vanaf nul te bouwen. Naarmate je meer systemen integreert, helpt MCP om de “spaghetti” van veel point-to-point-integraties te vermijden. En je hoeft niet alle API-updates van andere providers te monitoren.

Worden API-integraties overbodig?

Zowel traditionele API-integraties als MCP hebben hun plaats. De beste aanpak kan afhangen van de aard van het project, de expertise van het team en de langetermijndoelen.

Als je maar met één of twee externe services hoeft te integreren en de interacties relatief eenvoudig zijn, is een directe API-integratie vaak de snelste oplossing. Als je webapp alleen een Stripe-betalingstoken bij checkout hoeft te verifiëren, is het direct aanroepen van Stripe’s API simpel en effectief. MCP introduceren in dit scenario kan overdreven zijn. Je kunt een AI Agent verbinden met elke gedocumenteerde REST API met één beoordeelde HTTP Action, of een one-click-integratie gebruiken zoals Google Sheets om leads en demo-aanvragen te loggen, zonder een MCP-server te draaien.

In gevallen waarin je zeer strakke controle nodig hebt over het request/de response (voor performance tuning, speciale data-afhandeling of propriëtaire protocollen), kan rechtstreeks naar de API schrijven beter zijn. Traditionele integraties laten je alle geavanceerde functies van een API gebruiken en de calls precies afstemmen. Als een API ongebruikelijke vereisten heeft of als je voor maximale duidelijkheid en controle elke abstractielaag wilt vermijden, is traditioneel passend.

Voor een concreet voorbeeld van hoe MCP-tools naast custom API-acties beschikbaar worden gemaakt voor een productie-AI Agent, zie hoe Quickchat AI Agents beide benaderingen combineren. De diepere bespreking van wanneer je MCP, afzonderlijke AI Actions of “Generate from Text” gebruikt, staat in API’s voor AI Agents: van MCP tot custom endpoints. Om het zelf te proberen, volg je de stapsgewijze gids om je AI Agent met een remote MCP-server te verbinden, zodat deze tijdens een live gesprek een tool aanroept.

Lijst met beschikbare MCP-servers

Als je met MCP wilt beginnen, bekijk dan de MCP-serverdirectories hieronder:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Je kunt er ook een draaien zonder code te schrijven: elke Quickchat AI Agent kan worden omgezet in een MCP-server met een hosted URL die Claude, ChatGPT en Cursor als tool aanroepen. De verbinding werkt ook de andere kant op: een Quickchat AI Agent kan de hosted MCP-server van een leverancier als tools aanroepen. Zo controleert de AI-planningsassistent gebouwd op Calendly’s MCP-server echte beschikbaarheid en boekt hij meetings vanuit een chat, en zo beantwoordt een Notion AI-chatbot vragen vanuit een live helpcenter en logt hij supportverzoeken terug in een Notion-database.

Quickchat AI draait ook een remote MCP-server voor je eigen account. Verbind deze met ChatGPT, Claude, Cursor of Codex en je kunt je AI Agents van daaruit beheren: analytics, gesprekstranscripten, kennisbankupdates en het maken van nieuwe Agents, achter één OAuth-login. De setup-walkthrough voor elke client staat in Beheer je AI Agent vanuit ChatGPT, Claude en Codex met MCP.

FAQ

Werkt het alleen met Claude?

MCP is modelagnostisch. Het protocol maakt het niet uit of de client Claude, GPT-4, een lokale LLaMA-variant of een toekomstig model is, zolang de client de MCP-interface kan afhandelen. Dit betekent dat je niet vastzit aan één AI-provider wanneer je je toolintegraties bouwt.

Waarin verschilt MCP van het model vooraf alle informatie geven die het nodig heeft? Waarom stop je de prompt niet gewoon vol met data?

MCP is fundamenteel anders dan de prompt van het model volstoppen met data, omdat het het model in staat stelt informatie dynamisch op te halen wanneer dat nodig is, in plaats van te werken met een statische, vooraf geladen prompt. Tekst in de prompt stoppen loopt tegen beperkingen aan, omdat AI-modellen een vast contextvenster hebben. Te veel data kan ertoe leiden dat belangrijke details verloren gaan, responses trager worden en API-kosten stijgen (door de prijsmodellen per token die LLM-leveranciers gebruiken). Het biedt ook alleen kennis op één specifiek moment, terwijl MCP realtime toegang tot live externe data mogelijk maakt en de AI actie laat ondernemen, niet alleen informatie laat lezen. Een AI met een volle prompt kent misschien klantgegevens, maar kan geen records bijwerken of transacties verwerken.

Wat als we tientallen tools met de AI verbinden? Overweldigt dat het model niet of leidt het er niet toe dat het ze verkeerd gebruikt?

Dat hangt af van de implementatie, maar het is waar dat huidige LLM’s beperkingen hebben in hoe goed ze onderscheid maken tussen veel opties en daaruit kiezen. Als je een model bijvoorbeeld 50 mogelijke tools presenteert, bestaat het risico dat het de verkeerde kiest. De MCP-aanpak zelf dwingt je niet om alles tegelijk te laden. Je moet relevante tools koppelen op basis van de context. Een best practice is om alleen de tools te koppelen die nodig zijn voor de taak/het domein in kwestie en multiagent collaboration te benutten, een vorm van toolrouting of een agent die eerst bepaalt welke subset van tools moet worden overwogen.

MCP versus Function Calling

Traditionele function calling (zoals te zien in OpenAI’s API of andere LLM’s) laat een developer een set functies definiëren, de definities aan het model geven en het model deze op naam met argumenten laten “aanroepen”. Dit was een grote stap voor AI-integratie, maar het heeft beperkingen. Een belangrijk verschil is wanneer en hoe tools worden gedefinieerd. Bij klassieke function calling moeten alle mogelijke functies vooraf (tijdens design time) in de prompt of via de API worden gedeclareerd. Het model kan alleen die vaste functies aanroepen. In MCP zijn tools tijdens runtime ontdekbaar, de AI kan opvragen wat beschikbaar is en zelfs halverwege een sessie nieuwe tools krijgen.

MCP versus GPT Actions & Plugins

GPT Actions/Plugins verwijzen naar OpenAI’s ecosysteem waarin je plugins (zoals een webbrowser of een PDF-lezer) kon inschakelen voor ChatGPT, of naar de “GPTs” (custom ChatGPT-agents) die tools kunnen gebruiken. Die waren interessant, maar vereisten custom development voor elke plugin en waren beperkt tot OpenAI’s platforms. Als je een ChatGPT-plugin voor een taak wilde, moest je een API en een manifest maken en door OpenAI’s goedkeuring heen of deze ten minste handmatig inschakelen. Elke plugin was in wezen een silo: een weerplugin, een reisplugin, enzovoort, elk met eigen endpoints en logica. MCP verbetert dit concept door het te verenigen en open te maken.

MCP versus RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) is een techniek waarbij een LLM wordt aangevuld met een externe kennisbank. Meestal omvat RAG een vectordatabase of zoekindex: de query van de gebruiker wordt gebruikt om relevante documenten of data op te halen (via semantisch zoeken of andere methoden), en die documenten worden aan het model gegeven als extra context om te “lezen” bij het vormen van een antwoord. RAG gaat over het geven van kennis aan het model die het oorspronkelijk niet had, vooral nuttig voor feitelijke QA of domeinspecifieke informatie. RAG is echter read-only, het model haalt tekstpassages op, maar voert geen acties uit behalve retrieval.

MCP daarentegen gaat over acties ondernemen of willekeurige bewerkingen uitvoeren, niet alleen informatieve context ophalen. Met MCP kan een AI dingen doen: naar een database schrijven, een e-mail versturen, code uitvoeren, enzovoort. Het is niet beperkt tot kennis ophalen, het kan wijzigingen in externe systemen triggeren. RAG en MCP dienen dus in veel opzichten verschillende doelen.