WebMCP i oktober 2026: så gör du en webbplats användbar för AI-agenter, och vad origin trial egentligen betyder

Med WebMCP kan en webbsida ge en AI-agent en kort lista över vad den kan göra, där varje punkt har ett namn, en beskrivning och ett indataschema, i stället för att låta agenten lista ut sidan utifrån skärmbilder och DOM. En agent som hittar verktyget check_order_status kan anropa det med ett ordernummer. Utan det måste agenten hitta rätt fält och klicka på rätt knapp.

Det är löftet. Läget den 22 oktober 2026 är snävare än de flesta genomgångar ger sken av. WebMCP är ett förslag från en Community Group inom W3C, inte en standard. Chrome kör det som origin trial, utan något beslut ännu om att släppa det. En enda konsumentagent anropar verktygen (webbläsaren som är inbyggd i ChatGPT:s skrivbordsapp), och den agenten ignorerar den deklarativa formulärversionen, som togs bort ur specifikationen den 8 oktober. Safaris motorteam motsätter sig förslaget; Mozilla är neutralt.

Den här artikeln vänder sig till utvecklare och produktägare som ska avgöra om de ska lägga till WebMCP nu. Den går igenom vad API:et är, vem som anropar det, hur du slår på det för riktiga besökare, hur du skriver verktyg som inte lämnar över ett laddat vapen till en agent, och vad du bör åtgärda först om du vill att agenter över huvud taget ska använda din sajt.

Vad WebMCP är

Specifikationen definierar ett JavaScript-API på document.modelContext där en sida registrerar verktyg: ”WebMCP-API:et gör det möjligt för webbapplikationer att ge AI-agenter JavaScript-baserade verktyg.” Ett verktyg har ett name, en description och en execute-callback, och som tillval en title, ett inputSchema (JSON Schema) och annotations. Sidans egen kod körs när agenten anropar verktyget, med användarens session.

Tre saker är lätta att missförstå:

• Det är inte en standard. Dokumentet är en Draft Community Group Report från Web Machine Learning Community Group och säger det själv: ”Det är inte en W3C-standard och ligger inte heller på W3C:s standardspår.” Chromes egen dokumentation kallar det ”en föreslagen webbstandard”. Rapportens datum har ändrats med några dagars mellanrum under oktober; dess redaktörer kommer från Microsoft och Google.
• Det finns ingen MCP i det. Specifikationen säger att sidor som använder det ”kan ses som Model Context Protocol-servrar som implementerar verktyg i skript på klientsidan”, och sedan att den ”inte föreskriver i vilket format verktygen exponeras för webbläsarens agent”. Mozillas granskning sa det rakt ut: ”Namnet är missvisande ... Det finns ingen MCP här.” Ett WebMCP-verktyg ansluter inte till din MCP-server i backend, och ersätter den inte.
• Det gör dig inte upptäckbar. Chromes dokumentation räknar upp begränsningen själv: ”Klienter och webbläsare måste besöka en sajt direkt för att veta om den har verktyg som går att anropa.” WebMCP hjälper en agent som redan är på din sida. Det gör ingenting för att du ska bli hittad.

API:et är begränsat till säkra kontexter och styrs av en Permissions Policy som heter tools och vars standardlista över tillåtna källor är 'self', så en cross-origin iframe kan inte registrera verktyg om inte den inbäddande sidan tillåter det.

Läget den 22 oktober 2026

Chrome 156, den sista versionen i det ursprungliga testfönstret, nådde den stabila kanalen den 20 oktober 2026. Chrome 162, där den begärda förlängningen slutar, är planerad till stabil version den 2 februari 2027. Om förlängningen gäller redan nu gick inte att bekräfta i konsolen för testperioden, så räkna med att den sannolikt gör det men inte säkert.

Förlängningsansökan förklarar varför Chrome vill ha mer tid: ”Feedback från OT har gett förslag på förbättringar av API:et, som vi håller på att genomföra.” I samma tråd skrev Googles Dominic Farolino att teamet ”hoppas kunna gå vidare till I2S inom förlängningsperioden”, det vill säga be om att få släppa funktionen, och att ”det imperativa API:et är mycket mer populärt än det deklarativa, så vi satsar mer på det som svar på användarnas behov.” Han nämnde också ett continuation-API, ett API för verktygsstabilitet och gränser för verktygens storlek som prototypas. API:et du skriver mot i dag kommer att ändras.

