MCP voor website-chatbots: Tools koppelen met OAuth en goedkeuringen

MCP maakt website-chatbots daadkrachtiger - maar alleen met duidelijke grenzen

MCP voor AI-chatbots is geen magische stekker die een website-chatbot plotseling zomaar aan willekeurige systemen toevertrouwt. Het Model Context Protocol beschrijft eerder een gemeenschappelijke interface waarmee een model tools kan ontdekken en aanroepen: bijvoorbeeld een zoekopdracht in een kennisbank, een ticket-query, afspraaklogica of een interne controle van productgegevens. Vooral voor website-chatbots is dit aantrekkelijk, omdat veel gesprekken niet eindigen bij één antwoord. Bezoekers vragen naar de leveringsstatus, prijzen, contactmogelijkheden, formulieren, beschikbaarheid of vervolgstappen. Zonder tools kan de bot alleen dingen uitleggen. Met tools kan hij, gecontroleerd en navolgbaar, relevante gegevens ophalen of voorbereide acties in gang zetten.

De doorslaggevende vraag is daarom niet: kan een chatbot tools gebruiken? De vraag is: welke tools mag hij in welke context zien, met welk token aanroepen, met welke menselijke goedkeuring uitvoeren en met welke logbestanden achteraf verantwoorden? De definitieve MCP-specificatie van 28 juli 2026 scherpt precies deze operationele vragen aan. Het maakt de kern stateless, vereist relevante metadata per request en verduidelijkt hoe remote HTTP-autorisatie, OAuth, scopes en token-audience-binding met elkaar samenhangen.

Wat de 2026-07-28-specificatie verandert voor website-teams

De belangrijkste architectuurverandering is de stateless core. Een MCP-server mag er niet van uitgaan dat eerdere requests op dezelfde verbinding al context, client-capabilities of een sessie hebben opgebouwd. Alles wat nodig is voor de verwerking, moet in de huidige request staan. Voor gedistribueerde website-infrastructuur is dat praktisch: requests kunnen achter load balancers, edge-gateways of worker-platformen op verschillende instanties terechtkomen. Voor implementaties betekent het echter ook: geen verborgen aannames over transport-sessies, geen stille rechten uit een vorige verbinding en geen chatgesprek als veiligheidsgrens.

Elke aanvraag heeft de vereiste _meta-metadata nodig. Daartoe behoren in het bijzonder de protocolversie en de client-capabilities; client-informatie is nuttig voor weergave, logging en debugging, maar niet geschikt als veiligheidsbewijs. Als een website meerdere bot-instanties, talen of klantomgevingen bedient, moet deze metadatalaag bewust worden gevalideerd en gelogd. Het vervangt de functionele autorisatie niet, maar zorgt er wel voor dat de server requests correct kan plaatsen.

Tool-lijsten zijn dynamisch, maar niet willekeurig

tools/list is in de huidige specificatie gepagineerd en cachebaar. Antwoorden kunnen cache-hints bevatten zoals ttlMs en cacheScope. Tegelijkertijd moet de volgorde deterministisch blijven, zolang de onderliggende set tools niet verandert. Dat is meer dan alleen cosmetische performance: als tool-catalogi stabiel gesorteerd zijn, kunnen clients ze betrouwbaarder cachen en blijven model-contexten rustiger.

Belangrijk is de nuance bij autorisatie. De verzameling tools mag per request variëren op basis van de getoonde autorisatie, bijvoorbeeld omdat een token alleen leesrechten op supportgegevens geeft, maar geen schrijfrechten op een CRM. Het mag echter niet willekeurig schommelen als neveneffect van eerdere requests op dezelfde verbinding. Voor website-chatbots levert dit een helder patroon op: de zichtbare tool-catalogus ontstaat uit de rol, scope, tenant, taal, context en het risico van het huidige request.

Tool-beschrijvingen zijn geen vertrouwensbasis

MCP-tools beschrijven hun naam, hun invoer, optioneel uitvoer en annotaties. Deze metadata helpen het model en de gebruikersinterface om de functie te begrijpen. Ze vormen echter geen veiligheidsanker. De specificatie stelt duidelijk dat clients tool-annotaties als onbetrouwbaar moeten behandelen, tenzij ze afkomstig zijn van vertrouwde servers. Een tool die zichzelf als alleen-lezen beschrijft, moet aan de serverzijde toch zo zijn gebouwd dat hij geen schrijf-neveneffecten uitvoert.

Dat geldt ook voor gestructureerde resultaten. Een outputSchema helpt om antwoorden te valideren en niet alleen vrije tekst aan het model te geven. Desondanks moeten servers invoer controleren, toegang beheren, rate limits instellen en uitvoer opschonen. Een website-chatbot moet tool-resultaten niet ongefilterd overnemen in zichtbare antwoorden, vooral niet als er externe API's, klantgegevens of HTML-gerelateerde inhoud bij betrokken zijn.

OAuth: De MCP-server is een beschermde bron

