En browseragent ser en knap og anslår dens position. Det kan fungere. Men en webapplikation kan også kommunikere sin betydning mere eksplicit: Denne handling søger efter ledige tider, forventer en dato og returnerer en liste. Det er netop dette skift fra klikposition til beskrevet værktøj, der gør WebMCP interessant.
Ifølge den dokumenterede status er WebMCP et eksperimentelt forslag. Den aktuelle explainer omhandler imperativ registrering via JavaScript og document.modelContext. Deklarative HTML-formularværktøjer undersøges separat og er i øjeblikket ikke en del af denne specifikation. Chromes oversigtsside dateret den 18. maj 2026 er derfor ingen grund til at påstå en ny universel browserfunktion i oktober.
Et værktøj starter med en afgrænset handling
Vores eget eksempel hedder »find ledige tider«. Dets opgave slutter med information. Det opretter ikke en reservation. Selve beskrivelsen bør allerede gøre dette klart, så en agent ikke gør et søgeresultat til en bekræftet aftale.
Inputtet indeholder en dato og en udbudt ydelse. Resultatet angiver den samme reference sammen med de ledige tidsrum. En isoleret værdi som »10:30« ville være svagere: Den kunne høre til en anden dag eller ydelse. Et struktureret resultat er særligt nyttigt, når dets poster kan fortolkes entydigt.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Dette er vores undervisningsskema, ikke en WebMCP-registrering, der er klar til at blive kopieret. Den fremtidige dato og ydelsen er opdigtede. Det viser den kontrakt, som en faktisk implementering skulle specificere. For konkret API-syntaks er den aktuelle eksperimentelle dokumentation afgørende.
Fejl har også brug for en forståelig betydning
En ugyldig dato, ingen ledige tider og en tjeneste, der ikke kan nås af tekniske årsager, er tre forskellige resultater. Hvis de alle blot giver en tom liste, måtte agenten gætte årsagen. Værktøjets svar bør derfor indeholde en forståelig tilstand og de oplysninger, der er nødvendige for den næste beslutning.
Det samme gælder delvise oplysninger. Er søgningen fuldstændig, eller mangler der stadig data? Hører svaret til den seneste forespørgsel? Har personen ændret datoen i mellemtiden? Sådanne spørgsmål findes, uanset om grænsefladen tilgås via et skærmbillede eller gennem et værktøj.
En beskrivelse er ikke en tilladelse
Et korrekt inputskema siger, hvilken form en forespørgsel skal have. Det afgør ikke, om kalderen må læse disse oplysninger. Applikationen skal stadig håndhæve sine egne regler. Et velklingende værktøjsnavn er hverken login eller adgangskontrol.
Overgangen til booking har også brug for sin egen betydning. »Søg efter ledige tider« og »reservér denne tid for mig« har forskellige konsekvenser. De bør ikke stiltiende smelte sammen til én enkelt funktion. En faktisk reservation skulle tage højde for det bekræftede element og den tilsigtede instruktion.
Til en første, harmløs designøvelse er faste eksempeldata derfor nok. Beskriv tre svartilstande, og find ud af, hvilken næste handling der ville være rimelig i hvert tilfælde. Så kan du teste, hvor forståelig kontrakten er, uden at forfalske en rigtig booking eller en eksisterende WebMCP-runtime.
WebMCP er ikke automatisk en eksisterende ekstern MCP-server
Ordet MCP optræder i forskellige tekniske sammenhænge. En handling, der er beskrevet på browsersiden, er ikke alene af den grund samme slags forbindelse som en ekstern værktøjsserver, der kan nås via HTTP. For en konkret forbindelse er det klienten, transporten, login og de faktisk tilbudte værktøjer, der tæller.
Eksisterende ekstern MCP-adgang beviser derfor ikke, at et websted understøtter WebMCP. Ligeledes garanterer et eksperimentelt browserforslag ikke, at alle agenter allerede kan bruge det. Denne skelnen er praktisk: Den forhindrer, at et lignende navn fører til den forkerte integrationsplan.
Det overførbare spørgsmål forbliver klart. Kan en applikation udtrykke, hvilken handling med hvilke input der har hvilket resultat og hvilken virkning? Jo mere præcist dette svar er, desto mindre skal en agent gætte ud fra en position på skærmen. Gode værktøjskontrakter gør handlerummet lettere at forstå; applikationens regler forbliver ikke desto mindre dens eget ansvar.
Kilder og status
Research og dokumentation pr. 25. oktober 2026. WebMCP · WebMCP-explainer.