Vem som faktiskt anropar verktygen

Att registrera verktyg kräver ingenting. Att använda dem kräver en agent, och listan över agenter är kort.

Chromes egna testtillägg. Chromes dokumentation erbjuder två tillägg, bland dem Model Context Tool Inspector, för att pröva verktyg i demon och på dina egna sidor. De kräver din egen API-nyckel till en modell, och Chrome noterar: ”De här tilläggen är fristående från Gemini i Chrome.” De är utvecklarverktyg, inte kunder.

ChatGPT:s inbyggda webbläsare. I ett inlägg på OpenAI:s utvecklarforum skrev en anställd den 25 augusti 2026 att ”Site tools är ChatGPT:s implementation av den föreslagna WebMCP-standarden.” Dess dokumentation ställer villkor: vissa modeller, den senaste skrivbordsappen, att en administratör tillåter det i Enterprise-arbetsytor, inga Edu-arbetsytor, och ”Tillgängligheten beror också på utrullningen”. Den räknar också upp vad som inte stöds: ”Deklarativt API: verktyg som definieras med HTML-formulärattribut är inte tillgängliga som site tools”, samt verktyg som registreras i iframes, även sådana med samma origin. OpenAI:s instruktion är tydlig: ”Använd JavaScript för att registrera verktyg på sidan på toppnivå”. Dokumentationen säger inte om en sida behöver en token för Chromes origin trial för att ChatGPT ska se dess verktyg.

Gemini i Chrome. Google sa i maj att det ”kommer snart att stödja WebMCP-API:er”. Vi hittade ingen primärkälla sedan dess som säger att det gör det. Bygg inga planer på det ännu.

Alla andra faller tillbaka. Varje agent i varje webbläsare läser fortfarande sidor på det gamla sättet. Chrome säger det i sin egen riskbedömning: ”Webbläsaragenter i Chrome kan fortsätta att styra sajter som förut genom att simulera användarbeteenden.” OpenAI: ”Om inget lämpligt verktyg finns kan agenten ändå använda sina vanliga webbläsarfunktioner.” En sajt utan WebMCP är inte osynlig för agenter. En sajt med trasiga knappar och fält utan etiketter är svår för dem alla.

Det imperativa API:et

Det här är versionen som specifikationen definierar, den som ChatGPT stöder och den som Chrome säger att utvecklare föredrar. Ett verktyg omsluter logik som sidan redan har. Här är ett skrivskyddat uppslag för en inloggad kund, efter mönstret i Chromes dokumentation och OpenAI:s 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 spelar roll i koden:

• Namn, beskrivning och schema är det modellen läser. Chrome rekommenderar högst 500 tecken per verktygsbeskrivning, 150 per parameterbeskrivning, 30 per verktygs- och parameternamn och 1,5 tusen tecken per verktygsutdata, och noterar att ”De här rekommendationerna kan komma att ändras”. Specifikationens explainer varnar för att ”Att exponera för många verktyg (till exempel dussintals eller hundratals) kan försämra agentens prestanda kraftigt”: registrera det som sidans nuvarande tillstånd behöver och ta bort resten med signalen från AbortController.
• Det andra argumentet till execute bär en AbortSignal, så att ett avbrutet anrop kan stoppa en förfrågan som pågår.
• Annotations är tips. readOnlyHint markerar ett uppslag. consequentialHint markerar allt som bokar, köper, skickar, raderar eller överför, och Chromes dokumentation säger att den ”gör det möjligt för agenter och webbläsare att kräva obligatoriska bekräftelsedialoger för användaren”. untrustedContentHint markerar utdata som innehåller recensioner, användarinnehåll eller data från tredje part. En debugging-annotation finns från Chrome 156.
• Sidans kod kan också lista och köra verktyg, med document.modelContext.getTools() och executeTool(), och en toolchange-händelse utlöses när listan ändras. Argument som JSON-serialiserats till strängar i executeTool() är föråldrade från Chrome 155.

