WebMCP verschiebt die Schnittstelle zwischen Website und KI-Agent

Websites sind bislang primär für Menschen gebaut. Ein Nutzer sieht ein Suchfeld, einen Warenkorb, Filter, Formulare und Buttons. Ein KI-Agent muss dieselbe Oberfläche dagegen technisch interpretieren: Er liest den DOM, wertet den Accessibility Tree aus, erkennt Elemente auf Screenshots oder steuert Maus und Tastatur.

WebMCP setzt genau an dieser Stelle an. Eine Website kann bestimmte Funktionen als strukturierte Tools bereitstellen. Statt beispielsweise einen Filter visuell zu suchen, Werte einzutragen und anschließend einen Button auszulösen, kann ein Agent eine klar beschriebene Funktion mit definierten Parametern aufrufen. Der Websitebetreiber legt dabei fest, welche Aktionen existieren, welche Eingaben zulässig sind und wie sie ausgeführt werden.

Der Begriff sollte allerdings sauber verwendet werden. WebMCP ist mit Stand vom 16. September 2026 kein fertiger W3C-Standard und befindet sich nicht auf dem W3C Standards Track. Es handelt sich um eine experimentelle Spezifikation aus der W3C Web Machine Learning Community Group.

Das ist mehr als eine formale Fußnote. Wer WebMCP heute implementiert, arbeitet mit einer Technologie, deren technische Richtung inzwischen deutlich erkennbar ist, deren APIs und Sicherheitsmechanismen sich aber weiterhin verändern.

WebMCP wird häufig als Möglichkeit beschrieben, Websites „KI-fähig“ zu machen. Das greift zu kurz.

Der technisch interessantere Punkt ist der gemeinsame Zustand von Mensch, Website und Agent. WebMCP arbeitet im Kontext des aktuell geöffneten Dokuments. Damit kann ein Agent grundsätzlich auf dieselbe Seite, denselben Loginzustand und denselben aktuellen UI-Kontext zugreifen wie der Nutzer.

Das unterscheidet den Ansatz erheblich von einer isolierten Backend-Integration. Eine externe Schnittstelle muss Authentifizierung, Zustand und Kontext häufig separat rekonstruieren. WebMCP setzt dagegen direkt an der laufenden Webanwendung an.

Für Anwendungen mit komplexem Frontend ist das entscheidend. Ein Produktkonfigurator, ein eingeloggtes Kundenportal oder ein mehrstufiger Checkout besteht eben nicht nur aus einer Sammlung von API-Endpunkten. Der Zustand der Oberfläche ist Teil des Prozesses.

WebMCP verfolgt derzeit zwei komplementäre Ansätze: eine imperative JavaScript-API und eine deklarative Integration für bestehende HTML-Formulare.

Der aktuelle technische Kern ist document.modelContext. Darüber können Websites Tools registrieren, auffindbar machen und ausführen. Zu den zentralen Mechanismen gehören unter anderem registerTool(), getTools() und executeTool().

Ein solches Tool besteht nicht lediglich aus einer JavaScript-Funktion. Es besitzt einen maschinenlesbaren Vertrag. Dazu gehören ein Name, eine Beschreibung, ein Eingabeschema, optionale Annotationen und die eigentliche Ausführungslogik.

Das Schema ist für die Zuverlässigkeit relevant. Ein Agent muss dann nicht mehr erraten, welche Werte ein Eingabefeld akzeptiert. Typen, Pflichtfelder, Enumerationen oder andere Beschränkungen können explizit vorgegeben werden.

Gerade hier zeigt sich, weshalb WebMCP eher ein Engineering-Thema als eine einfache Marketingintegration ist. Gute Tooldefinitionen benötigen eine klare Semantik, stabile Businesslogik, kontrollierte Berechtigungen und sauberes Lifecycle-Handling.

Nicht jede WebMCP-Funktion erfordert eine neue JavaScript-Schnittstelle. Die deklarative API baut bewusst auf vorhandener HTML-Semantik auf.

