Een WebMCP-tool zegt nee: maak van een weigering geen storing

Door E. Clein · Laatst bijgewerkt 14 september 2026 · 4 min lezen

Een medewerker past een offerte aan terwijl een agent nog over de vorige versie nadenkt. De agent probeert daarna zijn wijziging op te slaan. Als de tool dat terecht weigert, moet het antwoord niet alleen ‘mislukt’ zijn. Het moet duidelijk maken wat níét is gewijzigd en welke vervolgstap wel past.

Dit offertevoorbeeld is fictief, maar het onderliggende ontwerpvraagstuk is concreet. In de WebMCP-community beschrijven makers van Consequence en Redline hoe zij bewuste weigeringen onderscheiden van technische fouten. Op 11 september 2026 volgde voorstel #308 om informatie bij de overdracht van tool naar aanroeper beter te behouden. Het voorstel staat open; er is geen nieuw standaardformaat aangenomen.

Eerst het onderscheid: aanroep versus klantresultaat

Een tool kan normaal een antwoord teruggeven met daarin de boodschap dat niets is opgeslagen. Voor de aanroep is er dan een resultaat; voor de klant is de opdracht nog niet afgerond. Wie alleen controleert of een promise is voltooid, kan een weigering ten onrechte als succes tellen.

Het WebMCP-concept van 10 september onderscheidt een teruggegeven waarde van een afgewezen uitvoering. Bij de foutafhandeling van executeTool() komt een afwijzing echter als een algemene UnknownError bij de aanroeper terecht, zonder de oorspronkelijke weigeringsreden. Dit betreft de beschreven browser-API, geen vaststelling dat iedere agentclient fouten identiek presenteert.

Daarom is ‘gooi gewoon een fout’ niet altijd voldoende voor een bruikbare vervolgstap. De discussie bij #282 gaat juist over het behouden van het verschil tussen niet mogen en technisch stukgaan.

Wat een bestaande implementatie laat zien

Redline is een openbare editor voor het beoordelen en aanpassen van presentaties. De broncode van revisie 1a5652e retourneert onder meer OUT_OF_SCOPE bij bepaalde wijzigingen buiten de door de gebruiker gekozen selectie en STALE_READ als een eerder gelezen dia daarna is gewijzigd. Dat zijn eigen applicatiecodes, geen WebMCP-standaard.

De bijgeleverde tests controleren onder meer dat een handmatig aangepaste titel behouden blijft wanneer de agent met zijn oude informatie probeert te schrijven. Wij hebben broncode en tests beoordeeld, niet deze app of de browserintegratie uitgevoerd. Het voorbeeld toont een implementatiepatroon, geen bewijs van foutloze agentwerking.

Geef elke weigering een passende vervolgstap

Voor ons fictieve offerteproduct stellen we het volgende contract voor. De tabel is eigen ontwerpadvies, geïnspireerd door dat patroon.

Een geweigerde opslag kan in dit eigen contract bijvoorbeeld dit resultaat opleveren:

{
  "ok": false,
  "error": {
    "code": "STALE_VERSION",
    "message": "De offerte is gewijzigd. Jouw aanpassing is niet opgeslagen."
  },
  "nextStep": "Lees de actuele offerte en laat het verschil beoordelen."
}

Dit is een voorbeeld van de inhoud van een toolresultaat, geen complete registratie of universeel antwoordformaat. Je client moet deze velden daadwerkelijk interpreteren. Gebruik ‘niet opgeslagen’ uitsluitend wanneer je applicatie dat heeft vastgesteld. Bij een timeout kan de uitkomst juist onbekend zijn; daarvoor beschrijft onze timeout-uitleg een afzonderlijk herstelpad.

De melding beschermt niets zonder controle

Ons advies voor een serveropgeslagen offerte: controleer bevoegdheid en verwachte versie bij het opslaan zelf, samen met de wijziging. Alleen vooraf in de browser de versie lezen voorkomt geen gelijktijdige wijziging. Een nette foutcode vervangt die controle niet.

Ook opnieuw lezen is geen automatisch akkoord om de menselijke wijziging alsnog te overschrijven. Laat verschillen beoordelen wanneer ze de afgesproken opdracht veranderen. Een veld als retrySafe is een applicatiehint, geen nieuwe toestemming.

Test juist de route waarin niets hoort te gebeuren

Laat in een oefenomgeving de agent versie 4 lezen, wijzig de offerte daarna naar versie 5 en probeer de oude wijziging op te slaan. Controleer drie uitkomsten: versie 5 blijft intact, het toolresultaat benoemt de weigering en de agent meldt niet ‘opgeslagen’. Herhaal met een wijziging buiten de opdracht en controleer dat geen alternatieve schrijvende tool de grens omzeilt.

De concrete les: tel afgeronde klantresultaten, bewuste weigeringen en technische fouten apart. Soms is een correct uitgevoerde tool juist de tool die niets verandert — en helder uitlegt waarom.