WebMCP erklärt: Was es ist, wie es funktioniert und warum es das Web verändert

Am 10. Februar 2026 veröffentlichte Googles André Cipriani Bandarra auf Chrome for Developers einen kurzen Blogbeitrag, der eine frühe Vorschau auf WebMCP vorstellte, das Web Model Context Protocol. Die Idee dahinter klang verblüffend einfach: Was wäre, wenn Websites KI-Agenten genau sagen könnten, was sie können, statt die Agenten raten zu lassen?

Dieser eine Gedanke, Rätselraten durch einen strukturierten Vertrag zwischen Websites und KI zu ersetzen, ist inzwischen auf dem Weg zu einem offiziellen Web-Standard. Google und Microsoft stehen dahinter, das W3C inkubiert ihn, und die erste Browser-Implementierung läuft bereits in Chrome Canary.

Warum das wichtig ist, zeigt ein Blick darauf, was heute passiert, wenn du einen KI-Assistenten bittest, dir einen Flug zu buchen. Der Agent macht einen Screenshot der Airline-Website, gibt ihn an ein Vision-Modell weiter, versucht herauszufinden, welches Element auf dem Bildschirm das Abflugfeld ist, tippt etwas hinein, macht den nächsten Screenshot, sucht den Suchen-Button, klickt darauf, macht wieder einen Screenshot und so weiter. Dutzende teure Inferenz-Aufrufe, nur um ein Formular auszufüllen. Gestaltet die Airline ihre Seite nächste Woche um, funktioniert der ganze Ablauf nicht mehr.

WebMCP ersetzt diese komplette Schleife durch einen einzigen Funktionsaufruf: searchFlights("AMS", "JFK", "2026-06-15"). Die Website stellt die Funktion bereit. Der Agent ruft sie auf. Fertig.

Die SEO-Szene reagierte sofort. Der Technical-SEO-Experte Dan Petrovic nannte WebMCP den größten Umbruch im technischen SEO seit strukturierten Daten, und WordLift brachte die Analogie auf den Punkt: Hat Schema.org die standardisierten Substantive des Webs geliefert, liefert WebMCP die standardisierten Verben.

Was ist WebMCP?

WebMCP steht für Web Model Context Protocol. Es ist ein vorgeschlagener Web-Standard, mit dem Websites ihre Funktionen als strukturierte, aufrufbare „Tools“ bereitstellen können, die KI-Agenten direkt über den Browser nutzen.

Verfasst haben die Spezifikation Entwickler von Google und Microsoft gemeinsam: Brandon Walderman, Leo Lee und Andrew Nolan von Microsoft sowie David Bokan, Khushal Sagar und Hannah Van Opstal von Google. Entwickelt wird sie in der W3C Web Machine Learning Community Group, demselben W3C-Gremium, das auch andere Machine-Learning-Standards auf Browserebene inkubiert. Ziel ist ein breit akzeptierter Web-Standard.

Stand Februar 2026 ist WebMCP in Chrome 146 Canary hinter einem experimentellen Flag verfügbar. Entwickler erhalten Dokumentation und Demos über Googles Early Preview Program. Da Microsoft die Spezifikation aktiv mitverfasst, wird allgemein erwartet, dass Edge-Unterstützung folgt.

Die Spezifikation selbst beschreibt WebMCP als „eine JavaScript-Schnittstelle, mit der Webentwickler die Funktionen ihrer Webanwendung als ‚Tools‘ bereitstellen können: JavaScript-Funktionen mit Beschreibungen in natürlicher Sprache und strukturierten Schemas, die von KI-Agenten, Browser-Assistenten und assistiven Technologien aufgerufen werden können“.

Der letzte Teil, assistive Technologien, geht leicht unter, ist aber wichtig. Vieles, was das Web für KI-Agenten schwierig macht, erschwert es auch Screenreadern und anderen Hilfsmitteln für Barrierefreiheit. Der strukturierte Tool-Ansatz von WebMCP könnte beides deutlich verbessern.

