MCP (Model Context Protocol) uitgelegd | EIGHTY8

Wat is MCP? Een open protocol waarmee AI-modellen op een standaardmanier tools en databronnen aanspreken. Wat het betekent voor koppelingen in je bedrijf.

MCP (Model Context Protocol) is een open standaard waarmee een AI-model op één vaste manier verbinding maakt met externe tools en databronnen. Als een soort stekkerdoos tussen model en bedrijfssystemen. In plaats van voor elke koppeling een eigen bouwwerk te maken, sluit je een bron één keer aan op het protocol en kan elke MCP-capabele toepassing er bij.

Elke AI-toepassing die echt iets doet (een agenda bijwerken, een order opzoeken, een dossier bijwerken) heeft koppelingen nodig. Vóór dit soort standaarden betekende dat: per tool een eigen integratie bouwen, met eigen authenticatie, eigen foutafhandeling en eigen onderhoud. Vijf tools betekende vijf bouwwerken. MCP doet daar één ding tegenover: het beschrijft hoe een toepassing beschikbaar stelt wat hij kan (een lijst tools met hun parameters) en hoe een model ze aanroept.

De vergelijking die goed werkt, is die van een stekker en stopcontact. Apparaatfabrikanten bouwden ooit elk hun eigen aansluiting; de standaard maakte dat elk apparaat in elk stopcontact past. Zo ook hier: een leverancier die zijn product MCP-vaardig maakt, is daarmee aansluitbaar op elke toepassing die het protocol spreekt. En omgekeerd. Het protocol zelf is open, dus geen enkele partij bezit het.

Wat MCP níet doet is net zo belangrijk. Het beslist niet wie er bij welke data mag; rechten en authenticatie blijven verantwoordelijkheid van de aanleverende kant. En het maakt een slechte koppeling niet automatisch goed: als de onderliggende systemen rommelig zijn of de rechten niet kloppen, verspreidt het protocol die rommel alleen sneller. Het is een aansluiting, geen kwaliteitskeurmerk.

De moeite waard is het zodra je meerdere AI-toepassingen verwacht die op dezelfde bronnen uitkomen, of als de tools die je wilt gebruiken al MCP-aansluitingen dragen. Dan spaar je herhaald integratiewerk uit en zijn nieuwe toepassingen sneller te bouwen. Ook voor interne gereedschapskisten (een zoeklaag, een agenda, een opzoekingstool) is één gestandaardiseerde aansluiting een logische keuze.

Niet nodig is het voor een toepassing die maar één koppeling heeft en die nooit meer wordt: dan is een directe, eenvoudige integratie simpeler. Wees bovendien zuinig met wat je via een protocol toegankelijk maakt. Alles wat erop is aangesloten is onderdeel van je aanvalsoppervlak. Wie één dossierstelsel heeft en drie inzichten wil, kan beter eerst die drie goed bouwen.

We gebruiken het protocol waar het herhaling voorkomt en bouwen direct waar één koppeling volstaat. De keuze hangt af van jouw landschap, niet van de mode. Bij elke aansluiting geldt dezelfde regel als bij gewone integraties: beperkte rechten per toepassing, logging van wat er aangeroepen werd, en een menselijke controle op acties met gevolgen. Zo profiteer je van de standaard zonder dat het gemak een deur wordt die niemand meer bewaakt.

Is MCP een product dat we moeten kopen of een abonnement dat doorloopt?

Nee: MCP is een open protocol, geen product, dus er is geen licentie en geen leverancier die het bezit. De kosten die je wél maakt zijn die van bouwen en beheren. Een bron MCP-vaardig maken, rechten inrichten en het bewaken. Sommige softwarepakketten bieden standaard-aansluitingen aan, en dan zit het in je bestaande abonnement. We adviseren het alleen waar het werk verkleint, niet omdat een standaard chic staat.

Wat lost MCP op dat losse koppelingen niet oplossen?

Herhaling. Zonder standaard bouw je per tool een eigen integratie met eigen authenticatie en onderhoud, en elke nieuwe AI-toepassing begint opnieuw. Met het protocol sluit je een bron één keer aan en is hij bereikbaar voor elke toepassing die het protocol spreekt; nieuwe tooling wordt daardoor sneller bruikbaar. Voor één koppeling die nooit meer verandert wint de standaard weinig. De winst zit in de tweede, derde en vierde aansluiting.

Kunnen onze bestaande systemen en API's via MCP worden aangesloten?

Meestal wel, mits er een bruikbare interface is: een API met logische mogelijkheden en rechten die je kunt beperken. Zo niet, dan bouwen we een dunne tussenlaag die jouw systeem beschikbaar stelt volgens het protocol. Dat is gewoon bouwwerk, geen truc. Wat telt vooraf is de vraag wat een model met die bron mag doen: lezen alleen, of ook bijwerken. Die afweging hoort bij het ontwerp, niet bij de aansluiting zelf.

Hoe voorkomen we dat een agent via MCP te veel mag?

Door het protocol te behandelen als een deur met een systeemsleutel in plaats van een hoofddeur zonder slot. Praktisch: per toepassing een eigen aansluiting met minimale rechten, schrijfacties apart houden van leesacties, alles loggen wat er wordt aangeroepen, en acties met gevolgen achter een menselijke goedkeuring zetten. We bouwen dat standaard zo in. Het gemak van één aansluiting mag nooit betekenen dat alles wat erachter hangt één gedeeld pasje krijgt.

EIGHTY8