WebMCP-code bijwerken: controleer API-versie en toollevensduur

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

Een WebMCP-demo die ooit werkte, is geen betrouwbare installatiehandleiding voor iedere nieuwe browser. Tijdens de experimentele fase veranderen namen en gedrag. De nuttige migratievraag is daarom niet alleen of een methode bestaat, maar ook wanneer een tool beschikbaar hoort te zijn.

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 op 5 september 2026 gecontroleerde Chrome-handleiding toont document.modelContext.registerTool. Oudere voorbeelden kunnen navigator.modelContext gebruiken. Maar een bibliotheek kan daarnaast een eigen wrapper of compatibiliteitslaag aanbieden; vervang namen daarom niet blind in alle bestanden.

Maak bij de migratie een korte inventaris: native aanroep, wrapper of polyfill; geïnstalleerde pakketversie; browserbuild; gebruikte documentatie. Zoek vervolgens in je eigen code naar registratie én opruimlogica. Een geslaagde eerste paginalaadtest mist fouten die pas bij de tweede routewisseling ontstaan.

Koppel de registratie aan de juiste levensduur

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.