Das Problem, das WebMCP löst

KI-Agenten bedienen Websites heute auf zwei Arten, und beide stoßen grundsätzlich an Grenzen.

Visuelle Agenten machen Screenshots von Webseiten, geben sie an Vision-Modelle weiter und versuchen, Buttons und Formularfelder anhand der Pixel zu finden. Jede Interaktion erfordert einen neuen Screenshot und einen neuen Inferenz-Aufruf. Eine simple Produktsuche kann ein Dutzend Durchläufe brauchen. Verschiebt sich das Layout der Seite auch nur leicht, etwa durch ein Redesign, einen A/B-Test oder eine andere Bildschirmgröße, kann der Agent scheitern.

DOM-basierte Agenten lesen das rohe HTML und den Accessibility-Tree einer Seite aus, um Daten zu extrahieren und Events auszulösen. Das ist zuverlässiger als Pixelanalyse, verbraucht aber viel Kontextfenster für das Durchforsten der Seitenstruktur, und der Agent muss erst rekonstruieren, was jedes Element eigentlich tut. Ein <button> mit der Aufschrift „Go“ kann Suchen, Absenden, Navigieren oder Löschen bedeuten. Der Agent muss es aus dem Kontext erschließen.

Beide Ansätze haben denselben Grundfehler: Die KI versucht, eine Oberfläche für Menschen zu bedienen, die nie für Maschinen gedacht war. Oder wie es in der WebMCP-Spezifikation heißt: „Selbst wenn Agenten Erfolg haben, erfordern einfache Vorgänge oft mehrere Schritte und können langsam oder unzuverlässig sein.“

WebMCP bietet einen dritten Weg. Statt dass der Agent herausfinden muss, was eine Website kann, erklärt die Website ihre Fähigkeiten ausdrücklich, und der Agent ruft sie direkt auf.

Wie WebMCP funktioniert

WebMCP führt eine neue Browser-API ein: navigator.modelContext. Darüber registriert eine Website „Tools“, also JavaScript-Funktionen mit Beschreibungen in natürlicher Sprache und typisierten Parameter-Schemas. Zusammen bilden diese Tool-Definitionen den sogenannten Tool Contract der Website: ein maschinenlesbares Menü aller Aktionen, die ein KI-Agent auf dieser Seite ausführen kann.

Die Spezifikation sieht zwei sich ergänzende Wege vor, diese Tools zu definieren.

Die deklarative API (HTML-basiert)

Das ist der Weg mit dem geringsten Aufwand. Entwickler ergänzen ihre bestehenden HTML-Formulare um neue Attribute, und der Browser macht daraus automatisch Tools, die Agenten aufrufen können. JavaScript ist nicht nötig.

<form toolname="searchFlights"
      tooldescription="Search for available flights between airports">
  <input name="origin" type="text" required pattern="[A-Z]{3}">
  <input name="destination" type="text" required pattern="[A-Z]{3}">
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

Die Attribute toolname und tooldescription sind die einzigen Ergänzungen. Der Browser liest die vorhandene Struktur des Formulars aus, also Feldnamen, Typen, Validierungsmuster und Pflichtfelder, und erzeugt daraus ein Schema, das ein KI-Agent verstehen und aufrufen kann. Websites mit sauber strukturierten Formularen können das fast ohne Umbau nachrüsten.

Ruft ein Agent ein deklaratives Tool auf, löst der Browser ein SubmitEvent aus, dessen Eigenschaft agentInvoked auf true gesetzt ist. So kann das Backend zwischen Eingaben von Menschen und von Agenten unterscheiden. Das ist nützlich für Analytics, Rate Limiting oder um Daten in einem maschinenfreundlichen Format statt als gerendertes HTML zurückzugeben.

Die imperative API (JavaScript-basiert)

Für Interaktionen, die über das Absenden von Formularen hinausgehen, etwa dynamische mehrstufige Abläufe, Datenverarbeitung in Echtzeit oder bedingte Logik, registrieren Entwickler Tools per Code:

