WebMCP: Websites für KI-Agenten nutzbar machen
WebMCP macht Funktionen einer Website als Tools für KI-Agenten aufrufbar. Stand in Chrome und ChatGPT, Haltung von Microsoft und Apple, Folgen für Unternehmen.
WebMCP macht Funktionen einer Website als Tools für KI-Agenten aufrufbar. Stand in Chrome und ChatGPT, Haltung von Microsoft und Apple, Folgen für Unternehmen.
Seit 2025 verhandeln Browser-Hersteller, Modellanbieter und Standardisierungsgremien darüber, wie eine Website mit einem KI-Agenten sprechen soll. WebMCP ist die derzeit sichtbarste Antwort auf diese Frage, und sie ist weiter fortgeschritten, als die meisten Unternehmen im deutschsprachigen Raum annehmen: In Chrome läuft ein Origin Trial, ChatGPT nutzt die Technologie im Browser seiner Desktop-App, Microsoft sitzt als Mitautor an der Spezifikation. Gleichzeitig hat Apple bei WebKit eine ausdrücklich ablehnende Position eingetragen. Diese Seite ordnet ein, was WebMCP technisch ist, wer dahintersteht, wo die Risiken liegen und was ein Unternehmen jetzt sinnvollerweise tut.
WebMCP ist ein vorgeschlagener Webstandard, mit dem eine Website ihre eigenen Funktionen als benannte, typisierte und beschriebene Werkzeuge an einen KI-Agenten übergibt. Statt dass ein Agent die Seite wie ein Mensch bedient, also Screenshots auswertet, das DOM ausliest, Buttons errät und Klickkoordinaten berechnet, bekommt er eine Liste aufrufbarer Funktionen mit klaren Eingabe- und Ausgabeschemata: search_flights, add_to_cart, book_appointment, filter_results.
Der Unterschied ist derselbe wie zwischen einer Fernsteuerung, die auf Bildschirmfotos zielt, und einer API. Die bisherige Agentensteuerung ist nicht-deterministisch und teuer: Ein verschobenes Layout, ein spät geladenes Werbeelement oder ein geändertes Label kann die gesamte Automatisierung brechen, und jede Bildanalyse kostet Zeit und Token. Ein früher Anwender, der WebMCP-Werkzeuge in die Testautomatisierung eingebaut hat, berichtete von rund 90 Prozent weniger Token-Verbrauch gegenüber dem üblichen Kreislauf aus Screenshot, Aktion und erneutem Screenshot, bei gleichzeitig höherer Wiederholbarkeit.
Wichtig für die Einordnung: WebMCP ist eine Ergänzung, keine Ablösung der bestehenden Website. Die Werkzeuge werden zusätzlich zur normalen Oberfläche registriert, sie laufen sichtbar auf der Seite ab, und Browser ohne Unterstützung bedienen die Seite unverändert weiter. Es handelt sich also um eine progressive Erweiterung, die man schrittweise einführen kann, nicht um einen Parallelauftritt, der separat gepflegt werden müsste.
Die Spezifikation kennt zwei Wege, Werkzeuge bereitzustellen.
Der deklarative Weg annotiert bestehende HTML-Formulare mit zusätzlichen Attributen. Ein Suchformular bekommt einen Werkzeugnamen und eine Beschreibung, und der Agent weiß damit, wofür das Formular gedacht ist und wie es auszufüllen ist. Für Seiten, deren zentrale Funktionen ohnehin über Formulare laufen, ist das der günstigste Einstieg.
Der imperative Weg registriert Werkzeuge per JavaScript. Jedes Werkzeug bekommt einen Namen, eine Beschreibung, ein Eingabeschema nach JSON Schema und eine Ausführungsfunktion, die die bereits vorhandene Anwendungslogik aufruft:
if (typeof document.modelContext?.registerTool === "function") {
await document.modelContext.registerTool({
name: "check_availability",
description: "Prüft freie Termine für eine Filiale in einem Zeitraum.",
inputSchema: {
type: "object",
properties: {
branch: { type: "string" },
from: { type: "string" },
to: { type: "string" },
},
required: ["branch", "from"],
},
annotations: { readOnlyHint: true },
execute: async ({ branch, from, to }) => findSlots(branch, from, to),
});
}
Drei Eigenschaften der Spezifikation sind für die Bewertung im Unternehmen wesentlich. Erstens die Entdeckbarkeit: Es gibt einen einheitlichen Weg, wie eine Seite ihre Werkzeuge beim Agenten anmeldet. Zweitens die Schemata: Ein- und Ausgaben sind explizit typisiert, was Fehlinterpretationen des Modells deutlich reduziert. Drittens der Zustand: Der Agent kennt den aktuellen Kontext der Seite und weiß, worauf er gerade wirken kann.
Dazu kommen Absicherungen im Browser. Die Werkzeuge stehen nur in origin-isolierten Dokumenten zur Verfügung, damit die Herkunft während der gesamten Lebensdauer eines Werkzeugs stabil bleibt. Beide Schnittstellen unterliegen außerdem einer Permissions Policy, die standardmäßig nur die eigene Herkunft zulässt; fremde Inhalte in eingebetteten Rahmen dürfen also nicht ungefragt Werkzeuge anmelden. Für Beschreibungen und Ausgaben gelten enge Zeichenbudgets, unter anderem 500 Zeichen je Werkzeugbeschreibung und 1.500 Zeichen je Werkzeugausgabe, was zu präzisen, knappen Definitionen zwingt.
Das Model Context Protocol, kurz MCP, verbindet eine KI-Anwendung mit einem lokalen oder entfernten Server. Solche Werkzeuge funktionieren unabhängig davon, ob eine Seite geöffnet ist: Ein MCP-Server kann ein CRM abfragen oder Datensätze schreiben, ohne dass ein Browser beteiligt wäre.
WebMCP arbeitet dagegen vollständig auf der Client-Seite, im geöffneten Dokument, in der angemeldeten Sitzung der Nutzerin oder des Nutzers. Niemand muss vorher einen Server installieren oder eine Verbindung einrichten; der Agent findet die Werkzeuge beim Besuch der Seite. Das ist immer dann der richtige Weg, wenn Mensch und Agent dasselbe sehen sollen, etwa beim Bearbeiten eines Dokuments, beim Konfigurieren eines Produkts oder beim Auswerten eines Dashboards.
Beide Ansätze schließen sich nicht aus. Ein Unternehmen kann einen MCP-Server für sitzungsunabhängige Integrationen betreiben und zusätzlich seine Website mit WebMCP-Werkzeugen ausstatten. Die Entscheidung, was wo liegt, gehört in die Architekturphase und nicht ins Frontend-Backlog.
Die Lage ist unübersichtlich, und genau deshalb kursieren in Unternehmen falsche Annahmen. Der Stand, sortiert nach Akteuren:
Google treibt die Spezifikation und hat sie als erster Hersteller ausgeliefert. WebMCP ist seit Chrome 149 in einem Origin Trial verfügbar, für lokale Entwicklung lässt sich die Schnittstelle zusätzlich über ein Flag aktivieren. Vorgestellt wurde das Vorhaben im Umfeld der Entwicklerkonferenz im Frühjahr 2026, zusammen mit weiteren Bausteinen für agentisches Browsen.
Microsoft ist an der Spezifikation als Mitautor beteiligt; die Standardisierungsgremien führen den Vorschlag ausdrücklich als von Google und Microsoft eingebracht. Das passt zur Linie, die Microsoft seit dem Copilot-Modus im eigenen Browser und den Agenten-Funktionen in Windows verfolgt.
OpenAI hat WebMCP unter dem Namen "Site tools" im Browser der ChatGPT-Desktop-Anwendung umgesetzt. Findet der Agent auf einer Seite Werkzeuge, kann er sie in der laufenden, angemeldeten Sitzung verwenden; jede Ausführung durchläuft vorher eine Sicherheitsprüfung, und die Funktion lässt sich in den Einstellungen abschalten. Flankierend hat OpenAI zusammen mit mehreren Plattformanbietern ein Hackathon-Format aufgelegt, um die Verbreitung auf Websites zu beschleunigen.
Apple ist entgegen einer verbreiteten Annahme nicht an Bord. Das WebKit-Team hat Mitte 2026 eine förmliche Ablehnung eingetragen, versehen mit Bedenken zu Sicherheit, Datenschutz, API-Entwurf, Mehrfachbelegung bestehender Plattformfunktionen, Portierbarkeit, Internationalisierung und der Wahl des Standardisierungsgremiums. Das ist keine Formalie: Ohne WebKit gibt es auf iOS auf absehbare Zeit keine native Unterstützung.
Mozilla führt den Vorschlag in seinen Standards-Positionen, hat aber bislang keine abschließende Haltung veröffentlicht.
Die Standardisierung selbst läuft in einer Community Group des W3C, begleitet von einem Design-Review der Technical Architecture Group. WebMCP ist damit ein ernsthafter Vorschlag mit zwei großen Implementierern, aber kein verabschiedeter Standard. Wer heute investiert, investiert in eine wahrscheinliche, nicht in eine gesicherte Zukunft.
Die Verwirrung um Apples Haltung hat einen nachvollziehbaren Grund: Apple hat im Sommer 2026 einen eigenen MCP-Server für Safari veröffentlicht, zunächst in der Technology Preview. Der richtet sich an Entwicklerinnen und Entwickler und erlaubt es Coding-Agenten, eine echte Safari-Sitzung zu inspizieren, Konsolenausgaben und Netzwerkanfragen zu lesen und Seiten zu prüfen.
Das ist etwas anderes als WebMCP. Apples Server bedient einen Agenten von außen, für Entwicklung und Fehlersuche. WebMCP lässt umgekehrt die Website selbst Werkzeuge anbieten, für Endanwenderinnen und Endanwender. Apple unterstützt also MCP als Protokoll und lehnt WebMCP als Webplattform-Funktion ab. Wer diese beiden Meldungen zusammenzieht, kommt zu dem falschen Schluss, die gesamte Branche sei sich einig.
Für die Praxis heißt das: Rechnen Sie mit Chromium-Browsern und Agenten-Anwendungen als Zielumgebung, nicht mit flächendeckender Verfügbarkeit auf iPhones. Und rechnen Sie damit, dass die Sicherheitsbedenken, die WebKit formuliert hat, die weitere Entwicklung der Spezifikation prägen werden.
Die strategische Frage ist nicht, ob eine bestimmte Schnittstelle den Standardisierungsprozess übersteht. Sie lautet: Was passiert mit unserem digitalen Kanal, wenn ein wachsender Teil der Interaktionen nicht mehr von Menschen, sondern von deren Agenten ausgeführt wird?
Drei Effekte sind heute schon absehbar.
Auffindbarkeit verschiebt sich von Seiten zu Fähigkeiten. Ein Agent, der eine Aufgabe erledigen soll, bevorzugt Anbieter, deren Funktionen er zuverlässig aufrufen kann, gegenüber solchen, bei denen er sich durch mehrstufige Oberflächen raten muss. Wer Werkzeuge anbietet, wird für agentische Abläufe schlicht der günstigere Weg.
Konversionsstrecken werden kürzer und härter messbar. Buchung, Terminvergabe, Angebotsanfrage, Nachbestellung: Genau diese Strecken sind es, die ein Agent im Auftrag der Kundin abschließt. Wer sie sauber als Werkzeuge modelliert, erhält nebenbei eine belastbare Instrumentierung des eigenen Trichters.
Der Support verlagert sich. Ein erheblicher Teil der Serviceanfragen betrifft Vorgänge, die eigentlich in Selbstbedienung erledigt werden könnten, an denen Menschen aber scheitern. Werkzeuge, die den richtigen Vorgang direkt starten und Felder korrekt befüllen, senken dieses Volumen messbar.
Dem stehen Risiken gegenüber, die niemand ignorieren sollte: Wer Funktionen für Agenten öffnet, verschiebt einen Teil der Kontrolle über die eigene Kundenschnittstelle in eine fremde Anwendung. Diese Abwägung gehört auf die Geschäftsleitungsebene, nicht in eine Frontend-Entscheidung.
Die Autoren der Spezifikation weisen selbst darauf hin, dass Sprachmodelle anfällig für indirekte Prompt-Injection sind und dass die Freigabe eigener Funktionen ein Risiko schafft, das verstanden und gesteuert werden muss. Vier Punkte gehören in jede Bewertung.
Fremde Inhalte sind nicht vertrauenswürdig. Daten, die von außen in eine Werkzeugantwort geraten, etwa Nutzerkommentare oder Lieferantentexte, müssen als solche gekennzeichnet werden, damit der Agent sie mit erhöhter Vorsicht behandelt. Umgekehrt können rein lesende Operationen als solche markiert werden, damit nicht jede harmlose Abfrage eine Rückfrage beim Menschen auslöst.
Berechtigungen dürfen nicht am Werkzeug hängen. Ein Werkzeug ist ein zusätzlicher Aufrufweg auf bestehende Logik, nicht ein zweiter, laxerer Zugang. Authentifizierung, Autorisierung und Eingabevalidierung der Anwendung müssen unverändert greifen.
Veraltete Regeln werden zum operativen Risiko. Wenn ein Erstattungsvorgang aufrufbar ist, die hinterlegte Erstattungsregel aber überholt, führt ein Agent die falsche Aktion sauber und schnell aus. Genau darin liegt der Unterschied zu einem Menschen, der stutzt. Ebenso können Rechtelücken sichtbar werden, die bisher dadurch verdeckt waren, dass niemand sie systematisch ausgenutzt hat.
Freigaben brauchen einen definierten Halt. Für alles, was Geld bewegt, Daten löscht oder nach außen kommuniziert, gehört eine ausdrückliche Bestätigung in den Ablauf. Die Browser-Implementierungen sehen dafür Mechanismen vor, aber die fachliche Entscheidung, welche Aktion bestätigungspflichtig ist, kann Ihnen niemand abnehmen.
Wir empfehlen deshalb, WebMCP-Werkzeuge wie eine öffentliche Schnittstelle zu behandeln: mit Bedrohungsmodell, Protokollierung, Test und regelmäßiger Überprüfung. Für Unternehmen, die ohnehin an einer Governance-Struktur für KI arbeiten, ist das kein Sonderthema, sondern ein weiterer Anwendungsfall derselben Regeln.
WebMCP ist kein Allheilmittel, und die Dokumentation der Beteiligten benennt die Grenzen offen. Die Schnittstelle ist auf lokale Abläufe mit einem Menschen im Ablauf ausgelegt, nicht auf serverseitige Massenautomatisierung. Bei sehr komplexen Oberflächen entsteht echter Umbauaufwand, weil Anwendungs- und Oberflächenzustand sauber getrennt werden müssen. Und die Entdeckbarkeit bleibt vorerst begrenzt: Ein Agent erfährt erst beim Besuch einer Seite, ob sie Werkzeuge anbietet, was die Frage nach einem Verzeichnis oder einem anderen Signal offen lässt.
Hinzu kommt die naheliegende Sorge, dass Agenten die kommerzielle Oberfläche umgehen. Wenn Werkzeuge die Kernaufgabe direkt erledigen, entfallen Zwischenseiten, auf denen heute beworben, verglichen und quergesteuert wird. Diese Frage sollte man bewusst beantworten, bevor die ersten Werkzeuge live gehen.
Wir empfehlen kein Programm, sondern einen eng abgegrenzten Piloten von vier bis sechs Wochen, der in derselben Logik arbeitet wie unsere übrigen Pilotprojekte.
Zuerst wählen Sie einen einzigen Ablauf mit klarem Nutzen und geringem Schadenspotenzial: eine Verfügbarkeitsabfrage, eine Filter- oder Suchfunktion, eine Terminvergabe. Rein lesende Werkzeuge sind der beste Anfang, weil sie den Wert zeigen, ohne den Sicherheitsraum zu vergrößern.
Danach modellieren Sie zwei bis fünf Werkzeuge auf bestehender Anwendungslogik, mit engen Schemata und knappen Beschreibungen. Anschließend prüfen Sie das Ergebnis nicht nur funktional, sondern mit szenariobasierten Auswertungen: Erledigt ein Agent typische Aufträge zuverlässig, und was passiert bei unklaren oder böswilligen Eingaben.
Am Ende steht eine Entscheidungsvorlage mit Zahlen: Erfolgsquote je Szenario, benötigte Schritte, Kosten pro Vorgang, gefundene Risiken. Auf dieser Grundlage lässt sich seriös entscheiden, ob und wie weit ausgebaut wird.
WebMCP ist kein isoliertes Frontend-Thema. Es berührt drei Felder, die wir in Mandaten ohnehin bearbeiten: die Priorisierung von Anwendungsfällen, die Governance für den produktiven Betrieb und die Frage, wer eine neue Fähigkeit dauerhaft verantwortet.
Deshalb behandeln wir es wie jeden anderen Kandidaten für einen Piloten und nicht als Sonderfall, den man aus Aktualitätsgründen vorzieht. Wenn Ihre wichtigsten Vorgänge heute intern stocken, ist ein Kundenservice- oder Dokumentenagent der wirksamere erste Schritt. Wenn Ihr digitaler Kanal dagegen der Kern des Geschäfts ist, gehört WebMCP in die nächste Planungsrunde, mit einem kleinen, gut abgesicherten Anfang.
Eine erste Einordnung Ihrer Ausgangslage liefert unser KI-Readiness-Check. Wenn Sie die Frage konkret für Ihre Plattform klären wollen, vereinbaren Sie ein Strategiegespräch, oder sehen Sie sich an, wie wir Strategie und Governance und Workshops miteinander verbinden.
Muss ich meine Website umbauen? Nein. WebMCP wird zusätzlich registriert. Die bestehende Oberfläche bleibt unverändert, und Browser ohne Unterstützung merken nichts davon.
Funktioniert das auf dem iPhone? Auf absehbare Zeit nicht nativ, weil Apple die Schnittstelle bei WebKit abgelehnt hat. Agenten-Anwendungen mit eigenem Browser sind davon nicht zwingend betroffen.
Ist das schon stabil genug für den Produktivbetrieb? Die Spezifikation ist in Bewegung, und Details können sich ändern. Für einen abgegrenzten, lesenden Anwendungsfall ist der Aufwand trotzdem überschaubar und der Lerngewinn hoch.
Was kostet ein Einstieg? Der Aufwand hängt fast vollständig davon ab, wie sauber Ihre Anwendungslogik von der Oberfläche getrennt ist. Bei einer modernen Anwendung sind zwei bis fünf Werkzeuge Tagewerk, bei einer gewachsenen Oberfläche kann derselbe Umfang mehrere Wochen bedeuten.