Ein KI-Agent findet eure Produktseite. Er kann den Text lesen, die Preise zitieren, euch vielleicht sogar in einer AI-Overview erwähnen. Aber kann er auch den Warenkorb füllen, einen Filter setzen oder einen Checkout abschließen? Genau das ist die Frage, die WebMCP beantwortet, und genau da trennt sich gerade ein neues Spielfeld von dem, worüber die meisten aktuell sprechen.

Die kurze Antwort: Was ist WebMCP?

WebMCP ist ein vorgeschlagener Web-Standard (Draft-Spezifikation unter webmachinelearning/webmcp, veröffentlicht am 18. Mai 2026, zuletzt aktualisiert am 9. Juni 2026), mit dem Websites strukturierte Tools für KI-Agenten deklarieren. Statt dass ein Agent raten muss, wofür ein Button da ist, sagt die Seite es ihm direkt: "Dieses Element ist ein Checkout-Tool, es erwartet diese Parameter, es liefert diese Antwort." Chrome unterstützt WebMCP aktuell per Origin Trial ab Version 149, lokal testbar über chrome://flags/#enable-webmcp-testing. Angular hat bereits experimentelle Unterstützung angekündigt.

Der zentrale Begriff dahinter ist Actuation: der Moment, in dem ein Agent nicht nur liest, sondern handelt, also klickt, tippt, absendet, wie ein menschlicher Nutzer es tun würde. WebMCP macht Actuation zuverlässiger, weil die Website den Zweck eines Elements deklariert, statt dass der Agent ihn interpretieren muss.

Zwei Hälften der KI-Sichtbarkeit, und warum die meisten nur eine kennen

Wenn heute über "KI-Sichtbarkeit" gesprochen wird, ist fast immer die erste Hälfte gemeint: Lesbarkeit. Kann ein Sprachmodell euren Content zitieren, versteht Perplexity eure Struktur, taucht ihr in einer Google-AI-Overview auf. Dafür gibt es inzwischen ein etabliertes Vokabular, GEO, AEO, Schema.org, Answer-Engine-Optimization (siehe unseren Vergleich SEO vs. GEO vs. AEO).

Die zweite Hälfte wird kaum besetzt: Handlungsfähigkeit. Kann derselbe Agent, der euch zitiert, auf eurer Storefront auch etwas tun. Einen Artikel in den Warenkorb legen, eine Verfügbarkeit prüfen, eine Buchung abschließen. Das ist keine Content-Frage mehr, sondern eine Architektur-Frage: Wie ist euer Frontend gebaut, und erlaubt diese Bauweise deklarierte, maschinenlesbare Interaktion.

Genau hier liegt der Punkt, den viele Agentic-Commerce-Diskussionen 2026 auslassen: Sie sprechen über Agenten, aber nicht darüber, was die Seite selbst können muss, damit ein Agent überhaupt sicher handeln kann. WebMCP ist der erste Standard, der diese Lücke technisch konkret macht.

Wie WebMCP technisch funktioniert

WebMCP bietet zwei Wege, Tools zu exponieren:

• Imperative API: Ihr definiert Tools direkt in JavaScript, zum Beispiel checkout(), filter_results(), navigate() oder Zugriff auf gemeinsamen Seiten-State. Jedes Tool bekommt ein JSON-Schema für Input und Output, das reduziert Halluzination, weil der Agent nicht raten muss, welche Parameter erwartet werden.
• Declarative API: Ihr annotiert bestehende HTML-Formulare direkt, ohne zusätzliche Tool-Definitionen zu schreiben. Das eignet sich für einfachere, formularbasierte Interaktionen.

Drei Bausteine tragen das Modell:

1. Discovery: Die Seite registriert ihre Tools, ein Agent kann sie beim Besuch der Seite entdecken.
2. JSON-Schemas: Inputs und Outputs sind explizit typisiert, das ist der Unterschied zu reinem "der Agent klickt auf gut Glück".
3. State: Tools teilen sich Seiten-Kontext, ein Agent muss den Zustand nicht aus dem DOM neu rekonstruieren.

Wichtig für Vertrauen und Brand-Kontrolle: Tools laufen sichtbar auf der Seite. Der Agent simuliert reale Interaktionen im UI, nicht in einem verborgenen Backend-Kanal. Euer Design bleibt sichtbar, eure Brand bleibt intakt, und bei sensiblen Aktionen wie einem Kauf kann die Seite einen Confirmation-Dialog verlangen, bevor die Aktion tatsächlich ausgeführt wird.