navigator.modelContext.registerTool({
  name: "getFlightStatus",
  description: "Check real-time status of a specific flight",
  schema: {
    type: "object",
    properties: {
      flightNumber: { type: "string", description: "IATA flight number" },
      date: { type: "string", format: "date" }
    },
    required: ["flightNumber"]
  },
  handler: async ({ flightNumber, date }) => {
    const status = await flightAPI.getStatus(flightNumber, date);
    return { status: status.state, gate: status.gate, delay: status.delay };
  }
});

Damit haben Entwickler die volle Kontrolle. Sie können Tools je nach Zustand der Anwendung dynamisch hinzufügen und entfernen und so unterschiedliche Funktionen anbieten, je nachdem, ob ein Nutzer angemeldet ist, auf welcher Seite er sich befindet oder an welchem Schritt eines Ablaufs er steht. Entscheidend ist, dass die Handler-Funktionen dieselbe Frontend-Logik wiederverwenden können, auf der die Oberfläche der Website ohnehin schon läuft. Du baust keine separate Integrationsschicht, sondern machst zugänglich, was du ohnehin schon gebaut hast.

Der Browser als Vermittler

Eine der folgenreichsten Designentscheidungen von WebMCP: Der Browser vermittelt die gesamte Kommunikation zwischen Website und Agent. Die Website registriert Tools über navigator.modelContext. Der Browser reicht diese Tools in dem Format an den Agenten weiter, das der Agent braucht. Website und Agent sprechen nie direkt miteinander.

Patrick Brosset vom Microsoft-Edge-Team erklärt es so: „Es ist der Browser, der mit dem Agenten spricht. Die Spezifikation verwendet den Begriff ‚Model context provider‘. Über navigator.modelContext liefert deine Webseite Kontext, nämlich die Tools, die ein KI-Agent dann nutzt, aber die Protokollarbeit erledigt der Browser für dich.“

Diese Architektur löst drei Probleme auf einmal.

Die Authentifizierung wird übernommen. Tools laufen im Browser-Tab, im Kontext der bestehenden Sitzung des Nutzers. Bist du bei einem Onlineshop angemeldet, hat der Agent Zugriff auf dieselbe Sitzung. Keine separaten OAuth-Abläufe, keine API-Schlüssel, keine Token-Verwaltung.

Der Nutzer behält die Kontrolle. Alles passiert im sichtbaren Browser-Tab, du siehst also, was der Agent tut. Für heikle Aktionen wie Käufe, die Übermittlung persönlicher Daten oder Löschvorgänge sieht die Spezifikation agent.requestUserInteraction() vor. Damit hält die Ausführung an, und der Browser holt eine ausdrückliche Bestätigung des Nutzers ein, bevor es weitergeht.

Plattformunabhängigkeit. Ob der besuchende Agent auf ChatGPT, Claude, Gemini oder einem eigenen Unternehmensmodell läuft, der Tool Contract der Website bleibt derselbe. Der Browser vereinheitlicht die Interaktion.

Woher WebMCP kommt

WebMCP begann weder bei Google noch bei Microsoft, sondern bei einem frustrierten Entwickler bei Amazon.

Anfang 2025 baute Alex Nahas bei Amazon interne KI-Agenten auf Basis von Anthropics Model Context Protocol (MCP). Amazon hatte im Grunde einen riesigen MCP-Server aufgesetzt, der Tausende Tools aus seinen internen Diensten bereitstellte. „Man musste sie über Prozessbefehle im Connection String deaktivieren“, sagte Nahas gegenüber Arcade.dev. Das war umständlich, doch das eigentliche Hindernis war die Authentifizierung. Die MCP-Spezifikation hatte OAuth 2.1 übernommen, und das hatte praktisch kein interner Amazon-Dienst implementiert. Jeder Dienst hatte seine eigene Lösung für die Anmeldung, und keine davon sprach OAuth.

