WebMCP voor meertalige sites: behoud de betekenis van je toolbeschrijvingen

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

Een offerteconcept maken is iets anders dan een offerte versturen. Als dat onderscheid uit een vertaling verdwijnt, krijgt een agent een andere instructie over dezelfde klanttaak. Een nieuw internationalisatie-issue maakt deze ontwerpvraag concreet.

Op 1 september werd issue #276 geopend in de WebMCP-repository. De declaratieve API zet HTML-attributen zoals tooldescription en toolparamdescription om naar toolmetadata. Het issue vraagt hoe taal en tekstrichting tijdens die omzetting bepaald en bewaard worden. Het betreft een open specificatievraag; een wijziging in browsergedrag is daarmee nog niet vastgesteld.

Voor een ontwikkelteam is de aanleiding bruikbaar omdat toolteksten meerdere lezers kunnen hebben. Een agent gebruikt beschrijvingen om een actie te kiezen. Sommige metadata kan ook in een gebruikersinterface verschijnen. De taal op de pagina, de taal van de klantvraag en de taal waarin een tool is beschreven hoeven bovendien niet dezelfde te zijn.

Voorbeeld: wanneer is een offerte verstuurd?

De volgende vergelijking is een fictief voorbeeld van onze redactie. De Nederlandse brontekst beschrijft een concept. De korte Engelse vertaling verliest die grens; de laatste variant bewaart haar wel.

De oplossing begint bij een helder toolontwerp. Als een tool alleen concepten aanmaakt, benoem dat als zijn eigen actie. De toestemming om een andere, verzendende tool te gebruiken hoort niet uitsluitend in een vertaalde zin verstopt te zitten. De applicatie moet de bedoelde grens zelf afdwingen.

Leg betekenis vast voordat je vertaalt

Ons advies is om per tool één korte productspecificatie te beheren: doel, benodigde invoer, voorwaarden, uitkomst en eventuele neveneffecten. Gebruik die voor zowel interface- als toolteksten. Een vertaler kan dan zien dat deliveryDate de gewenste bezorgdatum is en niet de datum die de leverancier al heeft bevestigd.

Behandel ook eenheden en datums expliciet. Een klant die ‘volgende vrijdag’ zegt, levert geen vast tijdstip aan. De tool moet duidelijk maken of zij een kalenderdatum, tijdzone of tijdvenster verwacht. Wat je daarvan aan de agent meegeeft, volgt uit het contract van je eigen toepassing; een vertaling kan een onduidelijk contract niet repareren.

Kies een aanpak die je kunt testen

De Chrome-documentatie beschrijft zowel JavaScript-registratie als declaratieve formulierannotaties. JavaScript kan handig zijn wanneer je metadata al vanuit een vertaalcatalogus opbouwt. Een bestaand, goed vertaald formulier kan juist aanleiding zijn om de declaratieve route te onderzoeken. Dat is een praktische afweging, geen uitspraak dat één van beide routes het open internationalisatieprobleem al volledig oplost.

Test voor iedere ondersteunde taal dezelfde drie opdrachten: een gewone aanvraag, een opdracht met ontbrekende informatie en een opdracht die buiten de voorwaarden valt. Controleer toolkeuze, ingevulde waarden, zichtbare samenvatting en foutmelding. Een vertaald label kan kloppen terwijl de agent toch een andere datum of definitieve actie kiest.

Bewaar een compact overzicht van die tests bij je tooldefinitie. Wanneer een productvoorwaarde verandert, moet ook de vertaling én de verwachte uitkomst veranderen. De leerzame vraag is dus niet hoeveel strings vertaald zijn, maar of dezelfde klantopdracht in iedere taal dezelfde toegestane handeling oplevert.