Menschen sehen ein Suchfeld, einen Filter und einen blauen Knopf. Ein KI-Agent sieht zunächst Pixel, DOM-Knoten und viele mögliche Aktionen. Er muss herausfinden, welches Element die gewünschte Funktion auslöst. WebMCP dreht dieses Verhältnis um: Die Webseite erklärt selbst, welche Werkzeuge sie anbietet, welche Eingaben sie benötigen und welche Funktion beim Aufruf ausgeführt wird.

Die Idee wirkt zunächst wie ein kleines technisches Detail. Tatsächlich könnte sie verändern, wie Agenten mit Webanwendungen zusammenarbeiten. Statt eine für Menschen gebaute Oberfläche Schritt für Schritt zu imitieren, erhält der Agent eine strukturierte Schnittstelle direkt aus der geöffneten Seite. Der Mensch sieht weiterhin dieselbe Anwendung, denselben Zustand und das Ergebnis der Aktion.

Ein KI-Agent ruft über WebMCP ein klar beschriebenes Werkzeug einer geöffneten Webseite auf und erzeugt ein sichtbares Ergebnis.
WebMCP macht vorhandene Webfunktionen als strukturierte Werkzeuge sichtbar. Die Ausführung bleibt in der geöffneten Webseite und kann deren Oberfläche aktualisieren.

Das heutige Problem: Agenten müssen raten

Browser-Agenten können Webseiten bereits über Screenshots, HTML und simulierte Klicks bedienen. Für universelle Aufgaben ist das erstaunlich leistungsfähig. Es bleibt aber indirekt: Der Agent muss die Bedeutung der Oberfläche rekonstruieren, passende Elemente finden und nach jedem Schritt prüfen, ob sich die Seite wie erwartet verändert hat.

1 · Das heutige Problem
Ohne strukturierte Werkzeuge muss ein Agent aus Darstellung und HTML ableiten, welche Interaktion zum Ziel führt.

Diese Art der Bedienung ist anfällig für Layoutänderungen, mehrdeutige Beschriftungen, verdeckte Elemente und komplexe Zustände. Ein visuell ähnlich aussehender Knopf kann eine Vorschau öffnen, eine Suche starten oder bereits eine endgültige Aktion auslösen. Der Agent arbeitet mit Wahrscheinlichkeiten, wo die Anwendung eigentlich bereits über präzise Funktionen verfügt.

Die Idee: Die Webseite beschreibt ihre Fähigkeiten

WebMCP ist eine JavaScript-Schnittstelle, über die Webanwendungen ihre Funktionen als Tools für KI-Agenten bereitstellen können. Ein Tool besteht im Kern aus einem eindeutigen Namen, einer Beschreibung, einem strukturierten Eingabeschema und einer ausführbaren Funktion. Der aktuelle Community-Group-Entwurf stellt dafür document.modelContext.registerTool() bereit.

2 · Ein klar beschriftetes Werkzeugfach
Der Agent erhält keine Liste möglicher Klicks, sondern einen semantischen Vertrag für eine konkrete Fähigkeit.

Damit kann ein Agent erkennen: Dieses Werkzeug sucht Artikel, erwartet einen Text als Suchbegriff und ruft eine definierte Funktion auf. Er muss nicht mehr erraten, welches Feld und welcher Knopf zusammengehören. Die Webanwendung entscheidet bewusst, welche ihrer Fähigkeiten sie anbietet.

Mensch und Agent arbeiten auf derselben Seite

Der besondere Reiz von WebMCP liegt im gemeinsamen Zustand. Das Werkzeug läuft in der geöffneten Webanwendung und kann vorhandene clientseitige Logik nutzen. Wenn es eine Suche ausführt, einen Filter setzt oder einen Entwurf vorbereitet, kann die sichtbare Oberfläche denselben Zustand anzeigen. Der Mensch bleibt nicht in einem getrennten Agenten-Backend zurück, sondern kann Ergebnis und Folgen direkt prüfen.