Dann kam Nahas die entscheidende Idee: Der Browser hatte dieses Problem längst gelöst. Amazon-Mitarbeiter waren über eine föderierte, browserbasierte Anmeldung bei allen internen Diensten eingeloggt. Wenn man MCP-artige Tools direkt im Browser-Tab ausführen könnte, bekäme man diese ganze Authentifizierung gratis dazu.

Als Proof of Concept baute er MCP-B (Model Context Protocol for Browser). Es funktionierte. Er stellte es als Open Source bereit.

Unterdessen arbeiteten Entwickler bei Google und Microsoft unabhängig davon an ähnlichen Problemen. Die Teams fanden über das W3C zueinander, einigten sich bis August 2025 auf eine gemeinsame Spezifikation und veröffentlichten sie auf GitHub. Im September 2025 nahm die W3C Web Machine Learning Community Group sie als offizielles Arbeitsergebnis an. Im Februar 2026 lieferte Google die erste Browser-Implementierung aus.

Ein wichtiger Punkt: Trotz des Namens ist WebMCP technisch gesehen kein MCP. Wie Nahas erklärte, wollte er ursprünglich das komplette MCP-Protokoll (samt JSON-RPC) in den Browser übertragen, doch die Arbeitsgruppe entschied sich dagegen, sich zu eng an Anthropics Spezifikation zu binden. WebMCP teilt das Grundkonzept von MCP, also Tools mit Schemas, die Agenten aufrufen, ist aber ein eigenständiger, browsernativer Standard.

WebMCP vs. MCP vs. NLWeb

Die Namen sorgen für Verwirrung, deshalb lohnt sich ein Blick darauf, wo WebMCP neben den anderen Protokollen im Ökosystem der KI-Agenten steht.

Anthropics MCP (Model Context Protocol) ist ein Backend-Protokoll. Es verbindet KI-Plattformen über serverseitige Integrationen per JSON-RPC mit externen Diensten. Willst du, dass Claude oder ChatGPT die Datenbank deines Unternehmens abfragt, baust du diese Verbindung mit MCP. Dafür brauchst du eigene Serverinfrastruktur.

Microsofts NLWeb, im Mai 2025 vorgestellt, gibt Websites eine Abfrageschnittstelle in natürlicher Sprache und macht jede Website zu einem MCP-Server für Agenten im weiteren Ökosystem. Es arbeitet auf API-Ebene: Agenten sprechen direkt mit dem Backend der Website.

WebMCP läuft komplett clientseitig im Browser. Die Website registriert Tools beim Laden der Seite. Der Browser stellt sie besuchenden Agenten zur Verfügung. Backend-Infrastruktur ist nicht nötig. Die Authentifizierung kommt aus der Sitzung des Nutzers.

Die drei ergänzen sich, statt zu konkurrieren. Ein Unternehmen könnte MCP für tiefe Backend-Integrationen nutzen, NLWeb für den Zugriff in natürlicher Sprache auf API-Ebene und WebMCP für Interaktionen im Browser, bei denen der Nutzer dabei ist. Der entscheidende Unterschied: Nur mit WebMCP können Entwickler vorhandenen Frontend-Code wiederverwenden, ohne neue serverseitige Infrastruktur aufzubauen.

Warum es wichtig ist

Bedeutend ist WebMCP weniger wegen einer einzelnen Funktion als wegen des Zusammenspiels mehrerer Eigenschaften.

Drastisch geringere Kosten pro Interaktion. Ein einziger strukturierter Tool-Aufruf ersetzt, wofür bisher Dutzende Hin-und-her-Schritte mit Screenshots, Inferenz durch Vision-Modelle und DOM-Parsing nötig waren. Erste Berichte sprechen von rund 67 % weniger Rechenaufwand im Vergleich zu visuellen Agenten. Für stark besuchte Websites mit Tausenden Agenten-Interaktionen pro Tag sind die Einsparungen erheblich.

Zuverlässigkeit unabhängig vom Design. Strukturierte Funktionsaufrufe gehen nicht kaputt, wenn ein Designer einen Button verschiebt, eine CSS-Klasse umbenennt oder einen A/B-Test startet. Der Tool Contract bietet eine stabile Schnittstelle, die vom visuellen Layout unabhängig ist. Agenten und Webdesign können sich also unabhängig voneinander weiterentwickeln.