Formulare können beispielsweise mit toolname, tooldescription und toolparamdescription beschrieben werden. Bereits vorhandene Attribute wie required, min, max, Feldtypen oder Auswahloptionen bleiben dabei relevant.

Das ist architektonisch sinnvoll. Ein sauber gebautes Formular enthält bereits einen erheblichen Teil der Information, die ein Agent benötigt.

Ein wichtiger Unterschied betrifft die tatsächliche Ausführung. Ein Agent kann ein Formular befüllen, ohne dass er es automatisch absenden darf. Erst toolautosubmit erweitert diese Befugnis. Der Standard unterscheidet damit bewusst zwischen dem Vorbereiten einer Aktion und ihrer endgültigen Ausführung.

Tools existieren nicht zwangsläufig dauerhaft. In einer Single-Page-Application können Funktionen durch Navigation, Loginstatus, Komponentenwechsel oder einen veränderten Workflow erscheinen und wieder verschwinden.

Deshalb berücksichtigt WebMCP unter anderem Abbruchsignale und Änderungen des verfügbaren Toolsets. Diese Details wirken zunächst technisch, werden in realen React-, Vue- oder vergleichbaren Anwendungen aber schnell relevant.

Genau solche Fragen werden im September 2026 noch aktiv diskutiert. Dazu gehören In-flight-Unregistration, dynamische Toolsets, zustandsabhängige Schemas und die Frage, wie ein Agent zwischen fehlender Berechtigung, temporärer Nichtverfügbarkeit und einem technischen Fehler unterscheiden soll.

WebMCP ist nicht einfach ein MCP-Server, der zufällig im Browser läuft. Die Spezifikation schreibt dem Browser nicht einmal vor, in welchem Format er die Website-Tools intern an einen Agenten weitergibt. Das könnte MCP sein, proprietäres Function Calling oder eine andere Vermittlungsschicht.

Die Vergleichsmatrix auf Seite 4 des Recherchedossiers macht die architektonische Trennung besonders deutlich:

Die Tabelle basiert auf der Gegenüberstellung des Dossiers zu WebMCP, Backend-MCP und DOM-/Vision-/Computer-Use-Automation.

In vielen Projekten ist deshalb eine hybride Architektur plausibler als die Suche nach einer einzigen universellen Schnittstelle. Backend-MCP oder klassische APIs eignen sich für dauerhafte Businessfunktionen und Hintergrundprozesse. WebMCP kann den sichtbaren, angemeldeten Browserkontext abbilden. Browser-Automation bleibt dort relevant, wo keine strukturierten Tools vorhanden sind. Genau diese Kombination entspricht auch der im Dossier herausgearbeiteten Architektur.

Die Entwicklungsgeschwindigkeit ist hoch. Das macht WebMCP interessant, aber auch fehleranfällig für jeden, der ältere Tutorials übernimmt.

Die erste veröffentlichte WebMCP-Proposal-Fassung stammt vom August 2025. Damals standen noch window.navigator.modelContext und provideContext() im Vordergrund. Inzwischen liegt der Schwerpunkt auf document.modelContext. Seit Chrome 150 wird die frühere navigator.modelContext-Oberfläche in der Chrome-Dokumentation als veraltet behandelt.

Für Entwickler ist das keine akademische Versionsfrage. Beispielcode aus dem ersten Quartal 2026 kann bereits strukturell falsch sein.

Wer WebMCP evaluieren möchte, sollte deshalb nicht einfach Snippets aus älteren Blogbeiträgen übernehmen. Die aktuelle Spezifikation, Implementierungsdokumentation und offenen Issues gehören zur technischen Prüfung dazu.

Chrome startete 2026 zunächst eine Early Preview und später einen Origin Trial. Die zum Recherchezeitpunkt dokumentierte Implementierung umfasst auch spezielle Entwicklungs- und Debuggingfunktionen. Edge führt ebenfalls einen experimentellen Origin Trial, Brave nennt WebMCP-Unterstützung im Zusammenhang mit Leo AI.

