Je MCP-server op je website gebruiken: wanneer is een WebMCP-brug genoeg?

Door Enrico Clein · Gepubliceerd 28 september 2026 · 3 min lezen

Je hebt al een MCP-server voor je diensten. Moet je dezelfde tools opnieuw bouwen voor je website? Niet altijd. Een nieuwe brug laat zien hoe hergebruik werkt, maar ook waar het ophoudt: bij de actuele paginastatus, de gebruikerssessie en acties waarvoor iemand eerst akkoord moet geven.

Wat de brug daadwerkelijk doet

Vercel bracht op 18 september 2026 `mcp-handler` 2.2.0 uit met een experimentele WebMCP-brug. In de versiegebonden handleiding kies je met experimental_webMcp.tools welke bestaande MCP-tools de pagina mag aanbieden. Een script op die pagina haalt de toollijst op, registreert de gekozen tools bij de beschikbare modelContext-provider en stuurt aanroepen via fetch terug naar het MCP-endpoint. Dat is een concrete implementatie, geen nieuwe WebMCP-standaardregel.

De broncode op release 2.2.0 laat de grens zien: tools/list levert de namen en schema’s, de allowlist filtert ze en tools/call voert een gekozen tool op de server uit. Zonder WebMCP-provider doet het script niets. Registratie op de pagina bewijst nog niet dat de browseragent van je klant deze tools ontdekt of goed gebruikt; test die client apart.

Kies op basis van de benodigde context

Stel dat een serviceportaal al een MCP-tool heeft die de status van een aanvraag ophaalt. Als die tool met de ingelogde sessie een begrijpelijk resultaat teruggeeft, kan de brug een geschikte proef zijn. Een afspraak verzetten is anders: de gebruiker heeft misschien net een ander tijdslot geselecteerd en moet de gevolgen eerst zien. Een serveraanroep alleen werkt de zichtbare selectie of clientcache niet automatisch bij. Dat onderscheid maakt Vercel zelf in de documentatie. De voorbeelden hier zijn fictief; geen van beide portaalflows is door ons uitgevoerd.

Dit is een eigen besliskader, geen productgarantie. De brug registreert tools eenmaal bij het laden van het script en vernieuwt de lijst niet als de applicatietoestand verandert. Voor dynamische tools zoals een verzendknop die pas na validatie mag verschijnen, past een eigen paginatool beter. Dat sluit aan op ons eerdere voorbeeld van veranderende toolsets.

De sessie is niet vanzelf veilig geregeld

De brug gebruikt standaard credentials: "same-origin" voor de browseraanvragen. Daardoor *kunnen* cookies naar een endpoint op dezelfde origin meegaan. De server moet de sessie vervolgens werkelijk verifiëren en per tool de bevoegdheid, invoer en actuele toestand controleren. Vercel waarschuwt expliciet dat een endpoint met alleen bearer-tokenauthenticatie niet vanzelf met deze paginabrug werkt. Zet zo’n token niet in het gegenereerde script; ontwerp zo nodig een gecontroleerde sessie- of BFF-laag.

De allowlist bepaalt welke tools op de pagina verschijnen, maar beperkt de bestaande MCP-server niet voor zijn andere clients. Bovendien kan code die op de pagina draait een geregistreerde tool aanroepen met de rechten van de ingelogde gebruiker. Begin daarom bij voorkeur met een alleen-lezen functie en behandel een schrijvende tool als een gewone gevoelige formulieractie. Een hint als readOnlyHint is geen autorisatiecontrole. De handleiding noemt ook dat andere MCP-annotaties niet automatisch dezelfde betekenis krijgen in WebMCP.

Een proef die een echte beslissing oplevert

Neem één fictieve testaanvraag en twee testaccounts. Controleer eerst of de statustool in een ondersteunde browser verschijnt en of de beoogde agent haar daadwerkelijk aanroept. Vergelijk het antwoord met de serverstatus. Probeer daarna dezelfde aanvraag met het andere account en zonder geldige sessie: beide mogen geen gegevens prijsgeven. Verander ten slotte een veld op de pagina en kijk of de tool en het scherm nog dezelfde toestand beschrijven.

De projecttests van Vercel controleren onder meer het filteren van tools en het aanroepen van een lokaal MCP-endpoint met een nagebootste WebMCP-provider. Wij hebben de tests gelezen, niet zelf een browseragent of productieportaal getest. De uitkomst van jouw proef moet dus een keuze zijn, niet ‘de brug werkt overal’: welke serverfunctie kun je verantwoord hergebruiken, en welke klantstap vraagt om een eigen tool in de pagina?