3 · Gemeinsamer Arbeitszustand
WebMCP unterstützt kollaborative Abläufe: Der Agent handelt strukturiert, die Wirkung bleibt in der gemeinsamen Oberfläche sichtbar.

Das ist ein wichtiger Unterschied zu einer rein serverseitigen Automation. WebMCP nutzt den Kontext der aktiven Seite: angemeldete Sitzung, aktuelle Auswahl, sichtbare Daten und laufende Anwendungslogik. Genau deshalb ist es mächtig – und genau deshalb müssen Berechtigungen und sensible Aktionen besonders sorgfältig behandelt werden.

WebMCP ist nicht dasselbe wie ein MCP-Server

4 · Zwei unterschiedliche Orte für Werkzeuge
Beide Ansätze können sich ergänzen. Sie lösen jedoch unterschiedliche Integrationsprobleme.

Der WebMCP-Entwurf formuliert es anschaulich: Eine Seite mit WebMCP kann als MCP-Server gedacht werden, dessen Tools in clientseitigem JavaScript statt in einem Backend implementiert sind. Technisch bleibt der Ausführungsort aber entscheidend. Ein klassischer MCP-Server verbindet Agenten mit einem separaten Dienst, einer Datenquelle oder einer API. WebMCP macht Fähigkeiten der aktiven Seite verfügbar.

Auch MCP Apps sind ein anderer Baustein. Sie erlauben MCP-Servern, interaktive Oberflächen in einem Agenten-Host bereitzustellen. WebMCP beginnt dagegen bei einer bereits geöffneten Webseite und beschreibt deren Funktionen für Agenten. Ein System kann alle drei Konzepte kombinieren, sollte sie aber nicht sprachlich vermischen.

Eine bestehende Webseite nachrüsten

Für WebMCP muss eine Anwendung nicht neu gebaut werden. Die sinnvollste Strategie ist, eine vorhandene, klar begrenzte Funktion zusätzlich für Agenten zu beschreiben. Ein guter Einstieg liest oder filtert Daten. Kaufen, löschen oder endgültig senden sind schlechte erste Kandidaten, weil Fehler dort unmittelbar reale Folgen haben.

A · Mit einer kleinen Aktion beginnen
Je höher die Auswirkung einer Aktion, desto wichtiger werden explizite Bestätigung, Autorisierung und Auditierbarkeit.

1. Vorhandene Logik wiederverwenden

Ein WebMCP-Tool sollte keinen geheimen Hintereingang schaffen. Der sichtbare Knopf und der Agentenaufruf sollten dieselbe geprüfte Anwendungsfunktion verwenden. So bleiben Validierung, Fehlerbehandlung und Geschäftsregeln konsistent.

B · Ein gemeinsamer Ausführungspfad
Unterschiedliche Oberflächen sollten nicht zu unterschiedlichen Sicherheits- und Geschäftsregeln führen.

2. Deklarativ oder imperativ beschreiben

Der Entwurf sieht zwei Wege vor. Ein vorhandenes HTML-Formular kann mit Attributen wie toolname und tooldescription beschrieben werden. Der Browser leitet daraus ein Tool und sein Eingabeschema ab. Für komplexere, JavaScript-getriebene Funktionen registriert die Anwendung ein Tool direkt über document.modelContext.registerTool().

C · Zwei Wege zur agentenfähigen Seite
Semantische Formulare eignen sich für den deklarativen Weg; komplexe Anwendungszustände eher für die imperative Registrierung.

3. Den Werkzeugvertrag klar formulieren

Name, Beschreibung, Eingabeschema und Ausführung bilden den Vertrag zwischen Anwendung und Agent. Die Beschreibung sollte nicht nur sagen, was ein Tool heißt, sondern wann es sinnvoll ist und welche Nebenwirkungen es besitzt. Das Schema sollte nur die wirklich benötigten Daten zulassen.

