AI-søk
Siden 18. oktober 2026 har AI-synlighetssjekken på sikte.ai et WebMCP-verktøy som nettleseragenter kan kalle direkte. Det tok én kveld å bygge, og det er trolig det første WebMCP-verktøyet på et norsk nettsted. Her er hva vi gjorde, hvordan det fungerer, og hva vi lærte – inkludert at Google AI Overview fire dager senere påsto at verktøyet ikke fantes.
Kort oppsummert: Sikte AI la til et WebMCP-verktøy,
checkAiVisibility, på sikte.ai/sjekk-din-synlighet 18. oktober 2026. Det bruker Chromes deklarative WebMCP-API (attributtenetoolname,tooldescriptionogtoolparamdescriptionpå et vanlig HTML-skjema). Nettstedet har en origin trial-token, så verktøyet er tilgjengelig for besøkende med Chrome 149 eller nyere uten flagg. Agenten fyller inn nettadresse og e-post; samtykke og innsending gjøres av brukeren. Det er, så vidt vi vet, det første WebMCP-verktøyet på et norsk nettsted.
Innlegget er for deg som jobber med nettsider i B2B, bank, forsikring eller handel, og som lurer på hva «agentisk web» faktisk betyr for et kontaktskjema eller en priskalkulator.
Hva er WebMCP?
WebMCP er en foreslått webstandard som lar et nettsted fortelle AI-agenter nøyaktig hvilke handlinger siden tilbyr – som «hent pristilbud» eller «send henvendelse» – i stedet for at agenten må gjette seg fram ved å lese skjermen. Standarden utvikles i W3C Web Machine Learning-gruppen, med Google og Microsoft i spissen, og Chrome 149 åpnet en offentlig origin trial i mai 2026.
I dag må en AI-agent som besøker et nettsted tolke skjemaer: finne feltet som trolig betyr «årlig kjørelengde», håpe at knappen ikke åpner en popup, og klikke seg fram. Med WebMCP erklærer siden et verktøy med navn, beskrivelse og et JSON-skjema for inndata. Agenten kaller det som en funksjon. Skjemaet forblir synlig for brukeren, og handlingen skjer i brukerens egen nettleser.
Det finnes to måter å gjøre det på:
Deklarativ API: legg til HTML-attributter på et vanlig
<form>. Ingen ny kode. Dette er det vi brukte.Imperativ API: registrer verktøy i JavaScript med
document.modelContext.registerTool(). Gir full kontroll over logikken bak verktøyet.
To ting er verdt å vite før du leser videre. WebMCP virker bare i nettlesere som støtter det, og per i dag er det Chrome. Og det er laget for agenter som kjører i nettleseren – ikke for ChatGPT, Perplexity eller Google AI Overview, som henter sider fra en server uten å kjøre JavaScript. Det siste blir viktig mot slutten.
Skjemaet vi startet med
Vi valgte AI-synlighetssjekken fordi den er den enkleste konverteringsflyten vi har, og fordi den er vår egen. Skjemaet har fire felt, en Cloudflare Turnstile-sjekk og én knapp.
Felt | Type | Påkrevd | Formål |
|---|---|---|---|
Nettadresse | url | Ja | Nettstedet som skal analyseres |
E-post | Ja | Rapportlenken sendes hit | |
Samtykke til behandling | avkrysning | Ja (GDPR) | Lagring og behandling av personopplysninger |
Nyhetsbrev | avkrysning | Nei | Valgfritt samtykke til markedsføring |
Skjemaet er en React-kodekomponent i Framer, rendret direkte i siden – ingen iframe fra et tredjepartsverktøy. Det viste seg å være avgjørende: WebMCP er låst til samme opprinnelse (origin) som siden, så et HubSpot- eller Typeform-skjema i iframe ville krevd en annen løsning.
To tekniske detaljer vi fant da vi inspiserte siden: ingen av feltene hadde required-attributtet i HTML (valideringen lå i JavaScript), og skjemaet sendte data til vårt eget API via fetch i stedet for vanlig skjemainnsending. Begge deler fikk betydning for hva vi måtte endre.
Slik bygde vi det
Hele endringen er fire attributter på skjemaet og feltene. Chrome leser dem fra DOM-en og bygger JSON-skjemaet selv.
Fire ting å merke seg:
Beskrivelsene er på engelsk, selv om siden er norsk. Agentens språkmodell leser dem, ikke brukeren, og engelsk gir mest forutsigbar tolkning på tvers av modeller.
requiredmåtte legges til i HTML. Det er dette attributtet Chrome bruker for å fyllerequired-listen i JSON-skjemaet. Vi beholdtnovalidatepå skjemaet, så brukeropplevelsen er uendret.Ingen
toolautosubmit. Uten det fyller agenten ut feltene, markerer skjemaet og stopper. Mennesket trykker på knappen. Mer om hvorfor i neste avsnitt.React og ukjente attributter. React kan fjerne små bokstaver-attributter den ikke kjenner. Vi testet først som vanlige JSX-props; de overlevde til DOM-en i Framers byggeprosess, så vi slapp å sette dem i en
useEffect.
Én ting la vi til i skjemaets JavaScript: når personen sender inn et skjema agenten har fylt ut, svarer vi agenten via respondWith() på submit-hendelsen, med status og lenke til rapporten. Da kan agenten fortelle brukeren hvor rapporten ligger.
Chrome genererte dette skjemaet fra HTML-en over – dette er det agenten ser:
Det skjulte Turnstile-feltet ble korrekt utelatt. Vi la merke til at type="url" og type="email" ble til vanlig string uten format – det er Chromes valg, og beskrivelsene veier opp for det.
Samtykke og Turnstile: hvorfor agenten ikke får sende inn selv
Det viktigste designvalget var at agenten aldri skal kunne krysse av for samtykke eller sende skjemaet. Et samtykke etter GDPR skal være en aktiv handling fra personen selv. En agent som krysser av fordi brukeren sa «bare gjør det» er ikke godt nok, og Datatilsynet ville neppe vært uenig.
Løsningen er tre lag:
Samtykkefeltene er ikke
requiredi HTML, og beskrivelsen sier eksplisitt «Leave unset: the user must tick this box themselves». Agenten vet at feltet finnes, men blir bedt om å la det være.Ingen
toolautosubmit. Når verktøyet kalles, ruller Chrome skjemaet inn i synsfeltet, fyller inn nettadresse og e-post, og setter en stiplet ramme rundt skjemaet og knappen (CSS-pseudoklassene:tool-form-activeog:tool-submit-active). Så venter det. Verktøykallet står som «pågår» til personen klikker eller avbryter.Turnstile må uansett passeres, og den sjekken gjør Cloudflare – ikke agenten.
Resultatet er at WebMCP sparer brukeren for skrivearbeidet, mens den juridisk relevante handlingen – samtykke og innsending – fortsatt er menneskelig. Det samme mønsteret passer for en lånesøknad, en forsikringsbestilling eller en B2B-henvendelse: agenten forbereder, mennesket bekrefter.
Slik testet vi
Du trenger Chrome 149 eller nyere. WebMCP er fortsatt i origin trial, så enten må nettstedet ha en origin trial-token, eller så må du slå på flagget chrome://flags/#enable-webmcp-testing. Vi brukte begge: under utviklingen testet vi forhåndsvisninger med flagget, og ved lansering la vi inn en origin trial-token for https://sikte.ai i sidens <head>. Med tokenet er verktøyet tilgjengelig for alle besøkende med Chrome 149 eller nyere, uten flagg. Tokenet utløper 30. mars 2027 og må fornyes før det.
Sjekk at verktøyet er registrert. Åpne DevTools → Application → WebMCP. Panelet lister verktøyene på siden og viser JSON-skjemaet slik Chrome genererte det. Dette er stedet å kontrollere at
required-listen stemmer.Kall verktøyet uten en språkmodell. I konsollen kan du gjøre det samme som en agent ville gjort:
Se hva som skjer på siden. Skjemaet rullet inn i synsfeltet, begge feltene ble fylt, samtykkeboksene forble tomme, og knappen fikk den blå rammen. Ingenting ble sendt. Kallet ble stående åpent til vi klikket selv.
Sjekk andre nettlesere. I Firefox og Safari er
document.modelContextudefinert, og skjemaet oppfører seg som før. Det er hele poenget med progressiv forbedring.
Etter lansering kjørte vi samme test på sikte.ai, med tokenet på plass. Da vi krysset av for samtykke og sendte inn selv, fikk agenten tilbake {"status": "started"} sammen med lenken til rapporten.
En fallgruve: executeTool tar verktøyobjektet fra getTools(), ikke navnet som streng. Vi brukte noen minutter på den.
Google tilbyr også en Chrome-utvidelse, Model Context Tool Inspector, der du skriver et naturlig språk-prompt og ser agenten velge og kalle verktøyet. Den krever en Gemini API-nøkkel for å kjøre prompts.
Hva vi lærte – og hva Google AI Overview sa etterpå
Fire dager etter lansering spurte vi Google om sikte.ai hadde WebMCP-verktøy. AI Overview svarte nei. Verktøyet var der hele tiden – vi sjekket på nytt, og toolname-attributtet ligger til og med i den serverrendrede HTML-en.
Grunnen er enkel, og den er selve kjernen i det vi jobber med. AI Overview kjører ikke en Chrome-agent mot siden din. Svaret lages fra Googles søkeindeks og en språkmodell. document.modelContext er et kjøretids-API i nettleseren; det havner aldri i indeksen. Chromes egen dokumentasjon lister dette som en begrensning: en klient må besøke nettstedet direkte for å vite om det finnes verktøy.
Og det fantes ingen tekst noe sted som sa at verktøyet eksisterte. Ingen setning på siden, ingen FAQ, ingen strukturerte data, ingen bloggpost. Spurt om noe uten dokumentasjon svarer modellen «fant ikke noe» og formulerer det som et nei.
Det er to lærdommer her:
WebMCP og GEO er to ulike kanaler. WebMCP gjør at nettleseragenter kan bruke siden din. GEO (generativ søkemotoroptimalisering) gjør at svarmotorer kan omtale den. Å bygge det ene gir ingenting i det andre.
Det agenten kan gjøre, må også kunne leses. Skal ChatGPT, Perplexity eller Google kunne si «sikte.ai har et verktøy for dette», må det stå i klartekst og i strukturerte data. Derfor skriver vi dette innlegget – og derfor har skjemasiden nå fått en FAQ og strukturerte data som sier det samme.
Vi måler effekten. Spørsmålet «har sikte.ai WebMCP-verktøy?» stilles nå ukentlig til Google AI Overview, ChatGPT og Perplexity, og vi oppdaterer dette innlegget når svaret snur.
Hva dette betyr for B2B, bank og forsikring
Kontaktskjemaer og priskalkulatorer er de to stedene der forskjellen mellom «AI kan lese siden» og «AI kan handle på siden» faktisk betyr omsetning. Begge finnes allerede på nesten alle sider i disse bransjene, og begge kan deklareres på samme måte som vi gjorde over.
Bransje | Verktøy som gir mening | Hva agenten får tilbake |
|---|---|---|
B2B / SaaS |
| Et avgrenset prisestimat uten å publisere hele prislisten |
Bank |
| Effektiv rente og månedsbeløp, med samme forbehold som kalkulatoren viser |
Forsikring |
| Et reelt tilbud – ikke et «fra kr 199» som agenten hopper over |
Handel |
| Lagerstatus og fraktpris før kunden går til kassen |
Tre råd fra vår egen erfaring:
Start med kalkulatoren, ikke skjemaet. En kalkulator er en ren funksjon og har ingen samtykkeproblematikk. Den er også der konkurransen avgjøres: en agent som sammenligner tre forsikringsselskaper velger dem som gir et faktisk tall.
Skill lesing fra handling. Et prisestimat kan agenten hente fritt. En søknad, et kjøp eller en henvendelse bør alltid gå via mennesket, slik vi gjorde med samtykket. Beskrivelsen i
tooldescriptioner stedet å si det.Forbeholdene må inn i svaret. Agenten gjengir tallet den får. Står det «eksempel, eks. tillegg» i kalkulatorens småskrift, må det også stå i verktøyets beskrivelse eller svar – ellers blir det borte før det når kunden.
Og for deg som skal selge dette internt: WebMCP gjør siden brukbar for agenter. Det er ikke det samme som at ChatGPT anbefaler deg. Det krever fortsatt synlig, siterbar tekst – som denne.
Vil du se hvordan nettstedet ditt står seg i AI-søk i dag? Kjør den gratis AI-synlighetssjekken – med eller uten agent.
Kilder: Chrome for Developers – WebMCP, Declarative API, WebMCP explainer (W3C WebML).

Torben Brenden Pedersen
Gründer / GEO-spesialist
Torben jobber med GEO og teknisk optimalisering, og gjør ekspertise om til maskinlesbar autoritet på tvers av søkemotorer og svarmotorer.