Bij remote HTTP MCP is de rolverdeling van essentieel belang. Een beschermde MCP-server fungeert als OAuth Resource Server. De MCP-client handelt namens een Resource Owner, dus typisch een gebruiker of een organisatie. De Authorization Server communiceert met de gebruiker, indien nodig, en geeft access tokens uit. De MCP-server moet zijn Protected Resource Metadata beschikbaar stellen, zodat clients de juiste Authorization Server kunnen ontdekken. De Authorization Server biedt ten minste één van de discovery-methoden aan: OAuth Authorization Server Metadata of OpenID Connect Discovery; de MCP-client moet beide ondersteunen.

Voor productteams betekent dit: de chatbot moet niet zelf wachtwoorden, API-keys of tokens van derden beheren als er een OAuth-flow is voorzien. Hij moet de gebruiker naar een duidelijke goedkeuring leiden, daarna een doelgebonden access token gebruiken en de daarmee toegestane tools zichtbaar beperken. Voor client-registratie hebben Client ID Metadata Documents de voorkeur; Dynamic Client Registration blijft alleen omwille van achterwaartse compatibiliteit behouden en is deprecated. Zeker bij integraties zoals agenda's, CRM, helpdesk, documentopslag of webshops is deze scheiding belangrijk, omdat hetzelfde gesprek vaak wisselt tussen openbare vragen en accountgebonden acties.

Tokens moeten gebonden zijn aan de doelbron

De huidige autorisatiespecificatie vereist Resource Indicators volgens RFC 8707. De client moet in autorisatie- en token-requests de resource-parameter instellen en daarmee de canonieke URI opgeven van de MCP-server waarvoor het token bedoeld is. De MCP-server moet controleren of het access token precies voor zijn resource is uitgegeven. Tokens mogen niet via query-strings worden verzonden, maar horen thuis in de Authorization Header.

Deze audience-binding voorkomt een gevaarlijke afsnijdingsroute: een token dat bedoeld is voor dienst A mag niet worden geaccepteerd of doorgegeven bij dienst B. Website-chatbots hebben daarom een schone token-grens nodig per MCP-server en per omgeving. Preview, staging en production moeten niet dezelfde audience gebruiken als ze verschillende resources vertegenwoordigen. Evenzo moet een aggregator die meerdere MCP-servers voor één model samenbrengt, geen tokens door elkaar halen.

Scopes zijn een UX- en veiligheidscontract

Scopes moeten klein beginnen. De specificatie raadt aan om scope-hints uit WWW-Authenticate-challenges te gebruiken en bij ontbrekende rechten een step-up-flow toe te staan. In de praktijk betekent dit: een bezoeker kan eerst werken met lees-tools. Pas wanneer een actie meer rechten vereist, zoals het aanmaken van een ticket, het schrijven van een bestand of het voorbereiden van een bestelling, vraagt het systeem gericht om de aanvullende goedkeuring.

Een goed consent-ontwerp noemt niet alleen de naam van de integratie, maar ook het effect: welke gegevens worden gelezen? Welke actie wordt voorbereid? Wordt er extern iets opgeslagen, verzonden of permanent gewijzigd? Voor gevoelige operaties moet de gebruiker een echte bevestiging zien en deze kunnen weigeren. Dit is geen individueel juridisch advies, maar een technische ontwerpregel: goedkeuringen moeten begrijpelijk zijn voor mensen, afdwingbaar voor servers en navolgbaar voor audits.

Een robuuste architectuur voor website-chatbots met MCP

Een robuuste architectuur scheidt het model, de tool-façade en de doelsystemen. De website-chatbot spreekt niet rechtstreeks met elke externe leverancier, maar met een MCP-client of gateway die de protocolversie, client-capabilities, auth-status, rate limits en observabiliteit controleert. Daarachter liggen MCP-servers voor afzonderlijke integraties of functionele domeinen. Elke server declareert alleen de tools die voor het huidige request zijn toegestaan en valideert elke aanroep opnieuw.

De tool-façade moet stabiele namen, strikte invoerschema's en duidelijke uitvoerschema's gebruiken. Tool-namen moeten uniek genoeg zijn, vooral als meerdere servers soortgelijke functies zoals search, create of lookup aanbieden. Bij aggregatie helpt een namespace of voorvoegsel. Parameters moeten zo worden ontworpen dat het model geen geheime ruwe gegevens hoeft te verzinnen. Als een proces over meerdere requests loopt, moet de server een expliciete, kortstondige handle retourneren en deze bij elke vervolgaanroep opnieuw autoriseren.

Een tweede bouwsteen is de gebruikersinterface. Bezoekers moeten kunnen zien wanneer een tool wordt aangeroepen, welke invoer wordt verzonden en wanneer een goedkeuring nodig is. Voor louter leesacties volstaat vaak een transparante status. Voor schrijvende, betaalde, externe of persoonsgebonden acties is een bewustere bevestiging nodig. De specificatie laat interfacepatronen open, maar eist wel duidelijk dat toepassingen menselijke controle over tool-calls mogelijk moeten maken.