Minimaler Aufwand für Entwickler. Für die deklarative API genügen zwei HTML-Attribute in bestehenden Formularen. Kein JavaScript, keine neuen Endpunkte, keine API-Dokumentation, die gepflegt werden muss. Für die meisten Websites ist der Weg zur „Agent-Readiness“ kürzer als bei vielen SEO-Optimierungen.

Barrierefreiheit als Nebeneffekt. Dieselben strukturierten Tool-Definitionen, die KI-Agenten helfen, helfen auch assistiven Technologien. Screenreader und andere Hilfsmittel stehen vor vielen derselben Hürden wie KI-Agenten, wenn sie verstehen wollen, was eine Webseite tut und nicht nur, was sie sagt. WebMCP könnte beides spürbar verbessern.

Branchen und Anwendungsfälle

Googles Dokumentation zur frühen Vorschau nennt mehrere zentrale Anwendungsfälle, allesamt strukturierte, mehrstufige Abläufe.

E-Commerce profitiert am offensichtlichsten. Statt dass sich ein KI-Agent mühsam durch Produktfilter, Größenauswahl und Checkout klickt, stellt ein Shop Tools wie searchProducts(query, priceRange, category), addToCart(productId, quantity, size) und checkout(paymentMethod) bereit. Der gesamte Weg von der Produktsuche bis zum Kauf wird zu einer Reihe sauberer Funktionsaufrufe. Für Händler könnte das deutlich höhere Conversion-Raten bei Käufen über Agenten bedeuten.

Reise und Gastgewerbe passen ebenfalls perfekt. Flugsuche, Hotelbuchung und Mietwagen sind strukturierte Transaktionen mit vielen Parametern, die sich direkt auf Tool-Definitionen abbilden lassen. Google nannte Reisebuchungen ausdrücklich als einen der wichtigsten verifizierten Anwendungsfälle.

SaaS-Produkte können ihre zentralen Abläufe für Agenten öffnen. Stell dir vor, du sagst einem KI-Assistenten „Leg ein neues Projektboard mit drei Spalten an und lade mein Team ein“, und er erledigt das über strukturierte Tool-Aufrufe statt über simulierte Klicks und Tastatureingaben.

Kundensupport-Portale können Tools für das Anlegen von Tickets, Statusabfragen und die Kategorisierung von Anliegen definieren. Ein Agent, der createTicket(category, urgency, description) direkt aufrufen kann, arbeitet weit zuverlässiger als einer, der sich visuell durch ein mehrstufiges Supportformular hangeln muss.

Die Folgen für SEO

Die starke Reaktion der SEO-Szene auf WebMCP ist kein Hype. Sie spiegelt einen strukturellen Wandel darin wider, wie Websites gefunden und genutzt werden.

Der Vergleich mit Schema.org hilft. Als strukturierte Daten eingeführt wurden, bekamen Suchmaschinen eine standardisierte Möglichkeit zu verstehen, was Inhalte bedeuten. Websites, die früh mitzogen, erhielten Rich Snippets, Plätze im Knowledge Panel und eine bessere Sichtbarkeit in der Suche. Wer nicht mitzog, geriet in einen Rückstand, den aufzuholen Jahre dauerte.

WebMCP leistet etwas Vergleichbares, nur für eine andere Ära. Es gibt KI-Agenten eine standardisierte Möglichkeit zu verstehen, welche Aktionen eine Website anbietet. Je mehr Agenten zu einem der wichtigsten Kanäle werden, über die Menschen das Web nutzen, um Reisen zu buchen, einzukaufen oder Dienste zu verwalten, desto mehr werden Websites mit klaren, verlässlichen Tool Contracts diejenigen sein, mit denen Agenten sicher arbeiten können.

