WebMCP i oktober 2026: sådan gør man et website brugbart for AI-agenter, og hvad origin trial reelt betyder

WebMCP lader en webside give en AI-agent en kort liste over, hvad den kan gøre, hver med et navn, en beskrivelse og et inputskema, i stedet for at lade agenten regne siden ud ud fra skærmbilleder og DOM'en. En agent, der finder et værktøj ved navn check_order_status, kan kalde det med et ordrenummer. Uden det må agenten selv finde det rigtige felt og klikke på den rigtige knap.

Det er løftet. Status pr. 22. oktober 2026 er snævrere, end de fleste artikler om emnet giver indtryk af. WebMCP er et forslag fra en W3C Community Group, ikke en standard. Chrome kører det som origin trial, uden at der er truffet beslutning om at udgive det. Én forbrugeragent kalder værktøjerne (den browser, der er indbygget i ChatGPT-desktopappen), og den agent ignorerer den deklarative formularversion, som blev fjernet fra specifikationen den 8. oktober. Safaris motorteam er imod forslaget; Mozilla er neutral.

Artiklen er til udviklere og produktejere, der skal afgøre, om de skal tilføje WebMCP nu. Den gennemgår, hvad API'et er, hvem der kalder det, hvordan man slår det til for rigtige besøgende, hvordan man skriver værktøjer, der ikke stikker en agent en ladt pistol i hånden, og hvad man bør rette først, hvis agenter overhovedet skal kunne bruge jeres website.

Hvad WebMCP er

Specifikationen definerer et JavaScript-API på document.modelContext, som en webside registrerer værktøjer igennem: »WebMCP API'et gør det muligt for webapplikationer at stille JavaScript-baserede værktøjer til rådighed for AI-agenter.« Et værktøj har et name, en description og en execute-callback og eventuelt en title, et inputSchema (JSON Schema) og annotations. Sidens egen kode kører, når agenten kalder værktøjet, med brugerens session.

Tre ting ved det er nemme at tage fejl af:

• Det er ikke en standard. Dokumentet er en Draft Community Group Report fra Web Machine Learning Community Group og siger det selv: »Det er ikke en W3C-standard, og det er heller ikke på W3C's standardspor.« Chromes egen dokumentation kalder det »en foreslået webstandard«. Rapportens dato har ændret sig med få dages mellemrum i oktober; redaktørerne kommer fra Microsoft og Google.
• Der er ingen MCP i det. Specifikationen siger, at sider, der bruger det, »kan opfattes som Model Context Protocol-servere, der implementerer værktøjer i script på klientsiden«, og derefter, at den »ikke foreskriver, i hvilket format værktøjerne eksponeres over for browseragenten«. Mozillas vurdering sagde det ligeud: »Navnet er misvisende ... Der er ingen MCP her.« Et WebMCP-værktøj forbinder ikke til jeres MCP-server i backend, og det erstatter den ikke.
• Det gør jer ikke synlige. Chromes dokumentation anfører selv begrænsningen: »Klienter og browsere skal besøge et website direkte for at vide, om det har værktøjer, der kan kaldes.« WebMCP hjælper en agent, der allerede er på jeres side. Det gør intet for at blive fundet.

API'et er begrænset til sikre kontekster og styres af en Permissions Policy ved navn tools, hvis standardliste over tilladte er 'self', så en iframe fra en anden origin ikke kan registrere værktøjer, medmindre den side, der indlejrer den, tillader det.

Status pr. 22. oktober 2026

Chrome 156, den sidste version i den oprindelige trialperiode, nåede den stabile kanal den 20. oktober 2026. Chrome 162, hvor den ansøgte forlængelse slutter, er planlagt til stabil den 2. februar 2027. Om forlængelsen er aktiv, kunne ikke bekræftes fra trialkonsollen, så planlæg ud fra, at den sandsynligvis er det, men ikke med sikkerhed.

Forlængelsesanmodningen forklarer, hvorfor Chrome vil have mere tid: »Feedback fra OT har peget på forbedringer af API'et, som vi er i gang med at implementere.« I samme tråd skrev Googles Dominic Farolino, at teamet »håber at gå videre til I2S inden for forlængelsesperioden«, altså at anmode om at udgive det, og at »det imperative API er langt mere populært end det deklarative, så vi investerer mere i det som svar på brugernes behov.« Han nævnte også et continuation-API, et API for værktøjsstabilitet og grænser for værktøjers størrelse, som er under prototypeudvikling. Det API, I skriver mod i dag, kommer til at ændre sig.

