WebMCP i oktober 2026: slik gjør du et nettsted brukbart for KI-agenter, og hva origin trialen egentlig betyr

WebMCP lar en nettside gi en KI-agent en kort liste over hva den kan gjøre, hver med navn, beskrivelse og inputskjema, i stedet for at agenten må lese seg fram til siden fra skjermbilder og DOM-en. En agent som finner et verktøy som heter check_order_status, kan kalle det med et ordrenummer. Uten verktøyet må agenten finne riktig felt og klikke på riktig knapp.

Det er løftet. Stillingen per 22. oktober 2026 er smalere enn de fleste omtaler gir inntrykk av. WebMCP er et forslag fra en W3C Community Group, ikke en standard. Chrome kjører det som en origin trial, uten at det er tatt noen beslutning om å lansere det. Én forbrukeragent kaller verktøyene (nettleseren i ChatGPT-skrivebordsappen), og den ignorerer den deklarative skjemaversjonen, som ble fjernet fra spesifikasjonen 8. oktober. Safaris motorteam er imot forslaget; Mozilla er nøytral.

Artikkelen er for utviklere og produkteiere som vurderer om de skal legge til WebMCP nå. Den tar for seg hva API-et er, hvem som kaller det, hvordan du slår det på for ekte besøkende, hvordan du skriver verktøy som ikke gir en agent en ladd pistol i hånden, og hva du bør rette først hvis du i det hele tatt vil at agenter skal bruke nettstedet ditt.

Hva WebMCP er

Spesifikasjonen definerer et JavaScript-API på document.modelContext som en side registrerer verktøy gjennom: «WebMCP API-et gjør det mulig for webapplikasjoner å tilby JavaScript-baserte verktøy til KI-agenter.» Et verktøy har et name, en description og en execute-callback, og eventuelt en title, et inputSchema (JSON Schema) og annotations. Sidens egen kode kjøres når agenten kaller verktøyet, med brukerens økt.

Tre ting ved det er lette å ta feil av:

• Det er ikke en standard. Dokumentet er en Draft Community Group Report fra Web Machine Learning Community Group, og sier det selv: «Det er ikke en W3C-standard, og det er heller ikke på W3Cs standardspor.» Chromes egen dokumentasjon kaller det «en foreslått webstandard». Rapportens dato har endret seg med noen dagers mellomrom i oktober; redaktørene kommer fra Microsoft og Google.
• Det er ingen MCP i det. Spesifikasjonen sier at sider som bruker det «kan betraktes som Model Context Protocol-servere som implementerer verktøy i skript på klientsiden», og deretter at den «ikke foreskriver formatet verktøyene eksponeres i overfor nettleseragenten». Mozillas vurdering sa det rett ut: «Navnet er misvisende ... Det er ingen MCP her.» Et WebMCP-verktøy kobler seg ikke til MCP-serveren din i bakenden, og det erstatter den ikke.
• Det gjør deg ikke synlig. Chromes dokumentasjon oppgir selv begrensningen: «Klienter og nettlesere må besøke et nettsted direkte for å vite om det har verktøy som kan kalles.» WebMCP hjelper en agent som allerede er på siden din. Det gjør ingenting for å bli funnet.

API-et er begrenset til sikre kontekster (secure contexts) og styres av en Permissions Policy som heter tools, med 'self' som standard tillatelsesliste. En iframe fra et annet origin kan derfor ikke registrere verktøy med mindre siden som bygger den inn, tillater det.

Stillingen 22. oktober 2026

Chrome 156, den siste versjonen i det opprinnelige trialvinduet, nådde stabilkanalen 20. oktober 2026. Chrome 162, der den omsøkte forlengelsen slutter, er planlagt for stabilkanalen 2. februar 2027. Om forlengelsen er i drift, lot seg ikke bekrefte fra trialkonsollen, så legg planen ut fra at den er sannsynlig, men ikke sikker.

Forlengelsessøknaden forklarer hvorfor Chrome vil ha mer tid: «Tilbakemeldinger fra OT har pekt på forbedringer av API-et, som vi er i ferd med å gjennomføre.» I samme tråd skrev Googles Dominic Farolino at teamet «håper å gå videre til I2S innenfor forlengelsesvinduet», altså å be om å få lansere, og at «Det imperative API-et er langt mer populært enn det deklarative, så vi investerer mer i det som svar på brukernes behov.» Han nevnte også et continuation-API, et API for verktøystabilitet og grenser for verktøystørrelse som er under prototyping. API-et du skriver mot i dag, kommer til å endre seg.