Daraus entsteht eine neue Art von Wettbewerb. Kann ein KI-Agent auf einer Reise-Website bookFlight() direkt aufrufen, muss sich auf einer anderen aber per Pixel-Scraping durchkämpfen, ist die strukturierte Option schneller, günstiger und weniger fehleranfällig. Mit der Zeit summiert sich dieser Vorsprung: Agenten (und die Plattformen, auf denen sie laufen) werden Nutzer ganz von selbst zu Websites lenken, die einfacher und günstiger zu bedienen sind.

Für Unternehmen könnte die WebMCP-Tauglichkeit ihrer Website so wichtig werden, wie es vor einem Jahrzehnt responsives Design für Mobilgeräte war. Nicht über Nacht, aber stetig, je breiter die Browser-Unterstützung wird und je mehr Interaktionen über Agenten laufen.

So fängst du an

WebMCP befindet sich in einer frühen Vorschau, das Fenster für frühe Anwender ist also jetzt offen.

Prüfe die wichtigsten Abläufe deiner Website. Finde die zentralen Nutzeraktionen wie Suche, Buchung, Checkout, Formulareingaben und Kontoverwaltung, die davon profitieren würden, als Tools bereitzustehen. Fang mit den wertvollsten Transaktionen an.

Beginne mit der deklarativen API. Hast du saubere, gut strukturierte HTML-Formulare, sind die Attribute toolname und tooldescription der schnellste Weg. Das erfordert kein JavaScript und nur minimale Änderungen am Code.

Tritt dem Early Preview Program bei. Googles EPP bietet Zugang zu vollständiger Dokumentation, Demos und Testwerkzeugen. Anmelden kannst du dich über die Chrome-for-Developers-Website.

Teste in Chrome Canary. Aktiviere in Chrome 146 Canary das Flag „WebMCP for testing“. Googles Model Context Tool Inspector bietet Debugging-Werkzeuge, mit denen du deine Tool-Definitionen prüfen kannst.

Probier die imperative API aus, wenn du komplexe Abläufe mit dynamischer Tool-Registrierung oder mehrstufiger Logik hast.

Wer schon loslegen will, bevor native Browser-Unterstützung breit verfügbar ist, kann mit dem MCP-B-Polyfill von Alex Nahas (@mcp-b/global) bereits heute Tools über navigator.modelContext.registerTool() registrieren. Es funktioniert mit bestehenden Frontend-Frameworks für Tool-Aufrufe wie CopilotKit, AGUI und SystintUI. Die vollständige Dokumentation findest du unter docs.mcp-b.ai.

Die W3C-Spezifikation ist auf GitHub verfügbar.

Wie es weitergeht

Die Spezifikation ist noch ein Entwurf, doch die Richtung ist klar.

Der offizielle Browser-Rollout wird für Mitte bis Ende 2026 erwartet. Google I/O und Google Cloud Next sind die wahrscheinlichsten Bühnen für größere Ankündigungen. Da Microsoft die Spezifikation mitverfasst hat, dürfte Edge dem Zeitplan von Chrome folgen. Patrick Brosset vom Edge-Team hat ausdrücklich signalisiert, dass Microsoft weiter investiert: „Im Edge-Team ist uns wichtig, nicht nur die Menschen einzubinden, sondern auch die Entwickler. Deshalb ist uns WebMCP wichtig.“

Die API entwickelt sich weiter. Die Schnittstelle ist bereits vom früheren window.agent zu window.navigator.modelContext umgezogen, und Funktionen wie agent.requestUserInteraction() kamen nach dem ersten Vorschlag vom August 2025 hinzu. Die W3C-Community verfeinert die Spezifikation laufend anhand von Tests aus der Praxis.

Multimodale Unterstützung steht auf der Roadmap des gesamten MCP-Ökosystems. Künftige Protokollversionen sollen Bilder, Video und Audio verarbeiten können. Agenten würden dann nicht nur lesen und schreiben, sondern über dasselbe Framework auch visuelle und akustische Inhalte interpretieren.

