Techniek · Handleiding

Je eerste WebMCP-tool testen: van lokale demo naar origin trial

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

In het kort

Begin met een alleen-lezen tool. Controleer achtereenvolgens API-toegang, registratie, uitvoering en gebruik door de beoogde agent. Een lokale testflag bewijst niet dat je publieke trialconfiguratie werkt.

Een kleine demo helpt om configuratiefouten van toolfouten te onderscheiden. Hieronder maak je een tool die een zichtbaar levertijdbericht teruggeeft. Het voorbeeld volgt de op 5 september 2026 gecontroleerde Chrome-documentatie en wijzigt geen gegevens.

1. Maak eerst een lokale proef

Gebruik een actuele Chrome-testversie waarvoor de WebMCP-documentatie geldt. Schakel voor lokaal onderzoek de optie bij chrome://flags/#enable-webmcp-testing in en herstart de browser. Serveer het onderstaande bestand via localhost. Dit is een lokale ontwikkelinstelling, geen instructie voor je eindgebruikers.

Bewaar dit volledige voorbeeld als webmcp-demo.html. De tekst is fictieve winkelinformatie; vervang hem bij een echte toepassing door gegevens uit dezelfde betrouwbare bron als je gewone interface.

html

<!doctype html>
<html lang="nl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>WebMCP: levertijd-demo</title>
</head>
<body>
  <h1>Levertijd</h1>
  <p id="delivery-window">Dit demoartikel wordt binnen 3 werkdagen verzonden.</p>
  <p id="tool-status" role="status">WebMCP wordt gecontroleerd.</p>
  <script type="module">
    const status = document.getElementById("tool-status");
    const context = document.modelContext;

    if (typeof context?.registerTool !== "function") {
      status.textContent = "WebMCP is hier niet beschikbaar. De informatie blijft leesbaar.";
    } else {
      try {
        await context.registerTool({
          name: "get_delivery_window",
          description: "Read the dispatch time shown for this demo product. Does not place an order.",
          inputSchema: { type: "object", properties: {} },
          annotations: { readOnlyHint: true },
          execute: () => document.getElementById("delivery-window").textContent.trim(),
        });
        status.textContent = "Tool geregistreerd: get_delivery_window.";
      } catch (error) {
        status.textContent = "De tool kon niet worden geregistreerd.";
        console.error(error);
      }
    }
  </script>
</body>
</html>

De fallback is bewust zichtbaar. Ontbreekt WebMCP, dan blijft de levertijd gewoon leesbaar. Een fout bij registratie verdwijnt ook niet stilzwijgend: je ziet een statusmelding en vindt de technische fout in de console.

2. Controleer registratie én uitvoering

Wacht op de melding dat de tool geregistreerd is. In een browser die de huidige discovery- en uitvoer-API ondersteunt, kun je vervolgens dit fragment in de DevTools-console uitvoeren. Het gebruikt de geregistreerde tool en een lege JSON-invoer, niet een los nagemaakte callback.

javascript

const context = document.modelContext;
if (typeof context?.getTools !== "function" ||
    typeof context?.executeTool !== "function") {
  throw new Error("Deze browser biedt de benodigde test-API niet aan.");
}
const registered = await context.getTools();
const deliveryTool = registered.find((tool) => tool.name === "get_delivery_window");
if (!deliveryTool) throw new Error("Levertijd-tool ontbreekt in de toollijst.");
console.log(await context.executeTool(deliveryTool, "{}"));

De verwachte uitkomst is exact het zichtbare levertijdbericht. Dit bewijst een technische uitvoering binnen deze testcontext. Het bewijst nog niet dat een taalmodel bij een klantvraag de juiste tool kiest.

3. Configureer de publieke trial apart

Voor een HTTPS-testsite registreer je de juiste origin via de WebMCP-origin-trialinformatie. Neem het echte token over in een Origin-Trial-responseheader of in een meta-element in de head, met http-equiv gelijk aan origin-trial en het token als content. Zet het op iedere pagina waar de functie nodig is, vóór de code die erop vertrouwt.

Controleer de exacte origin, geldigheidsduur en eventuele subdomeininstelling. Bekijk in DevTools bij Application de origin-trialstatus van het frame. Test daarna met de lokale WebMCP-flag uitgeschakeld; anders kan die een fout token maskeren. Herhaal de registratie- en uitvoeringstest.

4. Test de bedoelde agentclient

Vraag in de gekozen, ondersteunende client: ‘Wanneer wordt dit artikel verzonden?’ Controleer in de beschikbare uitvoertrace of de tool werkelijk is gebruikt en of het antwoord de juiste termijn noemt. De tekst staat ook op de pagina, dus een correct antwoord alleen bewijst geen WebMCP-gebruik.

Noteer browserbuild, client, trialstatus en resultaat. Test ten slotte zonder WebMCP: de informatie moet nog steeds toegankelijk zijn. Pas als deze kleine keten begrijpelijk werkt, is het zinvol een tool met klantgegevens of gevolgen te ontwerpen.

Bronnen

Deel dit artikelLinkedIn X