Hvem kalder egentlig værktøjerne

At registrere værktøjer kræver intet. At bruge dem kræver en agent, og listen over agenter er kort.

Chromes egne testudvidelser. Chromes dokumentation tilbyder to udvidelser, blandt dem Model Context Tool Inspector, til at prøve værktøjer af i demoer og på jeres egne sider. De kræver jeres egen API-nøgle til en model, og Chrome bemærker: »Disse udvidelser er adskilt fra Gemini i Chrome.« Det er udviklerværktøjer, ikke kunder.

ChatGPT's indbyggede browser. Et opslag fra en medarbejder hos OpenAI i udviklerforummet sagde den 25. august 2026, at »Site tools er ChatGPT's implementering af den foreslåede WebMCP-standard.« Dokumentationen stiller betingelser: bestemte modeller, den nyeste desktopapp, en administrator, der tillader det i Enterprise-workspaces, ingen Edu-workspaces, og »Tilgængelighed afhænger også af udrulningen«. Den oplister også, hvad der ikke understøttes: »Deklarativt API: Værktøjer defineret med HTML-formularattributter er ikke tilgængelige som site tools«, og værktøjer registreret i iframes, også dem fra samme origin. OpenAI's anvisning er klar: »Brug JavaScript til at registrere værktøjer på siden på øverste niveau«. Dokumentationen siger ikke, om en side skal have et origin trial-token fra Chrome, for at ChatGPT kan se dens værktøjer.

Gemini i Chrome. Google sagde i maj, at det »vil snart understøtte WebMCP API'er«. Vi har ikke fundet nogen primærkilde siden, der siger, at det gør det. Byg ikke en plan på det endnu.

Alle andre falder tilbage. Alle agenter i alle browsere læser stadig sider på den gamle måde. Chrome siger det selv i sin egen risikovurdering: »Browseragenter i Chrome kan fortsat betjene websites som hidtil ved at simulere brugeradfærd.« OpenAI: »Hvis der ikke findes et passende værktøj, kan agenten stadig være i stand til at bruge sine almindelige browserfunktioner.« Et website uden WebMCP er ikke usynligt for agenter. Et website med ødelagte knapper og felter uden labels er svært for dem alle.

Det imperative API

Det er den version, specifikationen definerer, den ChatGPT understøtter, og den Chrome siger, at udviklerne foretrækker. Et værktøj omslutter logik, som siden allerede har. Her er et skrivebeskyttet opslag for en logget ind kunde, efter mønster fra Chromes dokumentation og OpenAI's featuredetektering:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

Det vigtigste i det:

• Navn, beskrivelse og skema er det, modellen læser. Chrome anbefaler højst 500 tegn pr. værktøjsbeskrivelse, 150 pr. parameterbeskrivelse, 30 pr. værktøjs- og parameternavn og 1,5K tegn pr. værktøjsoutput og bemærker, at »disse anbefalinger kan ændre sig«. Specifikationens explainer advarer: »At eksponere for mange værktøjer (f.eks. dusinvis eller hundredvis) kan forringe agentens ydeevne alvorligt«: Registrer det, sidens aktuelle tilstand har brug for, og fjern resten med AbortController-signalet.
• Det andet argument til execute bærer et AbortSignal, så et annulleret kald kan stoppe en forespørgsel undervejs.
• Annotationer er hints. readOnlyHint markerer et opslag. consequentialHint markerer alt, der booker, køber, sender, sletter eller overfører, og Chromes dokumentation siger, at det »giver agenter og browsere mulighed for at gennemtvinge obligatoriske bekræftelsesdialoger over for brugeren«. untrustedContentHint markerer output, der indeholder anmeldelser, brugerindhold eller data fra tredjeparter. En debugging-annotation findes fra Chrome 156.
• Sidens kode kan også liste og køre værktøjer, med document.modelContext.getTools() og executeTool(), og en toolchange-hændelse udløses, når listen ændrer sig. Argumenter som JSON-streng til executeTool() er forældede fra Chrome 155.