Bei Firefox und Safari beziehungsweise WebKit ist die Lage zurückhaltender. Das Dossier dokumentiert Standardspositionen und Tracking, aber keine mit Chrome vergleichbare experimentelle Produktunterstützung. Browserübergreifende Stabilität kann deshalb noch nicht vorausgesetzt werden.

Besonders relevant für Websitebetreiber ist die Integration auf Agentenseite. OpenAI bezeichnet seine Umsetzung als „Site tools“ und beschreibt sie als Implementierung des vorgeschlagenen WebMCP-Modells.

Dabei können Website und Agent dieselbe geöffnete Seite und deren angemeldete Session verwenden. Eine separate MCP-Verbindung ist für Site Tools laut den im Dossier ausgewerteten OpenAI-Unterlagen nicht erforderlich. Die tatsächliche Unterstützung hängt allerdings von Modell, Rollout und Website ab.

Das ist ein starkes Signal für die Richtung des Ökosystems. Ein Beleg für flächendeckende Adoption ist es noch nicht.

Gerade bei neuen KI-Technologien kursieren schnell konkrete Effizienzwerte. Bei WebMCP ist Zurückhaltung angebracht.

Das Dossier findet zum Stichtag keinen etablierten, herstellerübergreifenden Benchmark, der das aktuelle document.modelContext systematisch gegen DOM-, Vision- oder klassische Browser-Automation vergleicht. Ebenso fehlen belastbare öffentliche ROI-, Conversion- und Umsatzdaten produktiver Großimplementierungen.

Auch die gelegentlich genannte Zahl von 67,6 Prozent geringeren Processing-Anforderungen darf nicht ohne Weiteres auf das heutige WebMCP übertragen werden. Sie stammt aus einem älteren Paper, das unter „webMCP“ ein anderes Konzept mit der Bezeichnung „Web Machine Context & Procedure“ beschreibt.

Für Unternehmen bedeutet das: WebMCP lässt sich technisch sinnvoll evaluieren. Pauschale Wirtschaftlichkeitsversprechen lassen sich derzeit dagegen kaum seriös begründen.

Die sinnvollsten ersten WebMCP-Anwendungen sind nicht unbedingt diejenigen mit der spektakulärsten Automatisierung. Technisch attraktiver sind zunächst klar definierte, risikoarme Aktionen.

Eine Produktsuche ist ein gutes Beispiel. Statt Kategorien, Varianten und IDs aus einer visuellen Oberfläche zu rekonstruieren, erhält ein Agent strukturierte Suchparameter und definierte Ergebnisse. Die sichtbare Website kann anschließend trotzdem aktualisiert werden, sodass der Nutzer die Auswahl nachvollziehen und weiterbearbeiten kann.

Ähnlich verhält es sich mit komplexeren Formularen. Ein Agent muss dann nicht interpretieren, ob „Name“ einen vollständigen Namen oder getrennte Felder meint. Die Website kann die Bedeutung explizit beschreiben und ihre bereits vorhandenen HTML-Validierungen weiterverwenden.

Das ist weniger spektakulär als ein vollständig autonomer Kaufprozess, in vielen Projekten aber wesentlich wertvoller. Such- und Formularprozesse sind häufig, klar abgrenzbar und vergleichsweise gut messbar.

Bei Sodah betrachten wir Agentenfähigkeit nicht erst seit WebMCP als isoliertes Zukunftsthema. Im Webdesign nutzen wir bereits die vorhandenen Standardmechanismen von WordPress, um MCP- beziehungsweise agentenfähige Funktionen in reale Websiteprozesse einzubinden.

Dafür haben wir ein eigenes Plugin entwickelt. Es ermöglicht unter anderem, dass KI-Systeme Inhalte beziehungsweise Angebote direkt auf der Website durchsuchen können. Ebenso können definierte Aktionen einen Kontaktprozess auslösen, beispielsweise per E-Mail oder über einen Zapier-Hook, der anschließend mit ERP- oder CRM-Systemen weiterarbeitet.

