Welke WebMCP-tools moet je bouwen? Van klantdoel naar toetsbare toolset

Door E. Clein · Gepubliceerd 31 augustus 2026 · bijgewerkt 5 september 2026 · 3 min lezen

Een knop is gemakkelijk als tool na te bouwen. Moeilijker is bepalen welke tools samen een klant werkelijk helpen. Het nieuwe Chrome-kader geeft daarvoor een aanpak; wij werken die uit voor een fictieve laptopofferte.

Op 26 augustus 2026 publiceerde André Cipriani Bandarra van het Chrome-team een ontwerpkader voor WebMCP-tools. De aanpak begint bij het gebruikersdoel en de beginsituatie. Vervolgens speel je het gesprek na, ontwerp je herstel bij afwijkingen en evalueer je het gedrag. Dat geeft productowners en ontwikkelaars een gezamenlijk vertrekpunt voordat er code wordt geschreven.

Maak het resultaat specifieker dan ‘een offerte’

Ons fictieve bedrijf verkoopt zakelijke laptops. Een klant vraagt: ‘Ik heb volgende maand 25 laptops nodig voor medewerkers die veel reizen.’ Succes betekent hier dat een compleet offerteconcept ontstaat voor een passend model en aantal. Er wordt nog geen bestelling geplaatst en de leverancier ontvangt nog geen aanvraag.

Die grens beïnvloedt de toolset. Producten zoeken, beschikbaarheid controleren en een concept bewaren zijn verschillende handelingen. Een eventuele verzendactie komt pas later. Geef de agent dus geen algemene regel_bestelling-tool als het proces op dit moment alleen een concept mag opleveren.

Speel de ontbrekende informatie door

De klant heeft nog geen budget, concrete leverdatum of eisen aan het apparaat genoemd. Speel het gesprek met iemand van klantservice na. Welke vraag stellen zij eerst? Welke informatie staat al in het bedrijfsprofiel? Welke voorkeur blijkt pas relevant nadat geschikte modellen zijn gevonden?

Daaruit kan deze voorbeeldset ontstaan:

De tabel is geen universeel voorschrift. Als zoeken en leverbaarheid in jouw applicatie één betrouwbare bestaande handeling vormen, kan een gecombineerde tool handiger zijn. Kies de grens op basis van het klantdoel en de benodigde context, niet op basis van hoeveel endpoints je backend toevallig heeft.

Beschrijf één acceptatietest volledig

Een concrete test voor maak_offerteconcept kan als volgt luiden: gegeven een klant met toegang tot organisatie A, een bestaand product-ID en het opgegeven aantal 25, ontstaat één concept onder organisatie A. De samenvatting bevat precies dat product en aantal. De verzendstatus blijft ‘niet verstuurd’. Een onbekend product-ID levert geen concept op.

Voeg vervolgens een vrije klantopdracht toe waarin het aantal ontbreekt. Het gewenste agentgedrag is dat eerst het aantal wordt gevraagd. Alleen controleren of de tool met handmatig aangeleverde parameters werkt, toetst dat gedrag niet.

Maak fouten onderdeel van de route

Een uitverkocht model vraagt om alternatieven; een ontbrekende leverdatum vraagt om een vervolgvraag. Een onbereikbare voorraadservice vraagt om een statusmelding. Laat de tool die situaties onderscheidbaar teruggeven. Een algemene foutmelding laat mens en agent raden welke stap nog mogelijk is.

De uitkomst moet ook in de menselijke interface herkenbaar zijn. Als een concept bestaat, moet de klant het kunnen openen en controleren. Toon welke gegevens zijn gebruikt en welke nog onzeker zijn. Daarmee kan de gebruiker een verkeerde interpretatie corrigeren vóór de volgende actie.

Leg het gesprek, de toolgrenzen en de verwachte uitkomsten naast elkaar tijdens een review met product, klantservice en development. Als die drie beschrijvingen elkaar tegenspreken, is er nog ontwerpwerk nodig. Een goede eerste toolset maakt dat zichtbaar vóór een agent het probleem in productie tegenkomt.