WebMCP ist ein vorgeschlagener Webstandard, den Google und Microsoft im W3C vorantreiben. Er erlaubt einer Website, ihre Formulare und Funktionen als Tools zu beschreiben, die ein KI-Agent im Browser aufrufen kann. Statt dass ein Agent anhand von Pixeln rät, welchen Button er klicken soll, sagt ihm die Seite: Dieses Formular fordert ein Software-Audit an, das bedeutet jedes Feld, füll es aus und gib die Kontrolle an den Menschen zurück. Stand September 2026 steckt es in Chrome hinter einem Origin Trial, der einzige Agent, der es nutzt, ist Gemini in Chrome, und für Ihre Google-Rankings bringt es nichts. Wir haben es trotzdem auf wearefabbrik.com eingebaut. Dieser Beitrag erklärt, was WebMCP ist, was wir geändert haben und wie Sie entscheiden, ob Ihre Website es jetzt schon braucht.
Was ist WebMCP, einfach erklärt?
Das Model Context Protocol (MCP) ist der Standard, über den ein KI-Modell einen Backend-Dienst über eine definierte Menge von Tools aufrufen kann. WebMCP nimmt diese Idee und verlegt sie in die Seite. Eine Website wird zu einem MCP-Server im Browser: Sie stellt clientseitige Aktionen bereit, der Browser regelt den Zugriff, und ein Agent, den der Nutzer eingeladen hat (heute der in Chrome eingebaute), kann diese Aktionen finden und aufrufen, während der Nutzer zusieht.
Es gibt zwei Wege, ein Tool bereitzustellen, und der WebMCP-Explainer beschreibt beide.
Die deklarative API besteht aus einer Handvoll HTML-Attributen an einem Formular, das Sie ohnehin schon haben:
<form toolname="request-free-software-audit"
tooldescription="Request a free software audit from WeAreFabbrik. A senior engineer reviews the codebase and replies within 24 hours.">
<input name="name" toolparamdescription="The user's full name" required>
<input name="email" toolparamdescription="The user's work email address" required>
<textarea name="details"
toolparamdescription="Tech stack, rough size and age of the codebase, and what worries the user most"></textarea>
<button type="submit">Request my free audit</button>
</form>
Der Browser macht daraus eine Tool-Definition mit einem JSON-Schema, das aus den Formularfeldern abgeleitet wird. Kein JavaScript, kein Build-Schritt. Wenn Sie das Attribut toolautosubmit weglassen, füllt der Agent das Formular aus und setzt dann den Fokus auf den Absenden-Button, damit der Mensch alles prüft und selbst klickt. Diese Voreinstellung ist wichtig, und wir haben sie beibehalten.
Die imperative API ist für alles, was kein Formular ist. Sie registrieren ein Tool per JavaScript mit Namen, Beschreibung, Eingabeschema und einer execute-Funktion:
await document.modelContext.registerTool({
name: "check-availability",
description: "Check whether a 30-minute intro call slot is free",
inputSchema: {
type: "object",
properties: { date: { type: "string", description: "ISO date" } },
required: ["date"]
},
async execute({ date }) {
const slots = await fetchSlots(date);
return { content: [{ type: "text", text: JSON.stringify(slots) }] };
}
});
Wenn das wie eine MCP-Server-Definition aussieht: Genau darum geht es. Dasselbe Denkmodell, nur im Browser-Tab.
Wo steht WebMCP im September 2026?
Eine ehrliche Bestandsaufnahme, denn der Großteil der aktuellen Berichterstattung stammt von Leuten, die WebMCP-Checker verkaufen.
| Frage | Stand |
|---|---|
| Welche Browser unterstützen es? | Nur Chrome. Im Februar 2026 als Early Preview in Chrome 146 ausgeliefert, inzwischen in einem öffentlichen Origin Trial. Edge hat es hinter einem Flag. |
| Ist die API stabil? | Nein. Der Einstiegspunkt ist im Sommer von navigator.modelContext zu document.modelContext umgezogen. Der alte Name ist ein veralteter Alias. |
| Firefox und Safari? | An der Diskussion zur Spezifikation beteiligt. Von keinem der beiden gibt es eine Zusage zur Auslieferung. |
| Welche Agenten können die Tools aufrufen? | In der Praxis Gemini in Chrome. Erweiterungen können es auch, aber kein verbreiteter Assistent außerhalb von Chrome liest heute WebMCP-Tools. |
| Braucht es eine Änderung am Server? | Nein. Es läuft vollständig clientseitig. |
Die Ankündigung des Chrome-Teams bezeichnet es als Early Preview, und die Übersichten zum Stand von WebMCP aus dem Juli verorten den Origin Trial bei Chrome 149 bis 156. Betrachten Sie die Details als beweglich. Betrachten Sie die Richtung als entschieden: Browser werden Agenten einen strukturierten Weg geben, Seiten zu nutzen, und dies ist der Vorschlag, hinter dem zwei Browserhersteller stehen.
Hilft WebMCP bei SEO oder bei der Sichtbarkeit in KI-Suchen?
Nein, und genau hier lohnt sich Klarheit, weil an dieser Stelle der Hype in die falsche Richtung läuft.
WebMCP ist eine Browser-API zur Laufzeit. Googlebot führt sie nicht aus. ChatGPT, Perplexity und Claude sehen sie nicht, wenn sie Ihre Website zitieren. Sie hat keinen Einfluss darauf, ob Ihre Seite rankt, in einer AI Overview auftaucht oder von einem Chat-Assistenten zitiert wird. Das hängt weiterhin von den langweiligen Dingen ab: klare Inhalte, strukturierte Daten, eine vernünftige robots.txt, eine llms.txt, wenn Sie Crawlern entgegenkommen wollen, und Seiten, die ohne einen Umweg über den Client gerendert werden.
WebMCP verändert, was passiert, nachdem ein Mensch mit einem Agenten im Schlepptau bereits auf Ihrer Seite gelandet ist. Aus „Finde das Kontaktformular und füll es für mich aus“ wird statt eines geratenen Screen-Scrapings ein definierter Tool-Aufruf mit Schema. Das ist ein Feature für Conversion und Barrierefreiheit, kein Feature für Auffindbarkeit. Wer Ihnen erzählt, WebMCP sorge dafür, dass KI Sie zitiert, verwechselt zwei verschiedene Ebenen des Stacks.
Was haben wir auf wearefabbrik.com konkret geändert?
Wir haben zwei Formulare, auf die es ankommt: das Kontaktformular und die Anfrage für das kostenlose Software-Audit. Alles andere auf der Website ist Inhalt, und Inhalte lesen Agenten ohnehin problemlos. Die ganze Änderung umfasste also etwa vierzig Zeilen, und drei davon haben uns etwas gelehrt.
Wir haben nur die deklarative API genutzt. Beide Formulare haben ein toolname, eine tooldescription und an jedem Feld eine toolparamdescription bekommen. toolautosubmit haben wir nicht hinzugefügt. Ein Agent kann die Audit-Anfrage in Ihrem Namen ausfüllen, aber auf Senden klicken Sie. Für ein Lead-Formular ist das der richtige Kompromiss: Wenn ein Agent sich ein Budgetfeld zusammenhalluziniert und die Anfrage abschickt, kostet das mehr als ein zusätzlicher Klick.
Wir haben dem Agenten vom Honeypot erzählt. Wie die meisten Formulare haben unsere ein unsichtbares Anti-Spam-Feld, das leer bleiben muss. Ein Mensch sieht es nie. Ein Agent, der das Schema des Formulars liest, schon. Ohne Hinweis würde er es vielleicht hilfsbereit ausfüllen, der Server würde die Anfrage stillschweigend als Spam verwerfen, und alle würden denken, es hätte funktioniert. Deshalb trägt das versteckte Feld jetzt toolparamdescription="Anti-spam field. Must be left empty.". Wenn Sie einen Honeypot einsetzen und WebMCP hinzufügen, machen Sie es genauso oder nehmen Sie das Feld aus dem Tool heraus.
Wir lesen das Formular beim Absenden aus dem DOM. Unsere Website ist in React gebaut, mit kontrollierten Eingabefeldern: Die Werte liegen im Zustand der Komponente und werden über Change-Events aktualisiert. Ein Agent, der Felder programmatisch ausfüllt, löst diese Events womöglich nicht so aus wie eine Tastatur. Statt darauf zu wetten, wie ein bestimmter Browser sie auslöst, liest der Submit-Handler die aktuellen Werte jetzt direkt aus dem Formularelement und legt sie über den Zustand. Das ist ein einzeiliges Auslesen per FormData, das das Formular nebenbei auch robuster gegenüber dem Autofill des Browsers und gegenüber Passwortmanagern macht, die dasselbe Problem haben.
Wir antworten dem Agenten. Die deklarative API ergänzt das Submit-Event um eine Methode respondWith(), mit der die Seite dem aufrufenden Agenten ein strukturiertes Ergebnis zurückgeben kann. Unsere liefert einen kurzen Text: „Audit request received. WeAreFabbrik replies within 24 hours to set up repository access.“ Oder, im Fehlerfall, den Hinweis an den Agenten, dass der Nutzer uns direkt per E-Mail schreiben soll. Die Funktion wird per Feature Detection geprüft, in jedem anderen Browser passiert also einfach nichts.
Wir markieren Agenten-Anfragen in der Analyse. Das Submit-Event hat außerdem ein Flag agentInvoked. Wir reichen es an unser Conversion-Event weiter. Falls über Agenten eingehende Leads jemals eine relevante Größe werden, sehen wir das, statt zu raten.
Sie können das Ganze ohne speziellen Chrome-Build prüfen. Die Website wird statisch vorgerendert, die Attribute stehen also im HTML:
curl -s https://wearefabbrik.com/free-audit | grep -o 'toolname="[^"]*"'
Braucht eine Unternehmenswebsite WebMCP schon jetzt?
So würden wir die Entscheidung einem Kunden erklären, aufgeteilt nach Art der Website.
Sie haben transaktionale Formulare oder einen Buchungsablauf. Fügen Sie die deklarativen Attribute jetzt hinzu. Der Aufwand ist ein Nachmittag, zur Laufzeit kostet es nichts, in jedem Browser ohne Unterstützung passiert einfach nichts, und Sie gehören zu den ersten Websites Ihrer Branche, die ein Agent tatsächlich nutzen kann. Lassen Sie toolautosubmit bei allem weg, was eine Verpflichtung auslöst. Beschreiben Sie Ihren Honeypot. Lesen Sie beim Absenden aus dem DOM.
Sie betreiben eine Image-Website mit Kontaktformular. Machen Sie es, wenn Sie einen Entwickler haben, der die Änderung in einer Stunde umsetzt. Zahlen Sie dafür keiner Agentur einen Retainer. Das Lead-Formular ist das Einzige, was sich lohnt, bereitzustellen.
Sie verkaufen an Käufer, die in Chrome arbeiten und Gemini nutzen. Das ist schon heute ein echtes Publikum, und es wächst, je breiter der Origin Trial wird. Wenn Ihre Kunden aus der IT oder dem Marketing kommen, nutzt ein spürbarer Teil von ihnen es bereits.
Sie haben keine Formulare und keine dynamischen Aktionen. Lassen Sie es. Es gibt nichts, was Sie bereitstellen könnten. Investieren Sie den Nachmittag lieber in strukturierte Daten und Ladezeit, denn die verbessern die Auffindbarkeit nach wie vor.
Für Kunden aus dem deutschsprachigen Raum, die nach einer „agentenfähigen Website“ fragen, gilt dieselbe Antwort. Der formale Weg, eine Website für Agenten nutzbar zu machen, ist WebMCP, und die Arbeit ist so überschaubar, dass die Entscheidung davon abhängen sollte, ob Sie Formulare haben, nicht vom Budget.
Was würde unsere Empfehlung ändern?
Drei Dinge, und wir aktualisieren diesen Beitrag, sobald eines davon eintritt.
- Ein zweiter Browser liefert es aus. Wenn Firefox oder Safari
document.modelContextimplementiert, wird aus einem Chrome-Feature ein Web-Feature. - Ein Agent außerhalb von Chrome beginnt, es zu nutzen. Wenn Claude, ChatGPT oder eine Agentenplattform für Unternehmen WebMCP-Tools aus einem geöffneten Tab liest, hängt das Publikum nicht mehr an einem einzigen Browser.
- Die imperative API stabilisiert sich. Sobald sich das Hin und Her bei der Benennung gelegt hat, lohnt sich der Wartungsaufwand, auch komplexere Aktionen wie Verfügbarkeitsabfragen oder Angebotsrechner bereitzustellen.
Bis dahin ist WebMCP eine günstige Wette mit geringem Risiko darauf, wohin sich die Plattform entwickelt. Genau solche Wetten sollte ein kleines Studio früh eingehen, denn früh dran zu sein ist der einzige Vorteil, den ein kleines Studio hat. Es ist auch die Art von Änderung, nach der wir im kostenlosen Software-Audit suchen: kleine, gut verstandene Schritte, die eine Codebasis dorthin bringen, wohin sich die Plattform bewegt, statt großer Neubauten, die einer Schlagzeile hinterherjagen. Ein Agent kann diese Anfrage jetzt für Sie ausfüllen. Den Button drücken Sie trotzdem selbst.