Diese Lösung ist nicht automatisch mit der aktuellen WebMCP-API rund um document.modelContext gleichzusetzen. Die Unterscheidung ist wichtig. Sie zeigt aber sehr konkret, dass Unternehmen ihre Websites schon heute so strukturieren können, dass KI nicht nur Inhalte liest, sondern mit sauber definierten Funktionen und Businessprozessen interagiert.

Für Sodah ist das auch eine Frage der technischen Tiefe. Von zehn Teammitgliedern arbeiten fünf als spezialisierte Entwickler in Full-Stack-, Frontend- oder Backend-Rollen. Bei Themen wie WebMCP reicht es nicht, ein zusätzliches Attribut in ein Formular einzubauen. Entscheidend sind Datenmodelle, Berechtigungen, Schnittstellen, Zustände, Validierung und die Integration in bestehende Systeme.

Gerade bei WordPress entsteht dadurch eine interessante Entwicklungsperspektive: Bestehende CMS-Funktionen können heute bereits für agentische Workflows geöffnet werden, während WebMCP künftig einen standardisierteren browserseitigen Zugang ergänzen könnte.

Ein strukturiertes Tool ist nicht automatisch sicherer als ein Button. Es verlagert die Angriffsfläche.

Die WebMCP-Spezifikation behandelt ausdrücklich neue Threat Vectors und Privacy-Risiken. Ein Agent kann in einer angemeldeten Browser-Session unter Umständen auf dieselbe Identität, Personalisierung oder dieselben Berechtigungen zugreifen wie der Nutzer.

Ein zentraler Grundsatz lautet: Der WebMCP-Aufruf darf keine serverseitige Autorisierung ersetzen.

Wenn ein Agent beispielsweise cancel_order, change_address oder publish_content aufruft, muss das Backend weiterhin prüfen, ob der angemeldete Nutzer diese Aktion tatsächlich durchführen darf.

Besonders problematisch wird es, wenn die Toolimplementierung einen anderen technischen Pfad nutzt als die normale Benutzeroberfläche. Die Spezifikation warnt ausdrücklich vor solchen Validation Bypasses. Tool und UI sollten deshalb möglichst dieselbe autoritative Business- und Validierungsschicht verwenden.

Das ist ein klassisches Backend-Thema. Genau deshalb sollte WebMCP nicht allein im Frontend gedacht werden.

Eine sichtbare Bestätigungsschaltfläche vermittelt zunächst Sicherheit. Technisch genügt sie jedoch nicht immer.

Das Dossier verweist auf einen dokumentierten Fall aus Issue #288, bei dem ein Agent zunächst ein Tool verwendete und anschließend über klassische UI-Automation selbst den vorgesehenen Approval-Button betätigte.

Damit entsteht eine grundsätzliche Architekturfrage: Wer kontrolliert die eigentliche Autorität?

Wenn derselbe Agent sowohl strukturierte Tools als auch Maus- und Tastatursteuerung besitzt, kann eine lediglich optisch getrennte Bestätigung unzureichend sein. Bei Käufen, Veröffentlichungen, Löschungen oder anderen irreversiblen Aktionen braucht es deshalb eine Freigabeschicht, die der Agent nicht einfach selbst bedienen kann.

Moderne Websites bestehen selten aus Code einer einzigen Quelle. Tracking, Payment, Chats, Widgets und andere Drittanbieterkomponenten gehören zum Alltag.

WebMCP berücksichtigt deshalb Origin-Grenzen und Permissions Policy. Cross-Origin-Zugriffe benötigen explizite Freigaben, unter anderem über die tools Permissions Policy und exposedTo.

Chrome setzt außerdem Origin Isolation voraus. Bestimmte Legacy-Konfigurationen können die API dadurch vollständig deaktivieren.

Auch das verdeutlicht den Charakter von WebMCP: Es ist keine zusätzliche Marketingfunktion, sondern greift direkt in das Sicherheitsmodell moderner Webanwendungen ein.

WebMCP schafft einen neuen technischen Zugriffspfad auf Daten. Die bestehenden Datenschutzpflichten bleiben bestehen.