Sicherheit ist mitgedacht, nicht nachgereicht

WebMCP läuft ausschließlich in origin-isolierten Documents und wird über eine tools-Permissions-Policy gesteuert. Der Default ist self, cross-origin Iframes brauchen ein explizites allow="tools", um Tools zu exponieren. Das ist ein bewusster Unterschied zu vielen frühen Agent-Integrationen, die Tool-Zugriff nachträglich per Custom-Skript in bestehende Seiten schoben.

Wo WebMCP heute an Grenzen stößt

Ehrlich betrachtet ist WebMCP kein Wundermittel, sondern ein frühes, aber ernstzunehmendes Draft-Fundament:

• Browsing-Kontext nötig: Ein echter Tab, keine reine Headless-Anfrage. Das schließt manche Batch-Automatisierungs-Szenarien vorerst aus.
• Overhead bei komplexen Interfaces: Je mehr Interaktionsflächen eine Seite hat, desto mehr Tool-Definitionen braucht sie, das ist Pflege-Aufwand.
• Tool-Discoverability: Ein Client muss die Seite direkt besuchen, um ihre Tools zu finden. Es gibt noch keinen zentralen Katalog wie bei API-Marktplätzen.

Diese Grenzen sind der Grund, warum WebMCP eher als Baustein in einer größeren Frontend-Architektur gedacht werden sollte, nicht als Plugin, das man an ein bestehendes Setup anflanscht.

Die These: Actuation ist eine Architektur-Eigenschaft, kein Bolt-on

Genau das ist der Punkt, an dem viele Teams den falschen Schluss ziehen. Die naheliegende Reaktion auf WebMCP ist: "Wir bauen ein paar Tool-Definitionen dazu." Das funktioniert kurzfristig, löst aber nicht das eigentliche Problem. Ob ein Agent auf eurer Storefront wirklich handeln kann, entscheidet sich nicht an einem nachträglich aufgesetzten Skript, sondern daran, wie deterministisch euer Rendering ist, wie klar eure Komponenten strukturiert sind und ob eure Frontend-Schicht überhaupt ein stabiles Ziel für deklarierte Interaktion bietet.

Wir haben das bereits im Kontext von KI-Agenten und Guardrails beschrieben: Schema-getriebene Agenten brauchen ein Frontend, das ihnen klare Grenzen und klare Zusagen gibt, keine improvisierte DOM-Struktur, die sich bei jedem Redesign verschiebt (siehe Agentic Frontend Guardrails für schema-getriebene Agenten). Und wir haben gezeigt, warum ein Render-Contract, also eine verbindliche Zusage zwischen Backend-Daten und Frontend-Darstellung, die Voraussetzung für autonome Commerce-Interaktionen ist (siehe Der Frontend-Render-Contract für autonomen Commerce). WebMCP ist die konsequente Fortsetzung dieser Linie: ein Standard, der Actuation erst dann zuverlässig macht, wenn die Architektur darunter bereits sauber ist.

Das ist auch der Grund, warum wir bei Laioutr die Agentic Frontend Management Platform so bauen, dass Human-Designer und KI-Agenten dieselbe Komponenten-Bibliothek bedienen. Wenn Komponenten deterministisch gerendert werden und ihre Bedeutung (Preis, Verfügbarkeit, Warenkorb-Aktion) strukturell klar ist, ist der Weg zu deklarierten WebMCP-Tools kein Sprung mehr, sondern eine logische Erweiterung des bestehenden Component-Layers. Konkret heißt das: Wenn eine Storefront mit klar definierten Sections und Blöcken aufgebaut ist, in denen jede Komponente ihre Funktion (Produktkarte, Filter, Checkout-Schritt) explizit kennt, liegt der nächste Schritt nahe, genau diese Funktionen als WebMCP-Tools zu deklarieren, statt sie aus generiertem HTML zu erraten. Wir arbeiten an dieser Verbindung aktiv, an dieser Stelle bleiben wir bewusst auf der Vision-Ebene, konkrete Feature-Details folgen, sobald der Standard aus dem Origin-Trial-Stadium heraus ist.

Was heißt das für Marketing- und Product-Owner?

