En webbläsaragent ser en knapp och uppskattar dess position. Det kan fungera. Men en webbapplikation kan också kommunicera sin betydelse mer uttryckligt: den här åtgärden söker efter lediga tider, förväntar sig ett datum och returnerar en lista. Det är just denna förskjutning från klickposition till beskrivet verktyg som gör WebMCP intressant.
Enligt den dokumenterade statusen är WebMCP ett experimentellt förslag. Det aktuella förklaringsdokumentet behandlar imperativ registrering via JavaScript och document.modelContext. Deklarativa HTML-formulärverktyg utforskas separat och ingår för närvarande inte i denna specifikation. Chromes översiktssida daterad den 18 maj 2026 är därför inget skäl att hävda en ny universell webbläsarfunktion i oktober.
Ett verktyg börjar med en avgränsad åtgärd
Vårt eget exempel heter ”hitta lediga tider”. Dess uppgift slutar med information. Det skapar ingen reservation. Redan beskrivningen bör göra detta tydligt, så att en agent inte gör ett sökresultat till en bekräftad tid.
Indata innehåller ett datum och en erbjuden tjänst. Resultatet anger samma referens tillsammans med de lediga tidsluckorna. Ett isolerat värde som ”10:30” vore svagare: det skulle kunna höra till en annan dag eller tjänst. Ett strukturerat resultat är särskilt användbart när dess poster kan tolkas entydigt.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Detta är vårt undervisningsschema, inte en WebMCP-registrering färdig att kopiera. Det framtida datumet och tjänsten är påhittade. Det visar det kontrakt som en faktisk implementering skulle behöva specificera. För konkret API-syntax är den aktuella experimentella dokumentationen avgörande.
Även fel behöver en begriplig betydelse
Ett ogiltigt datum, inga lediga tider och en tjänst som inte kan nås av tekniska skäl är tre olika resultat. Om alla bara ger en tom lista skulle agenten behöva gissa orsaken. Verktygets svar bör därför innehålla ett begripligt tillstånd och den information som behövs för nästa beslut.
Detsamma gäller ofullständig information. Är sökningen fullständig, eller saknas det fortfarande data? Hör svaret till den senaste förfrågan? Har personen ändrat datumet under tiden? Sådana frågor finns oavsett om gränssnittet nås via en skärmbild eller genom ett verktyg.
En beskrivning är ingen behörighet
Ett korrekt indataschema anger vilken form en förfrågan ska ha. Det avgör inte om anroparen får läsa denna information. Applikationen måste fortfarande upprätthålla sina egna regler. Ett trevligt klingande verktygsnamn är varken inloggning eller åtkomstkontroll.
Övergången till bokning behöver också en egen betydelse. ”Sök efter lediga tider” och ”reservera den här tiden åt mig” har olika konsekvenser. De bör inte i det tysta smälta samman till en enda funktion. En faktisk reservation skulle behöva ta hänsyn till den bekräftade posten och den avsedda instruktionen.
För en första, ofarlig designövning räcker det därför med fasta exempeldata. Beskriv tre svarstillstånd och resonera fram vilken nästa åtgärd som vore rimlig i varje fall. På så sätt kan du testa hur begripligt kontraktet är utan att fejka en verklig bokning eller en befintlig WebMCP-körmiljö.
WebMCP är inte automatiskt en befintlig fjärransluten MCP-server
Ordet MCP förekommer i olika tekniska sammanhang. En åtgärd som beskrivs på webbläsarsidan är inte enbart av det skälet samma slags anslutning som en fjärransluten verktygsserver som nås via HTTP. För en specifik anslutning är det klienten, transporten, inloggningen och de verktyg som faktiskt erbjuds som räknas.
Befintlig fjärråtkomst via MCP bevisar därför inte att en webbplats stöder WebMCP. På samma sätt garanterar inte ett experimentellt webbläsarförslag att varje agent redan kan använda det. Denna åtskillnad är praktisk: den förhindrar att ett liknande namn leder till fel integrationsplan.
Den överförbara frågan förblir tydlig. Kan en applikation uttrycka vilken åtgärd, med vilka indata, som har vilket resultat och vilken effekt? Ju mer precist svaret är, desto mindre behöver en agent gissa utifrån en position på skärmen. Bra verktygskontrakt gör handlingsutrymmet lättare att förstå; applikationens regler förblir ändå dess eget ansvar.
Källor och status
Research och dokumentation per den 25 oktober 2026. WebMCP · WebMCP explainer.