Hvem som faktisk kaller verktøyene

Å registrere verktøy krever ingenting. Å bruke dem krever en agent, og listen over agenter er kort.

Chromes egne testutvidelser. Chromes dokumentasjon tilbyr to utvidelser, blant dem Model Context Tool Inspector, for å prøve verktøy i demoer og på egne sider. De krever din egen API-nøkkel til en modell, og Chrome merker seg: «Disse utvidelsene er atskilt fra Gemini i Chrome.» De er utviklerverktøy, ikke kunder.

ChatGPTs innebygde nettleser. Et innlegg fra en OpenAI-ansatt i selskapets utviklerforum sa 25. august 2026 at «Site tools er ChatGPTs implementasjon av den foreslåtte WebMCP-standarden.» Dokumentasjonen setter vilkår: bestemte modeller, den nyeste skrivebordsappen, at en administrator tillater det i Enterprise-arbeidsområder, ingen Edu-arbeidsområder, og «Tilgjengelighet avhenger også av utrullingen». Den lister også opp hva den ikke støtter: «Deklarativt API: Verktøy definert gjennom HTML-skjemaattributter er ikke tilgjengelige som site tools», og verktøy registrert inne i iframes, også de fra samme origin. OpenAIs anvisning er klar: «Bruk JavaScript til å registrere verktøy på toppnivåsiden». Dokumentasjonen sier ikke om en side trenger et Chrome origin trial-token for at ChatGPT skal se verktøyene.

Gemini i Chrome. Google sa i mai at det «vil snart støtte WebMCP API-er». Vi har ikke funnet noen primærkilde etter det som sier at det gjør det. Ikke bygg en plan på det ennå.

Alle andre faller tilbake. Alle agenter i alle nettlesere leser fortsatt sider på den gamle måten. Chrome sier det i sin egen risikovurdering: «Nettleseragenter i Chrome kan fortsatt betjene nettsteder som før ved å simulere brukeratferd.» OpenAI: «Hvis det ikke finnes noe egnet verktøy, kan agenten likevel bruke de vanlige nettleserfunksjonene sine.» Et nettsted uten WebMCP er ikke usynlig for agenter. Et nettsted med ødelagte knapper og felt uten merkelapper er vanskelig for dem alle.

Det imperative API-et

Dette er versjonen spesifikasjonen definerer, den ChatGPT støtter og den Chrome sier utviklerne foretrekker. Et verktøy pakker inn logikk siden allerede har. Her er et oppslag som bare leser, for en innlogget kunde, etter mønsteret i Chromes dokumentasjon og OpenAIs feature detection:

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 som er viktig i den:

• Navn, beskrivelse og skjema er det modellen leser. Chrome anbefaler høyst 500 tegn per verktøybeskrivelse, 150 per parameterbeskrivelse, 30 per verktøy- og parameternavn og 1,5K tegn per verktøyutdata, og merker seg at «Disse anbefalingene kan endres». Forklaringsdokumentet (explainer) til spesifikasjonen advarer om at «Å eksponere for mange verktøy (for eksempel titalls eller hundrevis) kan svekke agentens ytelse kraftig»: Registrer det som sidens nåværende tilstand trenger, og fjern resten med signalet fra AbortController.
• Det andre argumentet til execute har et AbortSignal, slik at et avbrutt kall kan stoppe en forespørsel som pågår.
• Annotasjoner er hint. readOnlyHint markerer et oppslag. consequentialHint markerer alt som bestiller, kjøper, sender, sletter eller overfører, og Chromes dokumentasjon sier at det «gjør det mulig for agenter og nettlesere å håndheve obligatoriske bekreftelsesdialoger for brukeren». untrustedContentHint markerer utdata som inneholder anmeldelser, brukerinnhold eller data fra tredjeparter. En debugging-annotasjon finnes fra Chrome 156.
• Sidens kode kan også liste opp og kjøre verktøy, med document.modelContext.getTools() og executeTool(), og en toolchange-hendelse utløses når listen endres. JSON-strengifiserte argumenter til executeTool() er foreldet fra Chrome 155.