React, Angular og Vue har hver især eksperimentelle hjælpere, og npm-pakken webmcp-types leverer TypeScript-typer. Ældre vejledninger, der kalder navigator.modelContext, er forældede: Specifikationen flyttede API'et til document den 27. maj 2026.

Det deklarative API: i Chromes trial, ude af specifikationen

Den deklarative version gør en eksisterende HTML-formular til et værktøj med to attributter. Den er attraktiv for gamle, formularstyrede sites, fordi intet andet behøver at ændre sig:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

I Chromes trial gælder: »Når en agent kalder toolname, sætter browseren fokus på formularen og udfylder dens felt. Formularen forbliver synlig for brugeren.« Browseren bygger parametrene ud fra kontrollerne: deres navne, deres <label>, required og et <select>s valgmuligheder. Medmindre formularen har toolautosubmit, »skal brugeren selv klikke på Send for at gennemføre opgaven«, hvilket er det, I vil have på alt, der afgiver en ordre eller sender en lead. SubmitEvent.agentInvoked fortæller jeres handler, at en agent har udfyldt formularen, og respondWith(), efter preventDefault(), returnerer udfaldet til agenten. Lyt efter hændelserne toolactivated og toolcancel på document.modelContext med addEventListener: window.ontoolactivated og window.ontoolcancel understøttes ikke fra Chrome 156.

Hagen er dens status. Explainerens seneste ændring, den 8. oktober 2026, hedder »Remove declarative API from the spec for now« og lyder nu, at en deklarativ pendant »undersøges separat ... men ikke er en del af specifikationen på nuværende tidspunkt.« ChatGPT understøtter den ikke. Chrome dokumenterer den stadig i trialen, og Googles Farolino argumenterede i Mozillas tråd for, at »vi ser værdi i det deklarative forslag alene for ældre websites, især formularbaserede«. Opfat det som et Chrome-eksperiment inde i et eksperiment: fint at prøve, uklogt som jeres eneste vej.

Sådan slår man det til for rigtige besøgende