Besonders relevant sind Datenminimierung, Privacy by Design und der Umgang mit angemeldeten Sessions. Toolschemas sollten nur die Informationen abfragen oder zurückgeben, die für die jeweilige Aufgabe benötigt werden. Wenn Daten an externe Agenten- oder Modellanbieter übertragen werden, gelten weiterhin die üblichen Anforderungen an Datenverarbeitung und gegebenenfalls Drittlandtransfers.

Auch der EU AI Act definiert WebMCP nicht als eigene Technologieklasse. Die regulatorische Beurteilung hängt vom konkreten KI-System, dessen Rolle und dem jeweiligen Anwendungsfall ab, nicht allein davon, ob document.modelContext eingesetzt wird.

Ein vollständiger agentischer Checkout ist selten der beste Einstieg.

Das Dossier leitet aus der aktuellen Sicherheits- und Implementierungslage einen pragmatischen Migrationspfad ab: zunächst Suche, Filter und Lookups, danach reversible Zustandsänderungen, anschließend Vorschläge oder Entwürfe und erst deutlich später irreversible Schreibaktionen mit eigener Autorisierung.

Die Versuchung ist groß, jede vorhandene Backendfunktion auch als WebMCP-Tool anzubieten. Technisch kann genau das zum Problem werden.

Große Toolsets erhöhen die Auswahlkomplexität für das Modell, vergrößern die Angriffsfläche und verschärfen Fragen rund um dynamische Verfügbarkeit. Die laufenden Diskussionen zu Namespaces, dynamischen Tooldefinitionen und „Tool Explosion“ entstehen genau aus diesem Problem.

Ein Tool sollte deshalb eine klare Nutzerintention repräsentieren. Seine Beschreibung muss diskriminierend genug sein, damit ein Agent entscheiden kann, wann dieses Tool und nicht ein ähnliches verwendet werden soll.

Aus Frontend-Entwicklung wird damit zunehmend Contract Design.

Chrome empfiehlt isolierte Tool-Evals, bevor komplette Journeys getestet werden. Sinnvolle Kennzahlen sind unter anderem Tool Selection, Argument Accuracy, Task Success, Anzahl der Tool Calls, zusätzliche UI-Schritte, Laufzeit, Tokenverbrauch und sicherheitsrelevante Fehlaktionen.

Für ein reales Projekt könnten Sie beispielsweise messen, wie häufig ein Agent das richtige Suchtool auswählt, wie oft ungültige Produkt-IDs übergeben werden, wie viele Retries notwendig sind oder bei welchem Anteil der Aufgaben anschließend doch klassische Browser-Automation benötigt wird.

Das liefert wesentlich mehr Erkenntnis als eine pauschale Aussage wie „WebMCP ist schneller“.

WebMCP zeigt eine Entwicklung, die über die konkrete Spezifikation hinausgeht.

Websites werden künftig nicht nur für visuelle Nutzbarkeit und klassische API-Nutzung entworfen. Zusätzlich entsteht eine maschinenlesbare Interaktionsschicht für Agenten. Dazu gehören Toolnamen, Schemata, Permissions, dynamische Verfügbarkeit, Refusals, Lifecycle, Write Boundaries und automatisierte Evals. Das Dossier beschreibt genau diese Contract-Fragen als eine neue Frontend- und Product-Engineering-Aufgabe.

Für Unternehmen bedeutet das nicht, dass jede Website sofort WebMCP implementieren sollte. Wer heute allerdings neue Portale, Shops, Plattformen oder komplexe WordPress-Systeme entwickelt, sollte die Architektur so aufbauen, dass Businesslogik nicht untrennbar mit einzelnen Buttons und UI-Pfaden verbunden ist.

Das erleichtert klassische APIs, Automatisierung, MCP-Integrationen und später auch WebMCP.

Genau dort liegt aus unserer Sicht bei Sodah der relevante technische Hebel: nicht möglichst früh ein neues Label auf eine Website zu setzen, sondern die darunterliegenden Systeme so sauber zu bauen, dass strukturierte Agenteninteraktionen kontrolliert, testbar und wartbar werden.