React, Angular og Vue har hver sine eksperimentelle hjelpere, og npm-pakken webmcp-types gir TypeScript-typer. Eldre veiledninger som kaller navigator.modelContext, er utdaterte: Spesifikasjonen flyttet API-et til document 27. mai 2026.

Det deklarative API-et: med i Chromes trial, ute av spesifikasjonen

Den deklarative versjonen gjør et eksisterende HTML-skjema om til et verktøy med to attributter. Den er attraktiv for gamle, skjematunge nettsteder, fordi ingenting annet må endres:

<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 gjelder: «Når en agent kaller toolname, setter nettleseren fokus på skjemaet og fyller ut feltene. Skjemaet forblir synlig for brukeren.» Nettleseren bygger parameterne fra kontrollene: navnene deres, <label>-elementene, required og alternativene i en <select>. Med mindre skjemaet har toolautosubmit, «må brukeren klikke på Send manuelt for å fullføre oppgaven», og det er det du vil ha på alt som legger inn en bestilling eller sender en lead. SubmitEvent.agentInvoked forteller håndtereren din at en agent fylte ut skjemaet, og respondWith(), etter preventDefault(), returnerer resultatet til agenten. Lytt etter hendelsene toolactivated og toolcancel på document.modelContext med addEventListener: window.ontoolactivated og window.ontoolcancel støttes ikke fra Chrome 156.

Haken er statusen. Den siste endringen i forklaringsdokumentet, 8. oktober 2026, har tittelen «Remove declarative API from the spec for now», og der står det nå at en deklarativ motpart «utforskes separat ... men er foreløpig ikke en del av spesifikasjonen.» ChatGPT støtter det ikke. Chrome dokumenterer det fortsatt i trialen, og Googles Farolino argumenterte i Mozillas tråd for at «vi ser verdi i det deklarative forslaget rett og slett for eldre nettsteder, særlig skjemabaserte». Se på det som et Chrome-eksperiment inne i et eksperiment: greit å prøve, uklokt som eneste vei.

Slik slår du det på for ekte besøkende