D · Vier Bausteine eines Tools
await document.modelContext.registerTool({
  name: "search-articles",
  description: "Artikel nach Thema suchen",
  inputSchema: {
    type: "object",
    properties: { query: { type: "string" } },
    required: ["query"]
  },
  async execute({ query }) {
    return searchArticles(query);
  }
});
Das Beispiel ist bewusst vereinfacht. API-Details können sich während der Entwurfsphase noch ändern.

Strukturiert bedeutet nicht automatisch vertrauenswürdig

Ein strukturiertes Tool kann genauso falsch implementiert, zu weit berechtigt oder irreführend beschrieben sein wie jede andere Schnittstelle. Der WebMCP-Entwurf nennt unter anderem Prompt Injection in Tool-Metadaten und Ausgaben, missverständlich beschriebene Nebenwirkungen, Datenschutzrisiken durch zu viele Parameter und Unterschiede zwischen UI- und Tool-Ausführungspfaden.

5 · Jeder Aufruf braucht Schutzprüfungen
Ein Agentenaufruf muss mindestens dieselben Kontrollen durchlaufen wie die entsprechende menschliche Interaktion.

Besonders kritisch ist die aktive Sitzung. Eine geöffnete Seite besitzt möglicherweise Cookies und Berechtigungen, mit denen ein Tool Einkäufe abschließen, Einstellungen verändern oder private Daten weitergeben könnte. Die Tool-Beschreibung allein beweist nicht, dass die Implementierung genau das tut, was sie verspricht.

Meine wichtigste Architekturregel: WebMCP darf einen Bedienweg ergänzen, aber keine Sicherheitsgrenze umgehen. Autorisierung, Validierung, Bestätigung und Audit-Logging gehören in die gemeinsame Anwendungslogik – nicht nur in die sichtbare Oberfläche.

Noch ein Entwurf, kein fertiger Webstandard

Der aktuelle Text ist ein Draft Community Group Report der W3C Web Machine Learning Community Group vom 26. August 2026. Er ist ausdrücklich weder W3C-Standard noch Teil des W3C Standards Track. API-Details, Browserunterstützung und Sicherheitsmechanismen können sich daher noch ändern.

Wer heute experimentiert, sollte WebMCP über Feature Detection kapseln, Tool-Registrierungen klein halten und Änderungen am Entwurf verfolgen. Produktive Kernabläufe dürfen nicht davon abhängen, dass eine experimentelle Browser-API überall verfügbar ist.

Gerade deshalb ist jetzt ein guter Zeitpunkt für Prototypen. Entwickler können prüfen, welche Funktionen ihrer Anwendungen sich sinnvoll als Agentenwerkzeuge beschreiben lassen, wo Zustands- und Lifecycle-Probleme entstehen und welche Bestätigungen Menschen tatsächlich benötigen. Solche Erfahrungen helfen, den Entwurf mit realen Anforderungen zu konfrontieren.

Fazit: Eine kleine Schnittstelle mit großer Wirkung

WebMCP ersetzt weder gute Benutzeroberflächen noch klassische APIs oder MCP-Server. Es ergänzt die geöffnete Webseite um eine agentenlesbare Werkzeugschicht. Der Agent bekommt klare Namen, Beschreibungen und Eingaben; der Mensch behält den sichtbaren Zustand und die Kontrolle.

Der pragmatische Einstieg ist einfach: eine vorhandene, risikoarme Funktion auswählen, dieselbe geprüfte Anwendungslogik wiederverwenden, einen engen Werkzeugvertrag formulieren und jeden Aufruf wie einen normalen Benutzeraufruf absichern.

Kurz gesagt: WebMCP macht aus einer Webseite kein autonomes System. Es gibt Agenten einen klar beschrifteten Werkzeugkasten innerhalb der Seite – und macht dadurch Zusammenarbeit weniger fragil und besser überprüfbar.

Weiterführende Quellen

WebMCPMCPKI-AgentenAgentic WebWebentwicklungBrowser-AutomationSecurity
Artikel teilen oder für später merken. Auf LinkedIn teilen