WebMCP-code bijwerken: controleer API-versie en toollevensduur

Door Enrico Clein · Gepubliceerd 24 juni 2026 · laatst bijgewerkt 30 september 2026 · 5 min lezen

Je WebMCP-tool staat nog in de lijst, maar je testaanroep past niet meer bij de API. Chrome documenteert voor executeTool een overstap van JSON-tekst naar een JavaScript-object. Dit raakt eigen testcode en pagina-agents; niet automatisch iedere toolregistratie of CLI-opdracht.

Nieuw: object-invoer voor executeTool

De op 11 september 2026 bijgewerkte Chrome-handleiding toont object-invoer en noemt JSON-stringinvoer verouderd vanaf Chrome 155. De overeenkomstige Chromium-implementatie is op 10 september opgenomen. Dat is geen bewijs dat alle geïnstalleerde browsers of agentclients al zijn overgestapt.

De wijziging heeft een voorgeschiedenis: PR 246 introduceerde object-invoer op 17 augustus in de conceptspecificatie. PR 251, gemerged op 10 september, verfijnde de typecontrole. Het gaat dus om concrete API- en implementatiewijzigingen, niet alleen om een nieuwe datum boven het concept.

Bij een rechtstreekse aanroep is tool hieronder de bedoelde registratie uit getTools(). De tabel vergelijkt aanroepvormen; voer ze niet achter elkaar uit om te ontdekken welke werkt.

De conceptspecificatie is op 29 september verduidelijkt: laat je het tweede argument helemaal weg, dan ontvangt de tool een leeg object. Volgens de bespreking deden Chrome en de bijbehorende tests dit al; dit is dus geen aankondiging van nieuwe browserondersteuning. In voorbeelden blijft executeTool(tool, {}) een expliciete keuze voor een tool zonder invoervelden.

Dit gaat over de browsermethode document.modelContext.executeTool, niet over de execute-callback die je bij registratie opgeeft. Ook een CLI of bibliotheek kan een eigen invoerformaat houden. Verwijder daarom niet overal JSON.stringify; zoek eerst uit welke grens de invoer passeert.

Test de overgang zonder dubbele actie

Ons advies: gebruik een alleen-lezen testtool met een bekende uitkomst en leg de browserbuild vast. Test ook een getal als invoer en een object met een kringverwijzing: de nieuwe implementatie hoort die af te wijzen vóór de tooluitvoering. De bijbehorende Web Platform Tests, gemerged op 11 september, bevatten invoer- en serialisatiecontroles. We hebben deze browserimplementatie niet zelf uitgevoerd; dit advies steunt op documentatie, broncode en die tests.

Vang fouten af rond een aanroep met await, zodat ook een afgewezen promise wordt afgehandeld. Probeer bij een boeking niet automatisch eerst een object en na iedere fout JSON-tekst. De fout kan elders in de uitvoering zitten en een tweede poging kan een tweede actie veroorzaken. Kies de aanroepvorm vooraf voor je geteste runtime of compatibiliteitslaag.

Twee wijzigingen met verschillende datums

De specificatierepository legt de geschiedenis vast. PR 132, gemerged op 5 maart 2026, verwijderde provideContext en clearContext. PR 147, gemerged op 26 maart 2026, introduceerde AbortSignal voor registratie en verwijderde unregisterTool.

Dat zijn datums van wijzigingen in het voorstel, geen bewijs dat iedere browser op die dag omschakelde. Een uitleg die alleen ‘de nieuwe API’ zegt zonder versie of controledatum, laat precies die onzekerheid weg.

Controleer eerst welke laag je gebruikt

De Chrome-handleiding toont document.modelContext.registerTool. Oudere voorbeelden kunnen navigator.modelContext gebruiken. Een bibliotheek kan daarnaast een eigen wrapper aanbieden. Leg native aanroepen, pakketversies en browserbuild naast elkaar voordat je registratie- en opruimcode wijzigt.

Koppel de registratie aan de juiste levensduur

Een verduidelijking in de officiële WebMCP-repository, gemerged op 29 september, maakt onderscheid tussen de uitvoering en wat een agent over een tool te zien krijgt. Verandert alleen de achterliggende functie terwijl naam, beschrijving en invoerschema nog kloppen? Dan kan de geregistreerde execute-callback naar de actuele functie verwijzen; opnieuw registreren is daarvoor niet nodig. Verandert de belofte aan de agent — bijvoorbeeld omdat een productzoektool voortaan ook een verplicht land verwacht — dan moet je de oude registratie beëindigen en de bijgewerkte tool registreren. De huidige draft kent geen updateTool()-methode.

Bij zo'n wissel ontstaan toolchange-events waarop een client zijn toollijst kan verversen. Ga er niet van uit dat elke agent dat op tijd doet: test of de beoogde client het nieuwe schema werkelijk gebruikt. Controleer in execute ook opnieuw de actuele invoer, rechten en processtatus; de agent kan argumenten hebben gekozen vóór de wijziging. Dit is de praktische consequentie van de nieuwe uitleg, geen nieuwe garantie van de standaard.

Dit eigen, kleine voorbeeld registreert een alleen-lezen tool voor de paginatitel en geeft een opruimfunctie terug. Het is bewust gewone JavaScript: een frameworkcomponent kan dezelfde functie aanroepen bij het verschijnen en de teruggegeven functie bij het verdwijnen. Het voorbeeld doet geen netwerkaanvragen of mutaties.

async function registerPageTitleTool() {
  const context = document.modelContext;
  if (typeof context?.registerTool !== "function") {
    return () => {};
  }

  const controller = new AbortController();
  await context.registerTool({
    name: "get_page_title",
    description: "Read the title of the current page. Does not change data.",
    inputSchema: { type: "object", properties: {} },
    annotations: { readOnlyHint: true },
    execute: () => document.title,
  }, { signal: controller.signal });

  return () => controller.abort();
}

// Deze demo registreert en ruimt direct weer op.
// Koppel cleanup in je app aan het verdwijnen van de betreffende view.
try {
  const cleanup = await registerPageTitleTool();
  cleanup();
} catch (error) {
  console.error("Registratie van de paginatitel-tool mislukt", error);
}

De functie is asynchroon. Houd er in componentcode rekening mee dat de view al verdwenen kan zijn voordat de registratie klaar is: roep de ontvangen cleanup dan alsnog aan. Laat ook twee instanties niet ongecoördineerd dezelfde toolnaam registreren. Dat zijn applicatieproblemen die een nieuwe methodenaam niet oplost.

Opruimen is geen rollback

Het verwijderen van een registratie en het afbreken van een lopende uitvoering zijn verschillende gebeurtenissen. Chrome documenteert voor versie 153 een wijziging waarbij unregisteren lopende uitvoeringen niet meer afbreekt. Test het gedrag van jouw doelversie expliciet als een route tijdens een aanroep kan verdwijnen.

Geen van beide gebeurtenissen draait een al opgeslagen serverwijziging vanzelf terug. Een betaal- of boekingsflow heeft daarom een eigen controleerbare transactiestatus nodig, zoals uitgewerkt in onze timeout-uitleg.

De migratie is klaar na de tweede navigatie

Test ten minste: openen, registreren, uitvoeren, verlaten en terugkeren. Controleer daarbij de toollijst, dubbele namen, oude accountcontext en foutafhandeling. Noteer de geteste browserbuild bij de uitkomst. Zo lever je geen cosmetisch bijgewerkt codevoorbeeld op, maar een tool die alleen beschikbaar is waar zijn belofte klopt.