React, Angular och Vue har var och en experimentella hjälpbibliotek, och npm-paketet webmcp-types tillhandahåller TypeScript-typer. Äldre handledningar som anropar navigator.modelContext är föråldrade: specifikationen flyttade API:et till document den 27 maj 2026.

Det deklarativa API:et: med i Chromes trial, ute ur specifikationen

Den deklarativa versionen gör om ett befintligt HTML-formulär till ett verktyg med två attribut. Den är lockande för gamla, formulärtunga sajter, eftersom inget annat behöver ändras:

<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äller att ”när en agent anropar toolname ger webbläsaren formuläret fokus och fyller i dess fält. Formuläret förblir synligt för användaren.” Webbläsaren bygger parametrarna utifrån kontrollerna: deras namn, deras <label>, required och alternativen i en <select>. Om inte formuläret har toolautosubmit gäller att ”användaren själv måste klicka på Skicka för att slutföra uppgiften”, vilket är precis vad du vill ha för allt som lägger en beställning eller skickar en lead. SubmitEvent.agentInvoked talar om för din hanterare att en agent har fyllt i formuläret, och respondWith(), efter preventDefault(), returnerar utfallet till agenten. Lyssna efter händelserna toolactivated och toolcancel på document.modelContext med addEventListener: window.ontoolactivated och window.ontoolcancel stöds inte från Chrome 156.

Haken är dess status. Explainerns senaste ändring, den 8 oktober 2026, har rubriken ”Remove declarative API from the spec for now”, och där står nu att en deklarativ motsvarighet ”utforskas separat ... men inte ingår i specifikationen i nuläget.” ChatGPT stöder den inte. Chrome dokumenterar den fortfarande i trialen, och Googles Farolino hävdade i Mozillas tråd att ”vi ser ett värde i det deklarativa förslaget enbart för äldre webbplatser, särskilt formulärbaserade”. Se det som ett Chrome-experiment inuti ett experiment: gott att prova, oklokt som enda väg.

Slå på det för riktiga besökare