Wenn ihr nicht täglich mit JSON-Schemas arbeitet, reicht dieser Kern: Actuation entscheidet, ob eure Kampagnen-Landingpage, euer Konfigurator oder euer Checkout für KI-Agenten nur "lesbar" oder auch "nutzbar" ist. Ein Agent, der eine Reise bucht, ein Formular ausfüllt oder eine Diagnose anfordert, tut das nur zuverlässig, wenn die Seite ihm sagt, welche Aktion welchen Effekt hat. Das ist relevant für Support-Flows, Buchungsstrecken, strukturierte Formulare (zum Beispiel submit_application) und Human-first-Felder wie Datumsauswahl. Wer heute schon in Personalisierung und Conversion-Optimierung investiert, investiert morgen in dieselbe Storefront-Basis für Agent-Handlungsfähigkeit, es ist derselbe Frontend-Layer, nur mit einem zweiten Publikum.

WebMCP und GEO/AEO: Die zwei Hälften zusammengeführt

Lesbarkeit und Handlungsfähigkeit sind kein Entweder-oder. Eine Storefront, die für Answer-Engines optimiert ist (siehe Answer Engine Optimization ist Architektur, kein Bolt-on und Die GEO-bereite Storefront: Frontend für AI-Answer-Engines), aber keine deklarierten Tools anbietet, wird zitiert, aber nicht genutzt. Eine Storefront, die WebMCP-Tools exponiert, aber für AI-Crawler unlesbar ist, wird genutzt, aber nie gefunden. Beides gehört in dieselbe Frontend-Strategie, mit demselben Schema.org-Fundament, derselben strukturierten Datenbasis, demselben deterministischen Rendering. Genau das bildet unsere SEO and GEO-Produktschicht ab, ergänzt um die Vision einer Storefront, die AI-Discoverability nicht nur als Lese-, sondern als Handlungsschicht denkt (siehe unsere Einordnung zu AI für Discoverability).

Auch das Interface-Modell ist verwandt, aber nicht identisch: Laioutr exponiert bereits eine eigene MCP-Schnittstelle für serverseitige Agenten, die mit der Plattform sprechen wollen. WebMCP verschiebt dasselbe Grundprinzip, deklarierte Tools statt interpretierter Absicht, in den Browser-Kontext, direkt auf die Storefront-Seite. Beide Schichten ergänzen sich, sie sind nicht dasselbe Protokoll.

Fazit

WebMCP ist ein frühes, aber technisch konkretes Signal: Die nächste Sichtbarkeits-Welle im E-Commerce entscheidet sich nicht nur an Content-Qualität, sondern an Frontend-Architektur. Wer heute in ein deterministisches, komponentenbasiertes Frontend investiert, baut die Grundlage, auf der Actuation morgen kein Sonderprojekt ist, sondern eine logische Erweiterung.

Häufige Fragen zu WebMCP

Was ist der Unterschied zwischen WebMCP und klassischem Web-Scraping durch KI-Agenten?

Beim Scraping interpretiert der Agent die Seite und muss raten, wofür ein Element gedacht ist. Bei WebMCP deklariert die Seite selbst ihre Tools inklusive JSON-Schema für Input und Output, der Agent muss nichts mehr interpretieren.

Ist WebMCP bereits produktiv einsetzbar?

WebMCP ist eine Draft-Spezifikation, verfügbar per Origin Trial ab Chrome 149 und lokal testbar über Chrome-Flags. Für produktive Breiteneinführung ist es noch zu früh, für die Architektur-Vorbereitung nicht.

Braucht WebMCP einen sichtbaren Browser-Tab?

Ja. WebMCP setzt einen echten Browsing-Kontext voraus, reine Headless-Batch-Anfragen sind damit nicht abgedeckt.

Wie hängt WebMCP mit GEO und AEO zusammen?

GEO und AEO optimieren, ob KI-Systeme euren Content zitieren (Lesbarkeit). WebMCP optimiert, ob ein Agent auf eurer Seite tatsächlich handeln kann (Handlungsfähigkeit). Beides zusammen ergibt vollständige KI-Sichtbarkeit.

Was hat WebMCP mit Laioutrs eigener MCP-Schnittstelle zu tun?

Laioutrs MCP-Interface bedient serverseitige Agenten, die mit der Plattform sprechen. WebMCP verschiebt dasselbe Prinzip, deklarierte statt interpretierte Tools, in den Browser, direkt auf die Storefront.

Über den Autor: Sebastian Langer ist Co-Founder und CTO von Laioutr. Er verantwortet die technische Architektur der Frontend Management Platform und beschäftigt sich mit der Frage, wie Frontend-Schichten für Menschen und KI-Agenten gleichermaßen zugänglich werden.