WebMCP giver dig ikke trafik. Den kræver en åben fane

Hvad WebMCP faktisk er

WebMCP er et browser-API, der lader en webside registrere sine egne handlinger som værktøjer med et JSON-skema. I stedet for at en AI-agent skal gætte, hvad knappen "Send" gør, kan siden sige det direkte: her er et værktøj, det hedder book_møde, det tager disse felter, og det returnerer dette. Agenten kalder værktøjet i stedet for at klikke i blinde.

Forslaget ligger hos Web Machine Learning Community Group og blev første gang offentliggjort 13. august 2025. Google annoncerede en origin trial på I/O den 19. maj 2026, og den kører i Chrome 149. Edge har en implementering bag et flag. Det er reelt hele udbredelsen lige nu.

Ideen er god. Agenter, der styrer en browser ved at kigge på skærmbilleder og gætte koordinater, er skrøbelige. Et deklareret værktøj med et skema er ikke skrøbeligt. Problemet er ikke ideen. Problemet er, hvad den bliver solgt som.

Hvorfor det ikke er en kanal

Der er tre ting i specifikationen og i Chromes egen dokumentation, som tilsammen afgør sagen.

For det første siger forklaringen selv, at headless kørsel er et ikke-mål: API'et er primært designet til lokale browser-workflows med et menneske i løkken. Det er ikke en formulering, man kan fortolke sig ud af. En søgemaskines crawler er per definition headless.

For det andet kræver det en åben fane. Værktøjerne eksisterer, mens dokumentet er indlæst i en browser. Lukker fanen, er de væk.

For det tredje findes der ingen discovery. Der er ingen registry, intet felt i sitemappet, ingen header, ingen måde for en agent at spørge "hvilke sider i Danmark har et bookingværktøj". Agenten skal allerede være på din side for at opdage, at du har gjort arbejdet.

Sammenlagt: WebMCP kan gøre en agent bedre til at gennemføre en opgave på dit site. Den kan ikke gøre, at agenten kommer til dit site. Det er forskellen på konverteringsoptimering og en kanal, og den forskel bliver systematisk sløret i det materiale, der lige nu bliver skrevet om emnet.

Interessen toppede, før Google gik i gang

Jeg trak søgevolumen for "webmcp" i Danmark den 20. august 2026 via Google Ads-data. Kurven er ikke, hvad man forventer af noget, der bliver kaldt den næste store kanal.

Toppen kom i februar, tre måneder før Google overhovedet annoncerede origin trial. Efter annonceringen kom den aldrig over 110. De beslægtede kommercielle søgninger, jeg tjekkede samtidig — "agent ready website", "ai agent hjemmeside", "geo optimering" — havde ingen målbar volumen i Danmark overhovedet.

Det er ikke et argument for, at teknologien er ligegyldig. Søgevolumen måler opmærksomhed, ikke betydning. Men det er et argument imod, at der skulle være et vindue, du er ved at misse.

To browsermotorer har ikke svaret

Den 28. maj 2026 blev både Mozilla og WebKit bedt om en standardposition på WebMCP — issue 1412 og issue 670. Knap tre måneder senere står begge stadig som foreslået, uden position. Det er hverken modstand eller opbakning; det er tavshed. Men det betyder, at Safari og Firefox ikke har forpligtet sig til noget.

Specifikationen flytter sig også stadig. Chromes lanceringsmateriale beskriver indgangen som navigator.modelContext; forklaringen i repoet specificerer nu document.modelContext. Metoder som getTools og executeTool står markeret som uafklarede. Enhver, der byggede efter dokumentationen i maj, har allerede migrationsgæld.

Og så er der sikkerheden. Værktøjerne kører i brugerens session med brugerens rettigheder. En agent, der er blevet prompt-injiceret af indhold på siden, kalder dine rigtige værktøjer med en rigtig session. Det er ikke et argument for at lade være, men det er et argument for, at det første værktøj, du udstiller, ikke skal være det, der flytter penge.

Hvem der rent faktisk har bygget det

Cloudflare slog WebMCP til på Radar den 7. august 2026, så browserbaserede agenter kan navigere platformen og kalde funktioner som URL-scanning og domæneopslag. Det er en fornuftig implementering, og den viser præcis, hvad API'et er godt til: et dataværktøj, hvor brugeren allerede er inde, og hvor et forkert klik ellers koster en fejlbesked.

Læg mærke til, hvad det ikke er. Cloudflare fik ikke flere besøgende ud af det. De gjorde de besøgende, de havde, i stand til at bruge siden gennem en agent.

Til sammenligning: Google rullede august 2026-spamopdateringen ud den 18. august, globalt og på alle sprog. Den flytter placeringer i denne uge. WebMCP flytter ingen. Hvis du kun har tid til én af delene, er valget ikke svært.

Sådan ville jeg gribe det an

Hvis du alligevel vil være tidligt ude — og der er en fornuftig grund til det, hvis dit produkt bliver brugt inde i browseren — så er rækkefølgen vigtigere end koden.

Start med at finde de to eller tre handlinger på dit site, som en agent realistisk skal udføre på vegne af en bruger. Ikke ti. For de fleste B2B-sites er det en søgning, en beregning og en bookingformular.

Sørg dernæst for, at hver af dem har et rigtigt endpoint bagved med servervalidering, som ikke stoler på inputtet. Værktøjet er en ny indgang til den samme forretningslogik, ikke et nyt sted at lægge logik. Hvis handlingen i dag kun findes som en kæde af klik i frontenden, er det arbejdet — ikke API-kaldet.

Beskriv derefter inputtet som et skema med snævre typer og få felter, og lad det, der ændrer data eller koster penge, kræve en bekræftelse fra brugeren. Log til sidst værktøjskald adskilt fra almindelige sessioner, så du kan se, om nogen som helst bruger dem. Uden den log har du ingen måde at afgøre, om investeringen var rigtig.

Og sæt en dato i kalenderen for at tage stilling igen — når origin trial slutter, og når Gemini i Chrome er ude af forsøgsstadiet. Det er det tidspunkt, hvor spørgsmålet skifter fra teknik til efterspørgsel.