En flagga (chrome://flags/#enable-webmcp-testing) slår på WebMCP i din egen webbläsare för tester. Den gör ingenting för besökare. För dem behöver sidan en token för origin trial.

1. Registrera din origin på Chromes registreringssida för WebMCP-trialen. Origin trials ”är offentliga och öppna för alla utvecklare”, och en token ”aktiverar en funktion för alla användare på din origin”.
2. Servera token på varje sida som ska exponera verktyg, som <meta http-equiv="origin-trial" content="..."> i <head> eller som en Origin-Trial:-header i svaret. En token kan också läggas in från skript. En token gäller för en origin; en sida kan ha flera.
3. Förnya den. När en trial förlängs ber Chrome registranterna att ”ange en ny token för varje origin som är med i trialen”, och ”Chrome ignorerar ogiltiga eller utgångna tokens”. En utgången token misslyckas tyst: verktygen slutar helt enkelt dyka upp.
4. För Edge registrerar du dig separat på Edges trialsida. Villkoren ber om att ”Om möjligt går du med på att tillämpa feature detection / graceful degradation”.

Lighthouses WebMCP-granskningar kräver också registreringen för trialen, så en sajt som testar dem utan token kommer att se dem misslyckas.

Skriv verktyg som är säkra att anropa

Specifikationens avsnitt om säkerhet är icke-normativt och är öppet med var bördan ligger: att hindra att en agent manipuleras är ”främst agentens egen säkerhetsmodells ansvar snarare än något den här specifikationen normativt kan genomdriva.” Dina verktyg avgör ändå hur stor skada en manipulerad agent kan göra.

• Tips kan ljuga, så agenter litar inte på dem. Specifikationen: ”en illasinnad sajt kan utelämna eller förvränga de tipsen.” OpenAI: ”Ett verktygs namn eller påstående att det bara läser data är inget bevis på vad det gör”, och varje anrop i dess webbläsare går igenom en säkerhetsgranskning, med bekräftelse som fortfarande krävs för köp och liknande åtgärder. Annotera ändå ärligt. Det är vad en försiktig agent använder för att avgöra när den ska fråga användaren.
• Beskriv effekterna exakt. Specifikationens eget dåliga exempel är ett verktyg som beskrivs som ”Slutför den aktuella varukorgen” men som ”i själva verket utlöser ett köp. Användaren avsåg inte att köpa något.” Om ett verktyg debiterar ett kort ska beskrivningen säga det, och consequentialHint ska vara true.
• Auktorisera på servern, varje gång. Verktyget körs med användarens session: specifikationen noterar att ”Agenter kan ärva användarens identitet och autentiseringskontext från webbläsaren.” Ett verktygsanrop är en förfrågan från den användaren och får samma kontroller. Explainerns råd håller: ”Validera strikt i koden, löst i schemat”, eftersom strikta schemafel kan få agenter att stanna av.
• Räkna med prompt injection. Specifikationen listar det först, i tre former: instruktioner dolda i verktygets metadata, i verktygets utdata, och attacker som använder verktyg som mål. Utdata som innehåller text skriven av andra (recensioner, meddelanden, produktfrågor) hör hemma under untrustedContentHint och bör returneras som data, inte som prosa som en agent kan ta för instruktioner.
• Välj bort sidor med avsikt. Headern Permissions-Policy: tools=() gör API:et otillgängligt för ett dokument och allt det bäddar in. Kontoinställningar, betalningssidor och adminvyer är kandidater.

En varning om Chromes dokumentation: dess säkerhetssida säger att utkastet innehåller en metod requestUserInteraction() för att fråga användaren mitt under ett verktyg. Specifikationens utkast från den 20 oktober 2026 har ingen sådan metod, och explainern listar fortfarande användarbekräftelse som en öppen fråga. Designa inte kring den.

Vad ingenjörerna bakom Safari och Firefox invänder mot

Invändningarna är värda att läsa även om du bara bygger för Chrome, eftersom de beskriver hur WebMCP kan gå fel i praktiken.

WebKits ståndpunkt, publicerad den 3 juni 2026, hävdar att sidor som är svåra att använda ska åtgärdas i HTML och ARIA, ”där användaren, hjälpmedlen och agenterna alla har nytta av det”, och att med verktyg ”flyttar bräckligheten bara från DOM till verktygsbeskrivningarna.” Den behandlar en agent som ett hjälpmedel som inte bör pekas ut: ”WebMCP gör tvärtom och gör ’en agent styr’ till ett observerbart faktum.” Och den noterar att förslaget ”saknar en modell för samtycke eller återkallelse vid åtgärder med följder”.

Mozilla landade i augusti på neutral: WebMCP ”introducerar en potentiellt värdefull abstraktion”, men ”öppnar en yta vars verkliga dynamik lämnar för många frågor öppna för att man ska kunna ställa sig helhjärtat bakom den”. Mozilla varnar för att sajter kan ”tillhandahålla verktyg som inte stämmer med upplevelsen för en användare på sidan”, till exempel för att ”tillhandahålla prompt injection som är osynlig för vanliga användare”. Enskilda Mozilla-ingenjörer har visat intresse för en imperativ primitiv för function calling; det är inte ett stöd från Mozilla.

Chrome bedömer själv risken att andra webbläsarmotorer inte antar WebMCP som låg för användarna. Baksidan av det är att en sajt inte vinner något i Safari eller Firefox på att lägga till verktyg i dag.

Det som fungerar för alla agenter i dag

Varje webbläsaragent läser skärmbilder, HTML och tillgänglighetsträdet. Googles vägledning på web.dev om agentvänliga sajter säger att agenter ”använder DOM och tillgänglighetsträdet för att få en ren, strukturerad lista över interaktiva element, och korsrefererar sedan den mot en visuell återgivning”. Den praktiska listan är kort:

• Använd riktiga element av typen <button> och <a>, inte klickbara <div> och <span>.
• Koppla varje <label> till sitt fält med for.
• Inga genomskinliga överlägg över interaktiva element, och inget interaktivt som är mindre än 8 kvadratpixlar.
• En stabil layout som inte flyttar sig medan agenten är på väg att klicka.

Slutsatsen: ”Allt vi föreslår för att göra en sajt ’agentredo’ gör också sajter bättre för människor.” Det här är också, nästan ord för ord, vad WebKit ber om i stället för WebMCP. Om din kassa inte klarar en tillgänglighetsgranskning ska du åtgärda det innan du skriver ett enda verktyg.

Lighthouse har haft kategorin Agentic Browsing sedan version 13.2.0 (1 maj 2026), tillgänglig i Chrome från version 150, och aktiverad för PageSpeed Insights API i Lighthouse 13.4.1 (20 juli 2026). Den kontrollerar den delmängd av tillgänglighetsgranskningarna som spelar roll för maskiner, layoutstabilitet, registrerade WebMCP-verktyg och formulär utan sådana, schemats giltighet och om det finns en llms.txt-fil. Chrome kallar den ”informativ och utan referensvärden”: det finns inget betyg från 0 till 100. När det gäller llms.txt är Google Söks egen vägledning att den ignorerar sådana filer: att lägga till en ”varken skadar eller hjälper din sajts synlighet eller rankning i Google Sök”. Att Lighthouse kontrollerar filen ändrar inte det.

Ska du lägga till WebMCP nu?

På Shopify med ett Liquid-tema: inget arbete. Shopifys verktyg för butik, varukorg och kassa är redan i gång, ”Det finns inget att installera eller konfigurera”, med Shopifys egen reservation att ”agentstödet för närvarande är begränsat till Chromium-baserade webbläsare via en origin trial”. Headless-butiker omfattas bara av förhandsversionen för utvecklare av Hydrogen. Vi hittade ingen annan handelsplattform, betaltjänstleverantör eller något CDN som slår på WebMCP åt sina kunder.

På en egen, headless eller äldre sajt: det beror på vilka dina användare är.

• Om dina kunder eller medarbetare använder webbläsaren i ChatGPT:s skrivbordsapp är imperativa verktyg på sidan på toppnivå det enda slag som når dem. Börja med två eller tre skrivskyddade verktyg kring din vanligaste uppgift (orderstatus, tillgänglighet, en offert), bakom feature detection, med en token för origin trial, och mät om någon anropar dem.
• Om du vill experimentera billigt i Chrome är deklarativa attribut på befintliga formulär några timmars arbete. Stanna inte där: ChatGPT ser dem inte, och specifikationen innehåller dem inte längre.
• Om du inte har några belägg för att agenter besöker dig, åtgärda semantik, etiketter och layout först. Det arbetet hjälper varje agent och varje person som använder hjälpmedel, och inget av det kastas bort när API:et ändras.

Behåll i alla fall det vanliga gränssnittet komplett. OpenAI:s råd: ”Behåll det vanliga gränssnittet för människor och webbläsare som inte stöder WebMCP.”

Vad som kan ändras

• En Intent to Ship. Chromes team hoppas kunna be om det inom förlängningsperioden, som slutar med Chrome 162 (2 februari 2027) om förlängningen står sig. Ett släpp skulle ta bort behovet av tokens i Chrome.
• API:ets form. Ett continuation-API (resultat som landar på nästa sida efter en navigering), ett API för verktygsstabilitet och storleksgränser prototypas. Senare versioner har redan tagit bort window.ontoolactivated och argument serialiserade till strängar.
• Det deklarativa API:ets öde. Ute ur specifikationen ”tills vidare”, fortfarande med i Chromes trial.
• Anropare. Stöd i Gemini i Chrome har aviserats men inte levererats. Specifikationens sida om implementationsstatus listar WebMCP för webbappar på Metas Ray-Ban Display-glasögon som ”kommer snart”, och experimentellt stöd i Brave-assistenten Leo.

Om du lägger till verktyg nu, ha dem i en enda modul, bakom feature detection, så att nästa ändring blir en enda redigering.

Var du får hjälp

Vi bygger de delar av en webbplats och dess backend som agenter berör: verktyg som omsluter befintlig order-, boknings- och kontologik, auktorisering som behandlar en agents anrop som vilken annan förfrågan som helst från den användaren, och de semantik- och tillgänglighetsåtgärder som gör en sajt användbar innan något verktyg finns. Vår tjänst för utveckling av AI-agenter och MCP-integration omfattar WebMCP-verktyg såväl som MCP-servrar i backend, som är något annat trots namnet.

Vill du veta vad en agent ser på din sajt i dag, och om verktyg skulle förändra något för dina kunder, skriv till office@c9group.dev.