5 August 2026 publiserte Shopify en changelog-oppføring nesten ingen leste. Seksten dager senere hadde hver eneste Liquid-butikk på plattformen stille og rolig fått ti nye funksjoner [9]. Ingen installerte noe. Ingen konfigurerte noe. Butikkene begynte bare å gi AI-agenter en strukturert måte å søke i katalogen på, endre kundens handlekurv og sende kunden videre til kassen [10].
Det er den delen jeg blir gående og tenke på. Ikke lanseringen. Standardinnstillingen.
Protokollen under heter WebMCP, Web Model Context Protocol, og den svarer på et spørsmål to år med agent-hype stort sett har unngått: når en AI-agent lander på nettstedet ditt, hva skal den egentlig gjøre?
Table of Contents
Hva WebMCP faktisk er
Fram til nå har svaret vært «myse og gjette». Nettleseragenter har tatt skjermbilde av siden, kjørt bildet gjennom en visjonsmodell, bestemt seg for hvilke piksler som antakelig utgjorde en «Legg i handlekurv»-knapp, og klikket der. Det fungerer, sånn omtrent, på samme måte som det fungerer å betjene programvare gjennom en kikkert. Bytt navn på en knapp, send ut et uventet cookie-banner, bruk en egendefinert nedtrekksmeny i stedet for en vanlig, og kjeden ryker [1].
WebMCP bytter kikkerten mot en telefonsamtale. I stedet for å utlede hva nettstedet ditt kan gjøre, spør agenten. Nettstedet svarer med en liste: her er verktøyene mine, her er hva hvert av dem gjør, her er dataene hvert av dem trenger.
Chromes egen formulering er den skarpeste setningen noen har skrevet om skiftet: «I stedet for at applikasjonen din er gjest hos en agent, er agenten gjest på din plattform.» [15]
Den snuoperasjonen er hele poenget. I skjermbildemodellen er nettstedet ditt råmateriale som tolkes av andres programvare, og du har ingenting du skulle ha sagt om tolkningen. I WebMCP-modellen skriver du grensesnittet selv. Du bestemmer hvilke handlinger som finnes, hva de heter, hva de tar imot, og hva de blankt nekter å gjøre.
Koden er mindre enn du tror
En verktøyregistrering er omtrent på størrelse med en skjemabehandler [4]:
await document.modelContext.registerTool({
name: "add-todo",
description: "Add a new item to the user's active todo list",
inputSchema: {
type: "object",
properties: {
text: { type: "string", description: "The text content of the todo item" }
},
required: ["text"]
},
async execute({ text }) {
await addTodoItemToCollection(text);
return { content: [{ type: "text", text: `Added todo item: "${text}"` }] };
}
});Tre ting gjør jobben her. description er det modellen leser når den vurderer om dette er riktig verktøy, noe som gjør den til prompt engineering forkledd som API. inputSchema er et JSON Schema som begrenser hva agenten kan sende inn, og det er hovedforsvaret ditt mot at en modell finner på egne parametere [14]. Og execute er rett og slett applikasjonslogikken du allerede har, kalt på samme måte som dine egne knapper kaller den.
Det finnes også en deklarativ variant, altså annotasjoner på vanlige HTML-skjemaer, for nettsteder der interaksjonene allerede har skjemaform [14]. De fleste bør begynne der.
Navnefellen de fleste veiledningene går i
Søk opp WebMCP-veiledninger, og de fleste vil fortelle deg at API-et heter navigator.modelContext. Det stemte en gang. Det stemmer ikke nå: både gjeldende spesifikasjon og referanseimplementasjonen bruker document.modelContext [3][4].
Spesifikasjonen ble først publisert i august 2025 og har, med vedlikeholdernes egne ord, «utviklet seg betydelig» siden [4]. Guider skrevet våren 2026 beskriver et API som ikke lenger finnes under det navnet. Kopierer du et kodeeksempel fra et innlegg som er eldre enn et par måneder, sender du ut noe som stille og rolig ikke registrerer noe som helst.
Jeg vil behandle det som en regel for hele den agentiske stacken akkurat nå. Spesifikasjonene beveger seg raskere enn omtalen av dem. Les repoet, ikke referatet.
WebMCP mot MCP: forskjellen som betyr noe
Driver du allerede en MCP-server, er det nærliggende å spørre hvorfor du trenger nummer to. De løser hver sin halvdel av det samme problemet.
MCP på serversiden har eksistert siden 2025, og det er en forbindelse utenfor nettleseren: agenten snakker direkte med serveren din, over sin egen transport, med sin egen autentisering og sin egen drift [2]. Det egner seg godt til å eksponere funksjonaliteten i et produkt for hvilken som helst agent hvor som helst. Det er også et ordentlig integrasjonsprosjekt, med nøkler som skal utstedes, scopes som skal defineres og infrastruktur som skal driftes.
WebMCP sitter på økten som allerede finnes. Verktøyene lever i fanen brukeren ser på, innenfor innloggingen vedkommende allerede har, og kaller den samme applikasjonslogikken frontenden din kaller [2][15]. Ingen nye nøkler, fordi agenten arver brukerens. Ingen ny drift, fordi koden allerede er ute. Og verktøyene forsvinner når siden lukkes [2][15].
Det siste er det interessante. MCP på serversiden gir varig tilgang til et system. WebMCP gir situasjonsbestemt tilgang til en side. Tilgangsmodellen ligner mer på «hva kan denne brukeren gjøre akkurat nå» enn på «hva har denne integrasjonen fått lov til å gjøre for all framtid».
De to lar seg for øvrig kombinere. Cloudflares Site MCP Server-pakke finnes nettopp for å videreformidle et eksisterende MCP-endepunkt på serversiden inn i nettleseren, til agenter som jobber i fanen [11].
Hvem som allerede har rullet det ut
Det er augustklyngen som gjorde WebMCP fra forslag til noe med reell utbredelse.
Shopify slo på ti verktøy på hver eneste Liquid-butikk og på Hydrogen-forhåndsvisningen, uten at noe måtte installeres [9]. Utvalget er mer komplett enn en demo [10]:
– search_catalog
– browse_store
– get_product
– show_variant
– get_cart
– update_cart
– cancel_cart
– proceed_to_checkout
– manage_orders
– search_shop_policies_and_faqs.
Se hvor grensen går. proceed_to_checkout tar kunden til kassen med handlekurven ferdig fylt, men fullfører ikke kjøpet [10]. Agenten får handle. Mennesket kjøper fortsatt.
OpenAI la Site tools inn i ChatGPTs desktop-nettleser 25. august, slik at støttede sider kan eksponere handlinger for ChatGPT Work og Codex [2]. Begrensningene er stramme: bare GPT-5.6 Sol eller Terra, avslått på Luna, utilgjengelig i Enterprise- og Edu-arbeidsområder, og bare i desktop-appen. Verktøyene lever inne på gjeldende side og i den innloggede økten, og de forsvinner når siden lukkes [2]. OpenAI kjørte også en ti dager lang WebMCP Challenge med Chrome, Shopify, Cloudflare, Netlify, Vercel og Render i ryggen [1], noe som sier litt om hvem som har tenkt at dette skal bli normalen.
Cloudflare valgte den rareste framgangsmåten, og kanskje den med størst konsekvenser. 6. august lanserte de en forhåndsvisning av WebMCP som en bryter i dashbordet [11]. Siden Cloudflare allerede sitter mellom nettstedet ditt og de besøkende, bruker de HTMLRewriter til å injisere én script-tag i HTML-en på vei ut:
<script type="module" src="/.webmcp/bridge.js"
data-packs="c2pa,mcp-server-client" data-mcp-url="/mcp"></script>Koden på din egen server endres aldri, og ingenting må deployes på nytt [11][12]. To verktøypakker er med i forhåndsvisningen, Content Credentials for C2PA-bildeproveniens og en Site MCP Server-pakke som videreformidler dine eksisterende MCP-verktøy fra serversiden inn i nettleseren, og alt sammen kjører i den besøkendes nettleser framfor på Cloudflares servere [11].
Bli sittende med den et øyeblikk. Mellom Shopifys standardinnstillinger og Cloudflares bryter kan en svært stor del av weben bli tilgjengelig for agenter uten at én eneste utvikler skriver en linje WebMCP.
Hva WebMCP ikke er: dette er ikke SEO
Her går det meste av dekningen galt, og her vil jeg protestere høyest.
WebMCP styrer det som skjer etter at en agent har kommet fram til nettstedet ditt. Det har ingenting å gjøre med hvordan du blir funnet, rangert, hentet fram eller sitert. SEJ formulerer det godt: et nettsted kan være vennlig mot agenter uten at det blir det minste enklere å finne for noen [1].
Så hvis problemet ditt er at ChatGPT aldri nevner deg, gjør WebMCP ingenting med det. Synlighet er en annen kamp, som avgjøres av om modellene har tatt opp i seg og stoler på merkevaren din. Det handler, som jeg har argumentert for tidligere, om hvordan AI velger hvilke merkevarer den anbefaler, ikke om markup.
En bedre mental modell er konverteringsoptimalisering, ikke SEO. WebMCP er det du gjør etter at agenten har kommet, for at den ikke skal rote det til. Strukturelt hører det hjemme ved siden av protokollstacken bak Universal Cart og AP2: skinner for agentens gjennomføring, ikke for å skaffe agenten.
Den omrammingen har praktiske konsekvenser. Selger du WebMCP internt som et SEO-tiltak, blir du målt mot rangerings- og trafikkmål prosjektet strukturelt ikke kan påvirke. Da blir det avskrevet som en fiasko, fordi det lyktes med noe annet.
Sikkerhetsproblemet ingen har løst helt
WebMCP-verktøy kjører inne i brukerens innloggede økt. Det er nettopp derfor de er nyttige, og nettopp derfor de er farlige.
Chrome har publisert eksplisitte advarsler om at WebMCP-verktøy kan brukes til å manipulere og kapre agenter [8]. To angrepsveier er verdt å kjenne. Den første er ondsinnede verktøydefinisjoner: et nettsted deklarerer verktøy der beskrivelsene inneholder skjulte instruksjoner rettet mot modellen framfor ærlig dokumentasjon. Den andre, og vanskeligere, er forurensede svar, der et fullstendig troverdig nettsted returnerer tredjepartsdata som brukerkommentarer eller anmeldelser med instruksjoner gjemt inni [7][8].
Årsaken lar seg ikke fikse på protokollnivå. Språkmodeller behandler instruksjoner og data som én udifferensiert strøm av tokens, og det er det som gjør indirekte prompt injection mulig i det hele tatt [8]. WebMCP skaper ikke problemet. Det gir det en godt opplyst og godt dokumentert inngang.
Chromes anbefalte forsvar er lagdelt framfor absolutt: hold mennesket i loopen med bekreftelse på handlinger som betyr noe, bruk spotlighting til å merke upålitelig innhold som data framfor instruksjoner, og begrens hvilke origins en agent får røre for å redusere mulighetene for datalekkasje [6][7]. Spesifikasjonen har egne kontroller, en tools-Permissions Policy som står på ['self'] som standard, eksponering avgrenset per origin via exposedTo, krav om sikker kontekst, og en untrustedContentHint-annotasjon for å merke skitne svar [3]. OpenAI kjører en sikkerhetsvurdering av kjøp, meldinger, slettinger og endringer av tillatelser [1].
Alt dette reduserer risiko. Ingenting av det fjerner risiko. Den som selger deg WebMCP som en løst sikkerhetshistorie, selger.
Måleproblemet det stille gjør verre
Dette er den delen som burde bekymre performance-folk mest, og nesten ingen snakker om den.
Økter som går via agenter er allerede nær usynlige i vanlig analyse. Sporing på klientsiden forutsetter et menneske som kjører JavaScript i en ordinær nettleserøkt, og når referrer-data mangler, havner besøket i Direkte ved siden av bokmerker og adresser folk taster inn selv. Agentatferd bryter den forutsetningen i flere retninger samtidig.
WebMCP gjør det verre, fordi interaksjonen slutter å ligne på surfing i det hele tatt. En kunde sier «legg den blå i medium i kurven og ta meg til kassen», og det du får er et update_cart-kall etterfulgt av proceed_to_checkout [10]. Ingen produktsidevisning. Ingen klikkhendelse for «legg i handlekurv». Ingen scrolldybde, ingen sesjonsopptak verdt å se på. Trakten din rapporterer en kasse som dukket opp fra ingensteds.
Løsningen er den samme som løser alle andre attribusjonshull i 2026, og den samme de fleste team fortsetter å utsette: flytt konverteringsregistreringen til serversiden, på ordre- eller webhook-nivå, og mat plattformene derfra i stedet for fra nettleseren. Har du ikke gjort den jobben, blir ikke agenttrafikk det som endelig tvinger den fram. Det blir bare enda en andel av omsetningen dashbordene dine stille feilplasserer, i samme familie som den blindsonen ChatGPT Ads har i målingen.
Og for å si det rett ut: det finnes foreløpig ingen publiserte tall på antall WebMCP-verktøykall, fullførte oppgaver, feilrater eller effekt på konvertering [1]. Den som gir deg et ROI-tall for WebMCP i dag, gjetter.
Bør du faktisk ta det i bruk?
Nettleserstøtten er den ærlige begrensningen. WebMCP er en Draft Community Group Report fra W3Cs Web Machine Learning Community Group, uttrykkelig ikke en W3C-standard og ikke på standardsporet [3]. Chrome kjører en origin trial fra versjon 149 [5], Edge fra 150, Brave Leo har eksperimentell støtte, Mozilla er nøytral, og WebKits standards position-sak er registrert med innvendinger som spenner fra API-design, duplisering og internasjonalisering til portabilitet, personvern, sikkerhet, bruksområder og hvor arbeidet hører hjemme [1][13]. Safari kommer ikke i dette selskapet med det første.
Beslutningen deler seg ganske rent etter situasjon.
Er du på Shopify eller bak Cloudflare, ruller du kanskje allerede ut dette. Første oppgave er ikke implementering, men inventar. Finn ut hva plattformen slo på som standard, hva verktøyene heter, og hva de lar en agent gjøre inne i en innlogget økt. Shopify setter verktøybeskrivelsene likt for hele plattformen, og det er uklart om den enkelte butikken kan tilpasse dem [1]. Det betyr at beskrivelsen agentene får av butikken din, er skrevet av noen andre. Den ville jeg lest.
Driver du et transaksjonsnettsted med tydelige, avgrensede handlinger, altså søk, filtrering, booking, konfigurering eller pristilbud, er kostnaden ved et forsøk lav og læringen reell. Start med tre eller fire verktøy som bare leser data, legg dem ut bak origin trial-en, og se hva agentene faktisk kaller. Det siste er hele verdien av å være tidlig ute.
Er du et innholds- eller leadsnettsted, kan du vente. Det finnes ingen meningsfull handling å eksponere, ingen synlighetsgevinst, og angrepsflaten er ikke verdt å skaffe seg for en funksjon to nettlesere støtter.
Kort oppsummert
WebMCP er ikke den nye SEO-en, og behandler du det slik, blir prosjektet feil avgrenset og feil målt. Det er noe roligere og mer varig: weben får et grensesnitt nummer to, skrevet for programvare i stedet for øyne.
Det konkrete grepet dette kvartalet er ikke å bygge verktøy. Det er å finne ut hvilke du allerede eksponerer. Sjekk Shopify-butikken din. Sjekk Cloudflare-dashbordet. Og så fikser du konverteringssporingen på serversiden, den agenttrafikken snart gjør obligatorisk.
De annonsørene som taper på dette, blir ikke de som tok i bruk WebMCP for sent. Det blir de som ikke kunne se omsetningen det flyttet.
Innhold
[1] WebMCP Connects AI Agents To Actions Inside Websites — Matt G. Southern, Search Engine Journal. https://www.searchenginejournal.com/webmcp-connects-ai-agents-actions-inside-websites/587303/
[2] OpenAI Adds WebMCP Site Tools To ChatGPT’s Browser — Matt G. Southern, Search Engine Journal. https://www.searchenginejournal.com/chatgpt-adds-webmcp-support/587237/
[3] WebMCP — Draft Community Group Report, W3C Web Machine Learning Community Group. https://webmachinelearning.github.io/webmcp/
[4] webmachinelearning/webmcp — GitHub repository. https://github.com/webmachinelearning/webmcp
[5] Join the WebMCP origin trial — Chrome for Developers. https://developer.chrome.com/blog/ai-webmcp-origin-trial
[6] WebMCP tool security — Chrome for Developers. https://developer.chrome.com/docs/ai/webmcp/secure-tools
[7] Agent security considerations for WebMCP — Chrome for Developers. https://developer.chrome.com/docs/agents/security
[8] WebMCP Can Be Used To Hijack AI Agents, Chrome Warns — Search Engine Journal. https://www.searchenginejournal.com/webmcp-can-be-used-to-hijack-ai-agents-chrome-warns/578904/
[9] WebMCP support for Liquid and Hydrogen storefronts — Shopify developer changelog. https://shopify.dev/changelog/webmcp-liquid-hydrogen
[10] WebMCP tools — Shopify.dev API documentation. https://shopify.dev/docs/api/web-mcp
[11] Give any website a WebMCP interface — Cloudflare Blog. https://blog.cloudflare.com/webmcp/
[12] Cloudflare Previews Automatic WebMCP Support for Web Pages — InfoQ. https://www.infoq.com/news/2026/08/cloudflare-webmcp/
[13] WebMCP · Issue #670 — WebKit/standards-positions, GitHub. https://github.com/WebKit/standards-positions/issues/670
[14] WebMCP documentation — Chrome for Developers. https://developer.chrome.com/docs/ai/webmcp
[15] When to use WebMCP and MCP — André Cipriani Bandarra and Alexandra Klepper, Chrome for Developers. https://developer.chrome.com/blog/webmcp-mcp-usage