Rollout-checklists voor MCP bij AI-chatbots

1. Tool-inventarisatie maken: Welke systemen moeten worden gekoppeld, welke tools zijn alleen-lezen, welke veranderen gegevens en welke vereisen menselijke bevestiging?
2. Scopes definiëren: Snijd rechten op basis van acties, niet op basis van interne teams. Een tool voor statusvragen heeft andere scopes nodig dan een tool voor het aanmaken, wijzigen of verzenden.
3. OAuth-discovery testen: Test Protected Resource Metadata, Authorization Server Metadata, client-registratie en redirect-URI's per omgeving.
4. Audience-binding afdwingen: Accepteer tokens alleen voor de canonieke MCP-server-URI, geef ze nooit door aan verkeerde resources en plaats ze nooit in URL's.
5. tools/list deterministisch maken: Test stabiele sortering, paginering, cache-hints en autorisatiefilters samen.
6. Schema's strikt houden: Valideer invoer, gebruik gestructureerde uitvoer en schakel het automatisch laden via het netwerk van externe $ref-doelen standaard uit; optioneel alleen met een allowlist, timeout, groottelimiet en logging.
7. Goedkeuringen bouwen in de UI: Maak tool-naam, doel, invoer, doelsysteem, scope-upgrade en de optie om te weigeren zichtbaar.
8. Observabiliteit verankeren: Log request-ID, tool-naam, scope, beslissing, fouten, latentie en resultaatrij, zonder gevoelige inhoud onnodig op te slaan.
9. Foutpaden oefenen: Behandel 401, 403, verlopen tokens, ontbrekende scopes, onbekende handles, timeouts en geweigerde goedkeuringen als normale productstatussen.
10. Klein beginnen: Neem eerst een of twee risicoarme lees-tools live, en voeg vervolgens stapsgewijs step-ups, schrijfacties en verdere integraties toe.

Veelvoorkomende fouten bij de implementatie

De meest gemaakte fout is een te breed eerste token. Als een website-chatbot na de eerste aanmelding meteen uitgebreide schrijfrechten krijgt, wordt elke beslissing van het model risicovoller. Beter is een minimale start-scope met een gerichte step-up. De tweede fout is een tool-catalogus die bestaat uit interne systeemnamen in plaats van gebruikersintenties. Een model werkt betrouwbaarder met duidelijke, nauwkeurig omschreven acties dan met generieke multifunctionele eindpunten.

De derde fout is het ontbreken van scheiding tussen modelvertrouwen en serververtrouwen. Het model mag een actie voorstellen, maar de server beslist of de invoer geldig is, of het token klopt en of er een goedkeuring is. De vierde fout is een gebrek aan traceerbaarheid. Als later onduidelijk is welke tool met welke scope welke gegevens heeft gelezen of gewijzigd, kunnen noch support noch beveiliging naar behoren functioneren.

Verdere verdieping

Dit artikel behandelt de MCP-integratielaag: stateless core, tools/list en HTTP-OAuth. De volgende artikelen gaan dieper in op algemene tool-beveiliging en beheer: Voor het rechtenmodel sluit AI-chatbots: Tools veilig gebruiken met rechten en bevestigingen aan. Voor concrete tool-calls is AI-chatbot tool-calls veilig ontwerpen de moeite waard. Als tool-resultaten machineleesbaar moeten blijven, past Gestructureerde AI-chatbot-uitvoer valideren. Voor beheer en probleemoplossing is AI-chatbot observabiliteit voor traces, retrieval en tools het technische vervolg.

Officiële bronnen

De inhoudelijke basis is de definitieve MCP-specificatie 2026-07-28: de pagina over MCP Tools, de MCP Authorization, het officiële artikel The 2026-07-28 Specification en de Base Protocol Overview.

Conclusie

MCP voor AI-chatbots wordt waardevol wanneer website-teams het niet zien als een open gereedschapskist, maar als een gecontroleerde integratielaag. De 2026-07-28-specificatie sluit goed aan bij moderne web-infrastructuur: stateless requests, cachebare lijsten, routeerbare HTTP-headers en expliciete autorisatie per resource. Tegelijkertijd maakt het de verantwoordelijkheid duidelijker. Tool-aanbod moet passen bij het huidige token, gevoelige operaties vereisen menselijke controle en elke aanroep moet aan de serverzijde worden gevalideerd.

Een pragmatische start is klein: één lees-tool, een krappe scope, een duidelijke consent-tekst, deterministische tool-discovery en goede logboeken. Daarna kunnen verdere tools worden aangesloten zonder dat de chatbot een black box wordt. Zo verandert een website-chatbot niet in een ongecontroleerde agent, maar in een navolgbare assistent die precies die systemen mag gebruiken die voor de huidige gebruiker en de huidige taak zijn vrijgegeven.