Et flag (chrome://flags/#enable-webmcp-testing) slår WebMCP til i jeres egen browser til test. Det gør intet for besøgende. For dem skal siden have et origin trial-token.

1. Registrér jeres origin på Chromes side for WebMCP-trialen. Origin trials »er offentlige og åbne for alle udviklere«, og et token »slår en funktion til for alle brugere på jeres origin«.
2. Server tokenet på hver side, der skal eksponere værktøjer, som <meta http-equiv="origin-trial" content="..."> i <head> eller som en Origin-Trial:-svarheader. Et token kan også indsættes fra script. Ét token dækker én origin; en side kan have flere.
3. Forny det. Når en trial forlænges, beder Chrome registranter om at »angive et nyt token for hver origin, der er tilmeldt trialen«, og »Chrome ignorerer ugyldige eller udløbne tokens«. Et udløbet token fejler lydløst: Værktøjerne holder simpelthen op med at dukke op.
4. For Edge skal I registrere jer separat på Edges trialside. Vilkårene beder om, at »I, hvor det er muligt, indvilliger i at anvende featuredetektering / graceful degradation«.

Lighthouses WebMCP-audits kræver også trialregistreringen, så et site, der tester dem uden token, vil se dem fejle.

Sådan skriver man værktøjer, der er sikre at kalde

Specifikationens sikkerhedsafsnit er ikke normativt, og det er åbent om, hvor byrden ligger: At forhindre, at en agent bliver manipuleret, er »primært agentens egen sikkerhedsmodels ansvar snarere end noget, denne specifikation normativt kan håndhæve.« Jeres værktøjer afgør stadig, hvor stor skade en manipuleret agent kan gøre.

• Hints kan lyve, så agenter stoler ikke på dem. Specifikationen: »et ondsindet website kan udelade eller fejlrepræsentere disse hints.« OpenAI: »Et værktøjs navn eller påstand om, at det kun læser data, er ikke bevis for, hvad det gør«, og hvert kald i dens browser gennemgår en sikkerhedsvurdering, med bekræftelse stadig påkrævet ved køb og lignende handlinger. Annotér alligevel ærligt. Det er det, en omhyggelig agent bruger til at afgøre, hvornår den skal spørge brugeren.
• Beskriv virkninger præcist. Specifikationens eget dårlige eksempel er et værktøj beskrevet som »Afslutter den aktuelle indkøbskurv«, der »i virkeligheden udløser et køb. Brugeren havde ikke tænkt sig at købe noget.« Hvis et værktøj trækker penge på et kort, siger beskrivelsen det, og consequentialHint er true.
• Autorisér på serveren, hver gang. Værktøjet kører med brugerens session: Specifikationen bemærker, at »agenter kan arve brugerens identitet og autentificeringskontekst fra browseren.« Et værktøjskald er en forespørgsel fra den bruger og får de samme kontroller. Explainerens råd gælder: »Valider strengt i kode, løst i skema«, fordi strenge skemafejl kan få agenter til at gå i stå.
• Forbered jer på prompt injection. Specifikationen nævner det først, i tre former: instruktioner skjult i værktøjets metadata, i værktøjets output og angreb, der bruger værktøjer som mål. Output, der indeholder tekst skrevet af andre (anmeldelser, beskeder, spørgsmål om produkter), hører under untrustedContentHint og bør returneres som data frem for som prosa, en agent kan tage for instruktioner.
• Meld sider ud med vilje. En Permissions-Policy: tools=()-header gør API'et utilgængeligt for et dokument og alt, det indlejrer. Kontoindstillinger, betalingssider og administrationsskærme er kandidater.

Et forbehold om Chromes dokumentation: Dens sikkerhedsside siger, at udkastet indeholder en requestUserInteraction()-metode til at spørge brugeren midt i et værktøj. Udkastet til specifikationen fra den 20. oktober 2026 har ingen sådan metode, og explaineren anfører stadig brugerbekræftelse som et åbent spørgsmål. Design ikke omkring den.

Hvad Safaris og Firefox' ingeniører har indvendinger imod

Indvendingerne er værd at læse, selv om I kun bygger til Chrome, fordi de beskriver, hvordan WebMCP kan gå galt i praksis.

WebKits holdning, der blev offentliggjort den 3. juni 2026, argumenterer for, at sider, der er svære at bruge, bør rettes i HTML og ARIA, »hvor brugeren, hjælpeteknologi og agenter alle har gavn«, og at med værktøjer »flytter skrøbeligheden bare fra DOM'en ind i værktøjsbeskrivelserne.« Den ser en agent som hjælpeteknologi, der ikke bør udpeges: »WebMCP gør det modsatte og gør ›en agent styrer‹ til et observerbart faktum.« Og den bemærker, at forslaget »ikke har nogen model for samtykke eller reversibilitet ved handlinger med konsekvenser«.

Mozilla endte på neutral i august: WebMCP »indfører en potentielt værdifuld abstraktion«, men »åbner en flade, hvis dynamik i den virkelige verden efterlader for mange åbne spørgsmål til, at man kan bakke det helhjertet op«. Mozilla advarer om, at sites kunne »tilbyde værktøjer, der ikke svarer til oplevelsen for en bruger på siden«, for eksempel for at »levere prompt injection, der er usynlig for typiske brugere«. Enkelte Mozilla-ingeniører har vist interesse for en imperativ function calling-primitiv; det er ikke en opbakning fra Mozilla.

Chrome vurderer selv risikoen for, at andre motorer ikke tager WebMCP til sig, som lav for brugerne. Bagsiden af det er, at et website ikke får noget ud af at tilføje værktøjer i Safari eller Firefox i dag.

Det, der virker for alle agenter i dag

Alle browseragenter læser skærmbilleder, HTML og tilgængelighedstræet. Googles vejledning på web.dev om agentvenlige sites siger, at agenter »bruger DOM'en og tilgængelighedstræet til at få en ren, struktureret liste over interaktive elementer og derefter krydsrefererer den med en visuel gengivelse«. Den praktiske liste er kort:

• Brug rigtige elementer af typen <button> og <a>, ikke klikbare <div> og <span>.
• Knyt hver <label> til sit inputfelt med for.
• Ingen gennemsigtige overlays over interaktive elementer, og intet interaktivt, der er mindre end 8 kvadratpixel.
• Et stabilt layout, der ikke rykker sig, mens agenten er ved at klikke.

Konklusionen: »Alt, hvad vi foreslår for at gøre et site ›agentklart‹, gør også sites bedre for mennesker.« Det er også, næsten ord for ord, det WebKit beder om i stedet for WebMCP. Hvis jeres checkout dumper en tilgængelighedsaudit, skal I rette det, før I skriver et eneste værktøj.

Lighthouse har haft en kategori, Agentic Browsing, siden version 13.2.0 (1. maj 2026), tilgængelig i Chrome fra version 150 og slået til for PageSpeed Insights API'et i Lighthouse 13.4.1 (20. juli 2026). Den kontrollerer den delmængde af tilgængelighedsaudits, der betyder noget for maskiner, layoutstabilitet, registrerede WebMCP-værktøjer og formularer uden, skemaets gyldighed og om der findes en llms.txt-fil. Chrome kalder den »informativ og uden benchmarks«: Der er ingen score fra 0 til 100. Hvad angår llms.txt, er Google Søgnings egen vejledning, at den ignorerer sådanne filer: At tilføje en »hverken skader eller hjælper jeres sites synlighed eller placeringer i Google Søgning«. At Lighthouse kontrollerer for filen, ændrer ikke på det.

Skal I tilføje WebMCP nu?

På Shopify med et Liquid-tema: intet arbejde. Shopifys storefront-, kurv- og checkoutværktøjer er allerede live, »Der er intet at installere eller konfigurere«, med Shopifys eget forbehold om, at »agentunderstøttelse i øjeblikket er begrænset til Chromium-baserede browsere via en origin trial«. Headless-storefronts er kun dækket i Hydrogens developer preview. Vi har ikke fundet nogen anden handelsplatform, betalingsudbyder eller CDN, der slår WebMCP til for sine kunder.

På et skræddersyet, headless eller ældre site: Det afhænger af, hvem jeres brugere er.

• Hvis jeres kunder eller medarbejdere bruger ChatGPT-desktopappens browser, er imperative værktøjer på siden på øverste niveau den eneste slags, der når dem. Start med to eller tre skrivebeskyttede værktøjer omkring jeres mest almindelige opgave (ordrestatus, tilgængelighed, et tilbud), bag featuredetektering, med et origin trial-token, og mål, om nogen kalder dem.
• Hvis I vil eksperimentere billigt i Chrome, er deklarative attributter på eksisterende formularer nogle få timers arbejde. Stop ikke der: ChatGPT ser dem ikke, og specifikationen indeholder dem ikke længere.
• Hvis I ikke har belæg for, at agenter besøger jer, så ret først semantik, labels og layout. Det arbejde hjælper alle agenter og alle, der bruger hjælpeteknologi, og intet af det bliver smidt væk, når API'et ændrer sig.

Hold i alle tilfælde den almindelige brugerflade komplet. OpenAI's råd: »Bevar den almindelige brugerflade for personer og browsere, der ikke understøtter WebMCP.«

Hvad der kan ændre sig

• En Intent to Ship. Chromes team håber at anmode om det inden for forlængelsesperioden, der slutter med Chrome 162 (2. februar 2027), hvis forlængelsen står ved magt. En udgivelse ville fjerne behovet for tokens i Chrome.
• API'ets form. Et continuation-API (resultater, der lander på næste side efter en navigation), et API for værktøjsstabilitet og størrelsesgrænser er under prototypeudvikling. Nylige versioner har allerede fjernet window.ontoolactivated og argumenter som streng.
• Det deklarative API's skæbne. Ude af specifikationen »for nu«, stadig i Chromes trial.
• Kaldere. Understøttelse i Gemini i Chrome er annonceret, men ikke udgivet. Specifikationens side om implementeringsstatus oplister WebMCP til webapps på Metas Ray-Ban Display-briller som kommer snart og eksperimentel understøttelse i Braves Leo-assistent.

Hvis I tilføjer værktøjer nu, så hold dem i ét modul, bag featuredetektering, så den næste ændring er én redigering.

Hvor I kan få hjælp

Vi bygger de dele af et website og dets backend, som agenter rører ved: værktøjer, der omslutter eksisterende logik for ordrer, bookinger og konti, autorisation, der behandler en agents kald som enhver anden forespørgsel fra den bruger, og de semantiske og tilgængelighedsmæssige rettelser, der gør et site brugbart, før der findes noget værktøj. Vores service til udvikling af AI-agenter og MCP-integration dækker WebMCP-værktøjer og MCP-servere i backend, som er noget andet, selv om navnet ligner.

Vil I vide, hvad en agent ser på jeres site i dag, og om værktøjer ville ændre noget for jeres kunder, så skriv til office@c9group.dev.