Model Context Protocol, meestal afgekort tot MCP, is een open protocol waarmee een AI-toepassing op een gestandaardiseerde manier context en functies van andere systemen kan gebruiken. Voor een ondernemer is vooral de praktische vraag relevant: welk werk kan hierdoor beter worden voorbereid, gecontroleerd en uitgevoerd?
MCP maakt van een taalmodel niet vanzelf een betrouwbare medewerker. Het kan wel een duidelijke brug vormen tussen een AI-toepassing en echte hulpmiddelen, zoals een kennisbron, planning of intern systeem. Juist omdat die verbinding echt werk kan raken, zijn afbakening, toestemming en bewijs belangrijk.
Wat MCP praktisch toevoegt
Volgens de officiële MCP-documentatie werkt de architectuur met hosts, clients en servers. De host is de AI-toepassing waarmee de gebruiker werkt. Een client onderhoudt binnen die host de verbinding met een MCP-server. De server stelt begrensde mogelijkheden beschikbaar, bijvoorbeeld een bron lezen of een concrete functie aanbieden.
Voor een bedrijf betekent dit dat niet iedere koppeling opnieuw op een geheel eigen manier hoeft te worden bedacht. Een toepassing kan beschikbare mogelijkheden ontdekken en gebruiken via een herkenbaar protocol. Dat helpt bij onderhoud en hergebruik, maar vervangt geen procesontwerp, toegangsbeheer of menselijke controle.
Een nuttige beschrijving van een koppeling bevat daarom ten minste:
- de toepassing en het bedrijfsaccount waarmee wordt verbonden;
- de gegevens die gelezen mogen worden;
- de acties die mogen worden voorbereid of uitgevoerd;
- de gebruiker of rol namens wie dat gebeurt;
- het moment waarop goedkeuring nodig is;
- het resultaat dat als bewijs wordt vastgelegd.
Verdeel de werkstroom in drie momenten
Een beheersbare workflow scheidt concept, goedkeuring en uitvoering.
1. Concept
De AI-toepassing leest alleen de noodzakelijke informatie en bereidt een voorstel voor. Dat kan een samenvatting, een vervolgtaak of een conceptbericht zijn. De status is dan “voorbereid”, niet “uitgevoerd”. De gebruiker moet kunnen zien welke bron en welke aannames zijn gebruikt.
2. Goedkeuring
Voor een actie met externe of klantimpact ziet de bevoegde persoon het definitieve voorstel: doelgroep, kanaal, inhoud, timing en gevolg. Een akkoord hoort bij precies die versie. Verandert de ontvanger, inhoud of scope, dan is opnieuw beoordelen logisch.
3. Uitvoering
Pas daarna gebruikt de koppeling de toegestane functie. Het systeem legt vast wat is aangevraagd en welk resultaat de externe toepassing teruggaf. Bij een fout blijft de status “niet bevestigd” of “mislukt”; een nette concepttekst is geen bewijs dat de actie is uitgevoerd.
Praktisch voorbeeld: een aanvraag naar een vervolgtaak
Stel dat een bedrijf aanvragen via een formulier ontvangt. Een MCP-verbinding geeft een assistent toegang tot de nieuwe aanvraag en tot een takenapp. De assistent herkent klantnaam, onderwerp en gewenste datum, en maakt eerst een concepttaak met een voorgestelde eigenaar.
Ontbreekt een locatie, dan markeert het systeem de aanvraag als onvolledig. Betreft het een spoedverzoek, dan wordt niet stilzwijgend een monteur ingepland; een planner krijgt een beslispunt. Na akkoord mag de koppeling de taak aanmaken. Het resultaat bevat vervolgens bijvoorbeeld het echte taak-ID uit de takenapp. Pas dan kan de workflow “taak aangemaakt” registreren.
Deze scheiding voorkomt dat een model op basis van onvolledige tekst meteen een onomkeerbare actie uitvoert. Zij maakt ook duidelijk waar een medewerker moet ingrijpen.
Een connectie is nog geen resultaat
Een geslaagde login of zichtbare connector bewijst alleen dat er op dat moment een verbinding kan bestaan. Het bewijst niet dat een specifieke taak is uitgevoerd. Zelfs een technisch succesvolle toolaanroep kan een concept, wachtrij-item of foutmelding opleveren.
Gebruik daarom verschillende bewijsniveaus:
- Verbonden: het juiste account is bereikbaar.
- Bevoegd: de benodigde beperkte actie is toegestaan.
- Aangevraagd: de concrete opdracht is verstuurd.
- Bevestigd: de doelapp geeft een uniek resultaat terug.
- Gecontroleerd: het resultaat is teruggelezen of zichtbaar op de bedoelde plek.
Voor publicatie is dit extra belangrijk. Een MCP-server die een publicatiefunctie aanbiedt, een succesmelding van een tussenlaag of een lokaal gegenereerde pagina is nog geen bewezen openbare publicatie. Daarvoor is ten minste een echte live URL en controle van de openbare pagina nodig. Hetzelfde principe geldt voor een agenda-afspraak, CRM-wijziging of verzonden bericht.
Rechten klein en zichtbaar houden
Geef een verbinding alleen toegang tot wat de workflow nodig heeft. Een assistent die taken leest, hoeft niet automatisch taken te verwijderen. Een koppeling die een concept maakt, hoeft niet direct te publiceren. Scheid lezen en schrijven waar dat kan, gebruik aparte bevoegdheden en trek ongebruikte toegang in.
De officiële beveiligingsdocumentatie van MCP benadrukt dat implementaties autorisatie en veiligheidsrisico’s zorgvuldig moeten behandelen. Het protocol neemt de bedrijfsverantwoordelijkheid dus niet over. De organisatie bepaalt welke server wordt vertrouwd, welke gegevens worden gedeeld en wie een actie mag bevestigen.
Checklist voor een controleerbare MCP-workflow
- [ ] De zakelijke taak is duidelijker omschreven dan “AI koppelen”.
- [ ] Account, gegevensbron en eigenaar zijn bekend.
- [ ] Lees- en schrijfrechten zijn minimaal ingesteld.
- [ ] Concept, goedkeuring en uitvoering hebben aparte statussen.
- [ ] Uitzonderingen en ontbrekende gegevens stoppen de route veilig.
- [ ] Een akkoord geldt voor één herkenbare actie en versie.
- [ ] Het doelsysteem levert een uniek uitvoeringsbewijs.
- [ ] De uitkomst wordt waar nodig teruggelezen.
- [ ] Fouten leiden niet automatisch tot dubbele uitvoering.
- [ ] Er is een route om toegang in te trekken en incidenten te onderzoeken.
MCP is daarmee geen garantie op automatisering, maar een bouwsteen voor een ordelijke verbinding. De waarde ontstaat wanneer techniek en werkafspraken samen één controleerbare keten vormen.
Bekijk MCP in een bedrijfsworkflow