Kommunikation zwischen Agenten ist der nächste große Schritt. Die aktuelle Spezifikation konzentriert sich auf die Interaktion zwischen Nutzer und Agent über den Browser, die Roadmap umfasst aber auch Szenarien, in denen Agenten Aufgaben über mehrere Dienste und Seiten hinweg an andere Agenten delegieren.

Häufig gestellte Fragen

Ist WebMCP dasselbe wie Anthropics MCP? Nein. Beide teilen ein Grundkonzept, nämlich Tools mit Schemas, die Agenten aufrufen können, doch WebMCP ist ein eigenständiger Standard. Er verwendet kein JSON-RPC, läuft komplett im Browser (nicht auf Backend-Servern) und wurde speziell für die Webplattform entworfen. Die beiden ergänzen sich: Ein Unternehmen könnte beide für unterschiedliche Anwendungsfälle einsetzen.

Welche Browser unterstützen WebMCP? Stand Februar 2026 ist WebMCP in Chrome 146 Canary hinter dem Flag „WebMCP for testing“ verfügbar. Da Microsoft die Spezifikation mitverfasst hat, wird Edge-Unterstützung allgemein erwartet. Der offizielle Rollout wird für Mitte bis Ende 2026 erwartet.

Muss ich meine Website neu schreiben? Nein. Mit der deklarativen API ergänzt du bestehende Formulare um zwei HTML-Attribute und hast damit WebMCP-Unterstützung. Bei Websites mit sauberem, gut strukturiertem HTML sind die Änderungen minimal. Die imperative API erfordert JavaScript, kann aber vorhandene Frontend-Logik wiederverwenden.

Können KI-Agenten ohne Erlaubnis des Nutzers handeln? Das ist so nicht vorgesehen. WebMCP enthält agent.requestUserInteraction(), das die Ausführung bei heiklen Aktionen anhält und auf die Bestätigung des Nutzers wartet. Die Spezifikation folgt dem Grundsatz, dass keine folgenreiche Aktion ohne Wissen und Zustimmung des Nutzers passieren darf.

Verbessert WebMCP die Barrierefreiheit? Möglicherweise ja. Die strukturierten Tool-Definitionen, mit denen KI-Agenten verstehen, was eine Seite tut, können auch Screenreadern und anderen assistiven Technologien helfen. Die W3C-Spezifikation nennt assistive Technologien ausdrücklich als Zielgruppe neben KI-Agenten.

Wie wirkt sich WebMCP auf SEO aus? Das Gesamtbild entsteht noch, doch die strukturellen Parallelen zu Schema.org sind deutlich. Je mehr KI-Agenten zu einem Kanal für Transaktionen und Entdeckung werden, desto einfacher und günstiger lässt sich für sie mit Websites arbeiten, die klar definierte Tool Contracts haben. Daraus entsteht ein natürlicher Vorteil, ähnlich dem, den frühe Anwender strukturierter Daten in der Suche hatten.

Fazit

Seit 30 Jahren ist das Web ein Ort für menschliche Augen und menschliche Hände. Jede Seite, jeder Button, jedes Formular geht davon aus, dass am anderen Ende ein Mensch sitzt. WebMCP ist der erste ernsthafte, von Standards getragene Versuch, das Web für KI-Agenten von Grund auf verständlich und bedienbar zu machen, ohne den Menschen außen vor zu lassen.

Es ist noch früh. Die Spezifikation ist ein Entwurf. Die Browser-Unterstützung ist experimentell. Doch das Fundament ist solide: zwei der größten Browserhersteller der Welt, die über das W3C zusammenarbeiten, eine funktionierende Implementierung, die sich schon testen lässt, und ein Einstieg für Entwickler, der so einfach ist, dass die meisten Websites mit zwei HTML-Attributen loslegen können.

Unternehmen, die früh erkannt haben, wie wichtig strukturierte Daten sind, haben sich in der Suche einen jahrelangen Vorsprung verschafft. Mit WebMCP öffnet sich gerade dasselbe Fenster, und es wird nicht ewig offen bleiben.