Voor N tools en M modellen waren vroeger N×M adapterlagen nodig. MCP ontkoppelt de toolkant van de modelkant, zodat beide het protocol maar één keer hoeven te implementeren. Dit artikel bespreekt die ontwerpkeuze, de abstractie van browseromgevingen en pagina-acties en wat nog niet is opgelost.
Als een Agent echt werk moet uitvoeren, komt die uiteindelijk meestal in de browser terecht: inloggen, publiceren, gegevens verzamelen of formulieren invullen. Technisch is niet de vraag of er geklikt kan worden, maar hoeveel integratiewerk nodig is om een browser aan een Agent beschikbaar te stellen.
De N×M-valkuil van adapters
Stel dat er N tools en M modellen op de markt zijn. Een toolleverancier moet voor elk model een aparte koppeling schrijven, terwijl de modelkant voor elke tool een adapterlaag nodig heeft. Beide kanten onderhouden hun eigen implementaties, samen N×M.
Het probleem is de vermenigvuldiging. Eén extra tool betekent niet één extra taak, maar een nieuwe koppeling tussen die tool en ieder model. Omgekeerd kan een nieuwe modelversie betekenen dat reeds gekoppelde tools opnieuw moeten worden gevalideerd. Een functie kan nog zo goed zijn: zonder adapter voor een bepaald model is ze daar niet bruikbaar en blijft de tool steken in de distributielaag.
In het begin moest iedereen zijn eigen integratie bouwen. Voor hetzelfde werk — omgevingen opsommen, een browser starten, een pagina lezen — moest alles opnieuw worden geschreven zodra de aanroeper veranderde, vaak met uiteenlopende logica: de ene implementatie plaatste wachttijd in de client, de andere in de server.
Het protocol ontkoppelt beide kanten
MCP (Model Context Protocol) werd eind 2024 openbaar gemaakt. Het idee is om toolontdekking en toolaanroepen in een standaardformaat vast te leggen: wat wordt aangeboden, hoe worden parameters beschreven en welke structuur wordt teruggegeven?
De architectuur wordt daarmee een Agent die is verbonden met een MCP Client. Die Client verbindt volgens het protocol met meerdere MCP Servers, waarachter de concrete mogelijkheden zitten. Het aantal implementaties daalt van N×M naar N+M: de modelkant implementeert de client één keer en de toolkant de server één keer.
Er zijn maar drie rollen. De Host is de toepassing waarin het model draait en die de client start. De Client is de implementatie van de protocolclient, doorgaans één per Server. De Server wordt door de toolleverancier gebouwd en stelt mogelijkheden beschikbaar als gestandaardiseerde tools.
Er zijn momenteel twee communicatiemodi. De lokale modus gebruikt standaardinvoer en -uitvoer, waarbij client en server op dezelfde machine draaien; de route is kort en er is weinig configuratie nodig, waardoor dit vaak bij automatisering wordt gebruikt. De externe modus gebruikt HTTP of WebSocket en past bij gedistribueerde implementaties, maar vraagt extra aandacht voor authenticatie en netwerkgrenzen.
In de browser zijn drie lagen zichtbaar
Wanneer een browseromgeving op het protocol wordt aangesloten, vallen de aangeboden mogelijkheden grofweg uiteen in drie lagen.
Bovenaan staat de omgeving: omgevingen van een account opsommen, een nieuwe omgeving volgens configuratie maken, een specifieke omgeving starten, een netwerkuitgang koppelen en de omgeving na gebruik sluiten. Deze handelingen zaten vroeger verspreid over verschillende API’s; nu zijn het tools die een model kan ontdekken en aanroepen. Na het starten wordt meestal een debug-endpoint teruggegeven, bijvoorbeeld een poort of WebSocket-adres, dat kan worden doorgegeven aan drivers zoals Selenium of Puppeteer.
De middelste laag is de pagina: een adres openen, de DOM of toegankelijkheidsboom lezen, van tabblad wisselen en screenshots maken.
De onderste laag bestaat uit acties: klikken, typen, scrollen, wachten op een voorwaarde en pop-ups afhandelen.
De belangrijkste verandering is niet hoeveel acties er zijn. De omgeving verandert van code die je zelf moet schrijven in een resource die de Agent zelf kan kiezen en gebruiken. Je hoeft alleen het doel te beschrijven; de Agent kan bepalen of een nieuwe omgeving nodig is of een bestaande kan worden hergebruikt, en in welke volgorde tools worden aangeroepen. Bij meerdere parallelle omgevingen wordt dat extra duidelijk: de planning staat in de prompt in plaats van hard gecodeerd in een script.
Wat nog niet is opgelost
Het protocol lost verbindingen op, niet de juistheid. Er blijven enkele punten die gemakkelijk over het hoofd worden gezien.
De kwaliteit van toolbeschrijvingen bepaalt het resultaat van aanroepen. Verkeerde parameters of de keuze van de verkeerde tool kan het protocol niet herstellen. Naarmate er meer tools zijn, nemen hun beschrijvingen bovendien context in beslag, zodat er een afweging nodig is tussen aantal en granulariteit. Bij te grove tools weet het model niet goed hoeveel taken één tool afdekt; bij te fijne tools raakt de context eerder vol.
Rechten en auditing staan nog aan het begin. Veel servers draaien lokaal op één machine, starten met aanzienlijke bevoegdheden en missen fijnmazige autorisatie en gedetailleerde aanroeplogboeken. In de externe modus moet eerst duidelijk zijn wie verbinding mag maken en wat diegene kan zien.
De instabiliteit van pagina’s verdwijnt evenmin. Niet gevonden elementen, onvoorspelbare laadtiming, verlopen sessies en CAPTCHA’s vereisen nog altijd wachttijden, herhaalpogingen en uitwijklogica. Het protocol standaardiseert alleen het toegangspunt.
Ook de volwassenheid van het ecosysteem verschilt. Servers ondersteunen niet exact dezelfde resourcetypen, retourstructuren of foutcodes. Wanneer een taak meerdere servers combineert, moet de orkestratielogica vaak nog zelf worden geschreven. Het protocol blijft zich ontwikkelen, waardoor gedragsverschillen tussen versies aandacht vragen.
Nog een grens moet helder blijven: het protocol bepaalt hoe een model tools aanroept, niet of de taak zelf aan regels voldoet. Of gegevensverzameling is toegestaan, of een account voor een legitiem doel wordt gebruikt en of platformregels worden overtreden zijn afzonderlijke beoordelingen en staan los van hoe soepel de verbinding werkt.
In scenario’s met meerdere omgevingen hebben de onderlinge isolatie en de samenhangende configuratie van netwerkuitgang, tijdzone en taal vaak meer invloed op het resultaat dan de integratiemethode. Op het niveau van omgevingsisolatie biedt PurpleMark interfaces voor het aanmaken en starten van omgevingen en voor netwerkconfiguratie, die door AI-tools kunnen worden aangeroepen en via één client kunnen worden gepland.
Dit artikel licht alleen technische principes toe. Gebruik de betreffende protocollen en tools binnen de geldende wet- en regelgeving.