Et flagg (chrome://flags/#enable-webmcp-testing) slår på WebMCP i din egen nettleser for testing. Det gjør ingenting for besøkende. For dem trenger siden et origin trial-token.

1. Registrer origin på Chromes side for WebMCP-trialen. Origin trials «er offentlige og åpne for alle utviklere», og et token «slår på en funksjon for alle brukere på origin-en din».
2. Server tokenet på hver side som skal eksponere verktøy, som <meta http-equiv="origin-trial" content="..."> i <head> eller som en Origin-Trial:-header i svaret. Et token kan også settes inn fra skript. Ett token dekker én origin; en side kan ha flere.
3. Forny det. Når en trial forlenges, ber Chrome registrerte om å «oppgi et nytt token for hver origin som er med i trialen», og «Chrome ignorerer ugyldige eller utløpte tokener». Et utløpt token svikter i det stille: Verktøyene slutter bare å dukke opp.
4. For Edge registrerer du deg separat på Edges trialside. Vilkårene der ber om at «Der det er mulig, forplikter du deg til å bruke feature detection / graceful degradation».

Lighthouses WebMCP-revisjoner (audits) krever også trialregistreringen, så et nettsted som tester dem uten token, vil se dem mislykkes.

Slik skriver du verktøy som er trygge å kalle

Sikkerhetsdelen i spesifikasjonen er ikke-normativ, og den er åpen om hvor byrden ligger: Å hindre at en agent blir manipulert «er først og fremst agentens egen sikkerhetsmodells ansvar, ikke noe denne spesifikasjonen kan håndheve normativt.» Verktøyene dine avgjør likevel hvor stor skade en manipulert agent kan gjøre.

• Hint kan lyve, så agenter stoler ikke på dem. Spesifikasjonen: «et ondsinnet nettsted kan utelate eller feilfremstille disse hintene.» OpenAI: «At et verktøy heter noe eller hevder at det bare leser data, er ikke bevis på hva det gjør», og hvert kall i nettleseren får en sikkerhetsvurdering, med bekreftelse som fortsatt kreves for kjøp og lignende handlinger. Annoter ærlig likevel. Det er det en forsiktig agent bruker for å avgjøre når den skal spørre brukeren.
• Beskriv virkningene nøyaktig. Spesifikasjonens eget dårlige eksempel er et verktøy beskrevet som «Finalizes the current shopping cart» som «faktisk utløser et kjøp. Brukeren hadde ikke tenkt å kjøpe noe.» Hvis et verktøy belaster et kort, sier beskrivelsen det, og consequentialHint er true.
• Autoriser på serveren, hver gang. Verktøyet kjører med brukerens økt: Spesifikasjonen merker seg at «Agenter kan arve brukerens identitet og autentiseringskontekst fra nettleseren.» Et verktøykall er en forespørsel fra den brukeren og får de samme kontrollene. Rådet i forklaringsdokumentet holder: «Valider strengt i kode, løst i skjema», fordi strenge skjemafeil kan få agenter til å stoppe opp.
• Regn med prompt injection. Spesifikasjonen lister det først, i tre former: instruksjoner skjult i verktøyets metadata, i verktøyets utdata, og angrep som bruker verktøy som mål. Utdata som inneholder tekst skrevet av andre (anmeldelser, meldinger, produktspørsmål), hører under untrustedContentHint, og bør returneres som data, ikke som prosa en agent kan ta for instruksjoner.
• Velg bevisst bort sider. En Permissions-Policy: tools=()-header gjør API-et utilgjengelig for et dokument og alt det bygger inn. Kontoinnstillinger, betalingssider og administrasjonsskjermer er kandidater.

Én advarsel om Chromes dokumentasjon: Sikkerhetssiden der sier at utkastet har en requestUserInteraction()-metode for å spørre brukeren midt i et verktøykall. Utkastet til spesifikasjonen fra 20. oktober 2026 har ingen slik metode, og forklaringsdokumentet lister fortsatt brukerbekreftelse som et åpent spørsmål. Ikke legg opp designet etter den.

Hva ingeniørene i Safari og Firefox innvender

Innvendingene er verdt å lese selv om du bare bygger for Chrome, fordi de beskriver hvordan WebMCP kan gå galt i praksis.

WebKits posisjon, lagt ut 3. juni 2026, hevder at sider som er vanskelige å bruke, bør rettes i HTML og ARIA, «der brukeren, hjelpeteknologi og agenter alle har nytte av det», og at med verktøy «flytter skjørheten seg bare fra DOM-en og inn i verktøybeskrivelsene.» Den behandler en agent som hjelpeteknologi som ikke bør pekes ut: «WebMCP gjør det motsatte og gjør ‘en agent styrer’ til et observerbart faktum.» Og den merker seg at forslaget «ikke har noen modell for samtykke eller reversibilitet for handlinger med konsekvenser».

Mozilla landet på nøytral i august: WebMCP «innfører en potensielt verdifull abstraksjon», men «åpner en flate der virkelighetens dynamikk etterlater for mange åpne spørsmål til at vi kan støtte det helhjertet». Den advarer om at nettsteder kan «tilby verktøy som ikke samsvarer med opplevelsen til en bruker på siden», for eksempel for å «bruke prompt injection som er usynlig for typiske brukere». Enkelte Mozilla-ingeniører har vist interesse for en imperativ primitiv for funksjonskall; det er ikke en støtte fra Mozilla.

Chrome selv vurderer risikoen for at andre motorer ikke tar i bruk WebMCP som lav for brukerne. Baksiden av det er at et nettsted ikke har noe å hente i Safari eller Firefox på å legge til verktøy i dag.

Det som virker for alle agenter i dag

Alle nettleseragenter leser skjermbilder, HTML og tilgjengelighetstreet. Googles veiledning på web.dev om agentvennlige nettsteder sier at agenter «bruker DOM-en og tilgjengelighetstreet til å få en ren, strukturert liste over interaktive elementer, og krysshenviser den med en visuell gjengivelse». Den praktiske listen er kort:

• Bruk elementene <button> og <a> på ekte, ikke klikkbare <div> og <span>.
• Knytt hver <label> til inputen sin med for.
• Ingen gjennomsiktige overlegg over interaktive elementer, og ingenting interaktivt som er mindre enn 8 kvadratpiksler.
• En stabil layout som ikke forskyver seg mens agenten er i ferd med å klikke.

Konklusjonen: «Alt vi foreslår for å gjøre et nettsted ‘agentklart’, gjør også nettsteder bedre for mennesker.» Det er også, nesten ord for ord, det WebKit ber om i stedet for WebMCP. Hvis kassen din ikke består en tilgjengelighetsrevisjon, rett det før du skriver ett eneste verktøy.

Lighthouse har hatt en kategori for Agentic Browsing siden versjon 13.2.0 (1. mai 2026), tilgjengelig i Chrome fra versjon 150, og slått på for PageSpeed Insights API i Lighthouse 13.4.1 (20. juli 2026). Den sjekker den delmengden av tilgjengelighetsrevisjonene som betyr noe for maskiner, layoutstabilitet, registrerte WebMCP-verktøy og skjemaer uten, skjemagyldighet og om det finnes en llms.txt-fil. Chrome kaller den «informativ og uten referanseverdier»: Det finnes ingen poengsum fra 0 til 100. Om llms.txt er Google Søks egen veiledning at den ignorerer slike filer: Å legge til en «verken skader eller hjelper nettstedets synlighet eller plassering i Google Søk». At Lighthouse sjekker for filen, endrer ikke det.

Bør du legge til WebMCP nå?

På Shopify med et Liquid-tema: Ingen jobb. Shopifys verktøy for butikkfront, handlekurv og kasse er allerede i drift, «Det er ingenting å installere eller konfigurere», med Shopifys eget forbehold om at «agentstøtte er foreløpig begrenset til Chromium-baserte nettlesere gjennom en origin trial». Headless-butikkfronter dekkes bare av forhåndsversjonen for utviklere av Hydrogen. Vi har ikke funnet noen annen handelsplattform, betalingsleverandør eller CDN som slår på WebMCP for kundene sine.

På et egenutviklet, headless eller eldre nettsted: Det avhenger av hvem brukerne dine er.

• Hvis kundene eller de ansatte dine bruker nettleseren i ChatGPT-skrivebordsappen, er imperative verktøy på toppnivåsiden den eneste typen som når dem. Begynn med to eller tre verktøy som bare leser, rundt den vanligste oppgaven din (ordrestatus, tilgjengelighet, et tilbud), bak feature detection, med et origin trial-token, og mål om noen i det hele tatt kaller dem.
• Hvis du vil eksperimentere billig i Chrome, er deklarative attributter på eksisterende skjemaer noen timers arbeid. Ikke stopp der: ChatGPT ser dem ikke, og spesifikasjonen inneholder dem ikke lenger.
• Hvis du ikke har noe som tyder på at agenter besøker deg, rett først semantikk, merkelapper og layout. Det arbeidet hjelper alle agenter og alle som bruker hjelpeteknologi, og ingenting av det blir kastet når API-et endrer seg.

Behold uansett det vanlige grensesnittet komplett. OpenAIs råd: «Behold det vanlige grensesnittet for personer og nettlesere som ikke støtter WebMCP.»

Hva som kan endre seg

• En Intent to Ship. Chrome-teamet håper å be om det innenfor forlengelsesvinduet, som slutter med Chrome 162 (2. februar 2027) hvis forlengelsen står ved lag. En lansering ville fjernet behovet for tokener i Chrome.
• API-ets form. Et continuation-API (resultater som lander på neste side etter en navigering), et API for verktøystabilitet og størrelsesgrenser er under prototyping. Nylige utgivelser har allerede fjernet window.ontoolactivated og strengifiserte argumenter.
• Skjebnen til det deklarative API-et. Ute av spesifikasjonen «foreløpig», fortsatt med i Chromes trial.
• Hvem som kaller. Støtte i Gemini i Chrome er kunngjort, men ikke lansert. Siden over implementeringsstatus i spesifikasjonen lister WebMCP for webapper på Metas Ray-Ban Display-briller som «kommer snart», og eksperimentell støtte i Braves Leo-assistent.

Hvis du legger til verktøy nå, hold dem samlet i én modul, bak feature detection, slik at neste endring blir én endring.

Hvor du får hjelp

Vi bygger de delene av et nettsted og bakenden som agenter berører: verktøy som pakker inn eksisterende logikk for bestilling, booking og kontoer, autorisasjon som behandler en agents kall som enhver annen forespørsel fra den brukeren, og de semantiske og tilgjengelighetsmessige rettingene som gjør et nettsted brukbart før noe verktøy finnes. Vår tjeneste for utvikling av KI-agenter og MCP-integrasjon dekker WebMCP-verktøy så vel som MCP-servere i bakenden, som er noe annet, til tross for navnet.

Vil du vite hva en agent ser på nettstedet ditt i dag, og om verktøy ville endret noe for kundene dine, skriv til office@c9group.dev.