WebMCP ist der neue Web-Standard für KI-Agenten – co-entwickelt von Google und Microsoft. Was er ist, wie er funktioniert und warum jetzt der Einstieg lohnt.
Über Jahre hat sich technisches SEO in einem stabilen Rahmen abgespielt. Crawler lesen HTML, folgen Links, indexieren Inhalte. Schema.org wurde zum Standard, weil es funktioniert hat — wer früh implementiert hat, hatte Vorteile in Rich Results und Knowledge Graph.
Jetzt steht die nächste Schicht an. WebMCP — ein neuer Web-Standard, co-entwickelt von Google und Microsoft, bereits in Chrome 146 verfügbar — verändert, wie KI-Agenten mit Websites interagieren. Nicht durch besseres Crawling, sondern durch direkten, strukturierten Zugriff auf das, was eine Seite kann. Wer die Parallele zu Schema.org in den frühen Tagen erkennt, weiß: Das ist kein "Nice-to-have für später" — das ist ein Zeitfenster.
Vertiefung: Agentic Web Strategie aufbauen · Strukturierte Daten richtig einsetzen · Wie KI-Systeme Websites verstehen
WebMCP ist ein neuer Web-Standard, der Websites einen strukturierten Weg gibt, ihre Funktionen direkt für KI-Agenten verfügbar zu machen. Statt dass Agenten das DOM scannen, Formularfelder erraten und an UI-Änderungen scheitern, deklariert die Seite explizit: „Das ist meine Buchungs-Action, so heißen die Felder, das tut sie." Co-entwickelt von Google und Microsoft, bereits als W3C Community Group Draft veröffentlicht und in Chrome 146 testbar. Die Declarative API ist die Schema.org-Analogie: HTML-Attribute hinzufügen, Seite bleibt für Menschen unverändert, Agenten verstehen sie sauber. Das Zeitfenster für Early Mover ist real und finit — wie damals bei Schema, SSL und Mobile-Optimization.
WebMCP (Web Model Context Protocol) ist ein Browser-nativer Web-Standard, der Websites einen strukturierten Weg gibt, KI-Agenten direkten Zugriff auf ihre Funktionen zu geben. Nicht über Scraping, nicht über DOM-Inferenz, nicht über brüchige Automatisierung — sondern über explizite Deklaration: „Das ist mein Tool, das tut es, so heißen die Parameter."
Die Spezifikation wird als W3C Community Group Draft entwickelt und ist seit Chrome 146 Beta testbar. Die Co-Autorschaft von Google und Microsoft ist ein wichtiges Signal — es ist kein Single-Vendor-Versuch, sondern ein gemeinsamer Standard.
Wenn zwei der größten Browser- und KI-Plattformen gemeinsam die Spezifikation schreiben, hat sie eine andere Trajektorie als eine unilaterale Wette.
Die Frage, ob SEO für Suchmaschinen oder für Menschen optimiert wird, ist auf dem Weg, irrelevant zu werden. Die nächste Schicht sind weder Crawler noch direkt Menschen — sondern KI-Agenten, die im Auftrag der Nutzer agieren. Wer heute ChatGPT eine Aufgabe gibt, erlebt das schon: Der Agent plant, sucht selbstständig nach, stellt Rückfragen, trifft Entscheidungen. Der Output ist geformt von dem, was er findet und wie er es interpretiert.
Das ist eine Verschiebung in einer langen Geschichte der Entdeckung:
Discovery v5 ist die dramatischste Verschiebung seit dem Übergang von v1 zu v2. WebMCP ist einer der ersten konkreten Schritte dorthin.
Vertrauen in KI-Systeme entwickelt sich in eine Richtung. Es wird nicht zurückgedreht. Heute akzeptierst du eine AI-Overview-Antwort für eine schnelle Frage, vor einem Jahr hättest du noch durchgeklickt. In einem Jahr wirst du Dinge automatisieren lassen, die du heute noch selbst machst.
Das typische Adoption-Muster: Skepsis → Widerwillige Annahme („Okay, einmal.") → Abhängigkeit („Ich kann mir das nicht mehr ohne vorstellen."). Genau diesen Bogen haben wir bei Suchmaschinen, Smartphones, GPS und Online-Banking erlebt. Es gibt keinen Grund anzunehmen, dass es bei autonomen Agenten anders läuft. Der Punkt, an dem deine Website nicht von Agenten bedient werden kann, wird zu einem geschäftlichen Problem — nicht zu einem hypothetischen Risiko.
WebMCP schlägt zwei APIs vor — die Unterscheidung kommt jedem vertraut vor, der mit technischem SEO gearbeitet hat.
Die Declarative API funktioniert wie Schema-Markup. Du annotierst bestehende HTML-Formulare mit Attributen, die beschreiben, was sie tun und was die Felder bedeuten. Der Browser übersetzt das automatisch in ein strukturiertes Tool, das jeder Agent aufrufen kann. Das Formular funktioniert für menschliche Besucher exakt wie vorher.
Die Imperative API ist mächtiger und flexibler. Du registrierst Tools direkt in JavaScript — der richtige Ansatz für dynamische Interaktionen oder mehrstufige Flows.
// Buchungstool per Imperative API navigator.modelContext.registerTool({ name: "book-assessment", description: "Buche eine kostenlose IT-Erstberatung.", inputSchema: { type: "object", properties: { name: { type: "string", description: "Vollständiger Name" }, city: { type: "string", description: "Stadt für den Termin" }, slot: { type: "string", description: "Wunschtermin (ISO 8601)" } }, required: ["name", "city", "slot"] }, execute: async (input) => { // Buchungslogik return { confirmed: true, appointmentId: "APT-001" }; } });
Besonders interessant: Tools können sich basierend auf dem Seiten-Zustand verändern. Google Chrome Labs zeigt das mit einer Hotel-Buchungs-Demo: Nach search_location erscheint filter_search_results. Nach Hotel-Auswahl wird start_booking verfügbar. Das Tool-Set entwickelt sich mit dem Nutzer-Flow.
Der Unterschied lässt sich am einfachsten an einem Kontaktformular zeigen — etwas, das praktisch jede Service-Website hat.
<form action="/contact" method="POST"> <label for="name">Name</label> <input id="name" name="name" type="text" required> <label for="email">E-Mail</label> <input id="email" name="email" type="email" required> <label for="message">Nachricht</label> <textarea id="message" name="message" required></textarea> <button type="submit">Absenden</button> </form>
Ein KI-Agent muss hier raten: Was ist das für ein Formular? Ist name ein Personen- oder Firmenname? Was passiert beim Submit? Eine UI-Änderung — und der Flow bricht.
<form action="/contact" method="POST" toolname="submitContactInquiry" tooldescription="Sendet eine Kontaktanfrage an ein Dienstleistungsunternehmen."> <label for="name">Name</label> <input id="name" name="name" type="text" required toolparamdescription="Vollständiger Name des Anfragenden."> <label for="email">E-Mail</label> <input id="email" name="email" type="email" required toolparamdescription="Gültige E-Mail-Adresse für die Rückmeldung."> <label for="message">Nachricht</label> <textarea id="message" name="message" required toolparamdescription="Frage, Projekt-Details oder Service-Bedarf des Anfragenden."></textarea> <button type="submit">Absenden</button> </form>
Das Formular sieht für Menschen exakt gleich aus. Der Agent sieht jedoch ein klar deklariertes Tool mit Namen, Beschreibung und Parameter-Definitionen.
| Attribut | Funktion |
|---|---|
toolname | Eindeutiger Name des Tools (z.B. submitContactInquiry) |
tooldescription | Beschreibung der Aktion — was das Formular tut |
toolparamdescription | Beschreibung jedes einzelnen Eingabefeldes |
toolautosubmit | Boolean: Darf der Agent ohne Nutzerbestätigung absenden? |
Es gibt eine sehr rationale Position, neue Technologien nicht zu früh zu implementieren — erst die Fehler der First Mover anschauen, dann clean nachziehen. Das funktioniert in 90% der Fälle, aber nicht in den verbleibenden 10%. WebMCP gehört in diese 10%, gemeinsam mit Schema-Markup, SSL und Mobile-Optimization. In diesen Fällen war das Zeitfenster real, finit und der Vorteil verteilt sich nicht gleichmäßig.
Was den Einstieg besonders attraktiv macht: Die Declarative API hat eine sehr niedrige Einstiegshürde — Annotationen auf den wichtigsten Formularen, kein neues Backend-System, keine Infrastruktur-Migration. Wer das in einem Sprint pilotiert, ist Wochen vor der Konkurrenz dran.
toolname, tooldescription und toolparamdescription ergänzenDie Diskussion über WebMCP läuft heute überwiegend als technische Frage: API-Design, Spec-Status, Adoption-Timeline. Was übersehen wird, ist die Marketing-Dimension. Unsere Einschätzung — basierend auf dem Verlauf vergleichbarer Standards seit 2010:
Drei Beobachtungen stützen das:
toolname und tooldescription entscheidet, ob ein Agent dein Tool wählt oder das eines Wettbewerbers. Copywriting für Maschinen — eine Disziplin, die SEOs seit 15 Jahren ausüben, jetzt mit höheren Stakes.WebMCP (Web Model Context Protocol) ist ein browser-nativer Web-Standard, der Websites einen strukturierten Weg gibt, ihre Aktionen direkt für KI-Agenten verfügbar zu machen. Statt das DOM zu scannen und Formularfelder zu erraten, kann ein Agent ein Tool direkt aufrufen, das die Seite explizit deklariert hat.
Nein. Die Spezifikation wird gemeinsam von Engineers bei Google und Microsoft entwickelt und als W3C Community Group Draft veröffentlicht. Das ist wichtig: Wenn die zwei größten Browser- und KI-Plattformen einen Standard gemeinsam tragen, hat er eine andere Adoptions-Trajektorie als ein Single-Vendor-Versuch.
Ja. Die Imperative API ist in Chrome 146 Beta bereits testbar. Die Declarative API ist konzeptionell stabil, einzelne Attributnamen können sich noch ändern. Wer pilotieren will, kann mit Imperative starten oder mit Declarative auf der konzeptionellen Ebene arbeiten und die finale Syntax nachziehen, sobald sie steht.
Schema beschreibt, was eine Seite ist (Produkt, Artikel, Rezept). WebMCP beschreibt, was eine Seite kann (Buchung anlegen, Kontakt senden, Suche ausführen). Schema macht Inhalte maschinenlesbar, WebMCP macht Funktionen maschinenausführbar. Beide ergänzen sich.
Die Declarative API nutzt HTML-Attribute (toolname, tooldescription, toolparamdescription) und ist ideal für bestehende Formulare. Die Imperative API registriert Tools per JavaScript und eignet sich für komplexe, mehrstufige oder zustandsabhängige Flows. Meiste Sites starten mit Declarative.
Nein. Die Annotationen sind für Menschen unsichtbar — Formulare und Seiten funktionieren exakt wie vorher. WebMCP ist eine zusätzliche Schicht oberhalb der bestehenden UX, nicht ein Ersatz dafür. Menschen sehen ihr gewohntes Interface, Agenten sehen ein strukturiertes Tool.
Ja — wenn man die Schema-Markup-Lektion anwendet. Schema-Syntax hat sich auch entwickelt, aber das zugrundeliegende Konzept war früh stabil. Wer 2011 angefangen hat, hatte 2015 Mustererkennung, die andere noch lernen mussten. Wer auf finale Standardisierung wartet, wartet auf den Moment, an dem das Differenzierungsfenster geschlossen ist.
Priorisiere Aktionen mit hohem Wert für Routine-Delegation: Kontaktformular, Buchungs- und Terminformular, Newsletter-Anmeldung, Produktanfrage, Suche. Aktionen mit hohem Risiko oder Mehrdeutigkeit (Kaufabschluss, sensible Daten) später angehen, wenn die Trust-Layer stabiler sind.
In den nächsten 12 Monaten: wenig. Ab 2027, wenn autonome Agenten breiter im Einsatz sind: Sichtbarkeitsverlust. Wenn ein Wettbewerber WebMCP-Tools deklariert hat und du nicht, schließt der Agent die Aktion bei ihm ab — der Nutzer erfährt nie, dass es eine Alternative gab.
WebMCP ist nicht das nächste Schema-Update. Es ist die Infrastruktur für eine neue Discovery-Schicht — eine, in der KI-Agenten nicht mehr nur Informationen abrufen, sondern Aktionen ausführen. Wer das Muster aus Schema-Markup, SSL und Mobile-First erkennt, weiß: Das Zeitfenster für Early Mover ist real, finit und nicht wiederholbar.
toolname und eine tooldescription, als müsstest du sie einem KI-Agenten erklären. Das ist der Einstieg in Tool-SEO — und du machst ihn in 30 Minuten.
Wir auditieren deine Site auf Agentic-Web-Sichtbarkeit und bereiten dich auf den WebMCP-Standard vor — bevor er Mainstream wird.
Kostenlose Erstberatung
.webp)
.webp)
.webp)
