WebMCP: Wie Chrome KI-Webagenten neu verdrahtet
Ich schaute zu, wie ein AI agent versuchte, einen Artikel in einen Einkaufswagen zu legen. Nicht irgendeinen Wagen — eine Live-E-Commerce-Website, die ich selbst gebaut hatte, also kannte ich jedes Element, jede Animation, jeden Randfall. Der Agent hatte Vision-Fähigkeiten, ein solides Modell dahinter, und ich hatte den größten Teil eines Dienstags damit verbracht, die Konfiguration richtig einzustellen.
Das Ergebnis? Der Agent machte einen Screenshot, identifizierte ein Hover-Menü falsch, klickte dreimal auf das falsche Element, hat die Seite versehentlich neu geladen und schickte mir schließlich eine höfliche Fehlermeldung, in der stand, er könne die Aufgabe nicht abschließen.
47 Sekunden. Mehr API tokens, als ich zugeben möchte. Null abgeschlossene Aufgaben.
Dieser Moment kristallisierte etwas heraus, was ich schon eine Weile ahnte: vision-basiertes KI-Webbrowsing ist leistungsstark in kontrollierten Demos und wirklich schmerzhaft im Produktionsbetrieb. Das Modell sieht Pixel. Es rät Koordinaten. Es klickt dort, wo es denkt, dass ein Button ist — nicht wo der Button tatsächlich ist. Auf einer statischen Marketingseite mit großen bunten Buttons funktioniert es prima. Bei allem mit dynamischer UI, Hover-States, Modals die animieren, oder Menüpunkten, die nur bei Interaktion erscheinen — bricht es, langsam und teuer.
Als ich hörte, dass Google Chrome etwas namens WebMCP in Chrome Beta ausliefert, ordnete ich es unter "interessant, aber wahrscheinlich noch nicht bereit" ein. Zwei Wochen später hatte ich das Flag aktiviert und schaute auf AI agent-Interaktionen, die in unter zwei Sekunden mit nahezu perfekter Zuverlässigkeit abgeschlossen wurden.
Ich lag falsch mit dem "noch nicht bereit"-Teil. Hier ist alles, was ich gelernt habe.
Die zwei kaputten Ansätze für KI-Webbrowsing
Bevor WebMCP Sinn ergibt, muss man verstehen, warum die aktuellen Optionen für ernsthafte Arbeit nicht gut genug sind.
Vision-basiertes Browsen ist der Ansatz, an den die meisten Menschen denken, wenn sie sich AI agents vorstellen, die mit Websites interagieren. Der Agent macht einen Screenshot, sendet ihn an ein Vision-Modell, das Modell identifiziert UI-Elemente, und dann versucht der Agent zu klicken, zu scrollen oder zu tippen, basierend auf dieser visuellen Interpretation. Tools wie Claudes Computer Use, GPT-4os visuelle Fähigkeiten und verschiedene Browser-Automatisierungs-Frameworks verwenden Varianten dieses Ansatzes.
Die Probleme potenzieren sich mit zunehmender Komplexität. Hover-aktivierte Dropdown-Menüs erfordern, dass der Agent zuerst hovert, einen weiteren Screenshot macht und dann klickt — und er hat die Hover-Position oft falsch. Animierte Übergänge verwirren das Screenshot-Timing. Überlappende Elemente verursachen Fehlklicks. Dark Mode, Hochkontrasteinstellungen oder jedes CSS, das von den Trainingsdaten abweicht, verschlechtert die Leistung merklich.
Das Kostenproblem ist real und wird oft unterschätzt. Vision-Modell-Inference ist teurer als Text-Inference. Wenn man einen Workflow mit 20-30 UI-Interaktionen ausführt, summieren sich die Token-Kosten für die Vision-Verarbeitung schnell. Ich führte eine mehrstufige Automatisierung auf einer komplexen Dashboard-UI durch — 24 einzelne Interaktionen — und die Kosten des Vision-Modells allein übertrafen, was ich normalerweise für einen ganzen Tag text-basierter KI-Arbeit ausgebe.
Benutzerdefinierte MCP Server — die zweite Option — lösen die Zuverlässigkeits- und Kostenprobleme elegant, führen aber eine andere Reihe von Einschränkungen ein. Model Context Protocol ist zum Standard geworden, um AI agents Zugang zu externen Tools und API's zu geben. Man baut einen benutzerdefinierten Server, der die Funktionalität der Anwendung als aufrufbare Tools exponiert, und der Agent ruft diese Tools direkt auf, anstatt zu versuchen, Buttons auf einem Bildschirm zu klicken.
Das Problem: MCP Server erfordern manuelle Vorkonfiguration. Bevor eine Agent-Sitzung beginnt, muss man wissen, welche MCP Server der Agent benötigt, sie installieren, die Verbindungsparameter konfigurieren und diese Konfigurationen aktuell halten. Es gibt keine dynamische Discovery — der Agent kann nicht zu einer beliebigen Website gehen und fragen "Was kann ich hier tun?" Er kann nur Tools verwenden, die vor Beginn der Sitzung registriert wurden.
Das ist eine fundamentale architektonische Einschränkung. Sie bedeutet, dass MCP Server gut für bekannte, stabile Integrationen skalieren — die internen API's des Unternehmens, Standard-Entwicklertools — aber nicht für das offene Web funktionieren, wo man zu beliebig vielen Tausenden von Seiten navigieren könnte.
WebMCP ist der Versuch, das, was an MCP funktioniert (direkte Funktionsaufrufe, typisierte Eingaben, zuverlässige Ausführung), mit dynamischer Discovery in den Browser zu bringen. Und die Kombination ist mächtiger als jeder der Ansätze allein.
Was WebMCP wirklich ist — jenseits der Marketing-Beschreibung
Hier ist das genaue technische Bild, denn die übergeordneten Zusammenfassungen, die ich gelesen habe, übergehen, was das Interessante daran macht.
WebMCP ist ein JavaScript-Standard, der für Browser-Umgebungen gebaut wurde. Eine Website kann eine Reihe aufrufbarer Tool-Funktionen über die WebMCP API registrieren — jedes Tool hat einen Namen, eine Beschreibung in natürlicher Sprache, ein Eingabeschema im JSON Schema-Format und eine Executor-Funktion mit der eigentlichen Implementierung. Wenn ein AI agent (in welcher Form auch immer: Browser-Sidebar, Desktop-App, IDE-Erweiterung) zu einer Seite mit registrierten WebMCP Tools navigiert, kann er die WebMCP-Schnittstelle abfragen, um herauszufinden, was verfügbar ist.
Keine Vorregistrierung erforderlich. Keine Konfigurationsdateien. Kein Installationsschritt für den Endbenutzer.
Das mentale Modell, das bei mir klickte: WebMCP macht Websites "agent-lesbar." Derzeit sind Websites für menschliche Augen und Mausklicks konzipiert. WebMCP fügt eine parallele Schnittstelle hinzu, die für AI agents konzipiert ist — eine, die in Funktionen und Schemata statt in Pixeln und Koordinaten spricht.
Betrachte ein konkretes Beispiel. Du hast eine To-Do-Anwendung. Normalerweise interagiert ein Mensch damit, indem er auf Buttons klickt, die mit "Aufgabe hinzufügen" beschriftet sind, in ein Eingabefeld tippt, Enter drückt. Ein AI agent, der vision-basiert browst, muss all diese Schritte simulieren. Ein AI agent, der WebMCP nutzt, kann addTodo({ text: "Eier kaufen", priority: "medium" }) aufrufen und in unter 200 Millisekunden { success: true, id: "task_847" } zurückerhalten.
Der Unterschied in der Interaktionsqualität ist nicht inkrementell. Er ist kategorial.
Was mich besonders auf WebMCP aufmerksam machte — im Vergleich zu anderen Browser-Automatisierungsexperimenten, die ich gesehen habe — ist die im Design eingebaute Unterstützung für mehrere Agents. Dieselben WebMCP Tool-Registrierungen auf einer Seite sind zugänglich für einen Chrome Browser-Sidebar-Agenten, Claude Desktop, das lokal läuft, Cursor oder VS Code mit einer Agent-Erweiterung, oder ein benutzerdefiniertes KI-Tool, das man selbst gebaut hat. Die Website exponiert die API einmal. Jeder kompatible Agent profitiert davon, ohne dass die Website im Voraus wissen muss, welche Agents sich verbinden werden.
Das unterscheidet sich wesentlich vom benutzerdefinierten MCP Server-Modell, das Punkt-zu-Punkt-Verbindungen zwischen bestimmten Agents und bestimmten Services herstellt. WebMCP ist Broadcast: registriere deine Tools, und jeder WebMCP-kompatible Agent, der dort hinbrowst, kann sie verwenden.
Aber hier ist der Teil, der das für echte Anwendungen statt nur Spielzeug-Demos machbar macht — und es ist der Teil, den die meisten frühen Berichte vollständig überspringen.
Das Authentifizierungsproblem, das gelöst werden musste
Eine To-Do-App ohne Konten, ohne private Daten und mit vier Tools ist eine saubere Demo. Echte Software funktioniert nicht so.
Echte Anwendungen haben Benutzerkonten. Benutzerkonten haben private Daten, die bestimmten Personen gehören. Wenn man WebMCP Tools ohne Authentifizierung exponiert, stellt man die Daten jedes Benutzers jedem Agent zur Verfügung, der zu seiner Seite navigiert. Das ist kein Kompromiss, den man in die Produktion schicken kann. Das ist ein Datenleck in der Entstehung.
Als ich zum ersten Mal auf WebMCP schaute, war das meine unmittelbare Frage: wie funktioniert Authentifizierung? Denn "wir haben eine JavaScript API hinzugefügt, die AI agents ermöglicht, die Funktionen deiner Website aufzurufen" klingt großartig, bis man darüber nachdenkt, was diese Funktionen für einen eingeloggten Benutzer sein könnten. Kann ein Agent meine E-Mails lesen? Bestellungen in meinem Namen aufgeben? Auf meine Finanzdaten zugreifen?
Die Antwort — wenn ordnungsgemäß implementiert — lautet nein. Und zu verstehen warum, erfordert das Verständnis der OAuth 2.1-Integration, die WebMCP unterstützt.
WebMCP enthält eine Authentifizierungsschicht, die auf OAuth 2.1 aufgebaut ist — dasselbe branchenübliche Autorisierungs-Framework, das von Google, GitHub, Stripe und praktisch jedem seriösen Webdienst verwendet wird. Wenn ein AI agent versucht, ein geschütztes WebMCP Tool aufzurufen, wird er durch einen OAuth-Autorisierungsflow umgeleitet. Der Benutzer erteilt dem Agenten explizit bestimmte Berechtigungen (Scopes), erhält ein Token, das genau auf diese Berechtigungen beschränkt ist, und der Agent verwendet dieses Token für nachfolgende Aufrufe. Token-Aktualisierung, Ablauf und Widerruf funktionieren alle gemäß der OAuth 2.1-Spezifikation.
Die Implementierung, die ich getestet habe, verwendete Scale Kits OAuth-Infrastruktur, und hier gebe ich Kredit, wo er verdient ist: Scale Kits Integration ist durchdacht gestaltet. Die Einrichtung erfordert drei Dinge — eine Umgebungs-URL, eine Client-ID und ein Secret sowie eine Resource-ID. Das ist wirklich alles. Alles andere — Token-Speicherung, Aktualisierungszyklen, Scope-Durchsetzung, Benutzersitzungsverwaltung — läuft innerhalb der Infrastruktur von Scale Kit.
Für jeden, der OAuth von Grund auf implementiert hat und die Narben vorweisen kann: eine funktionierende Multi-Tenant-OAuth-Integration zu haben, die man nicht selbst warten muss, ist keine Kleinigkeit.
Der Multi-Tenant-Aspekt ist wichtiger, als die Leute betonen. Mehrere Benutzer, jeder mit seiner eigenen authentifizierten Sitzung, jeder mit seinem eigenen Token, das auf seine eigenen Daten beschränkt ist, die alle möglicherweise gleichzeitig AI agents gegen dieselbe WebMCP-fähige Anwendung ausführen. Scale Kit handhabt diese Komplexität. Deine WebMCP Executor-Funktionen erhalten einen validierten authContext, der dir sagt, wer die Anfrage stellt — du verwendest ihn einfach.
Was das meiner Meinung nach praktisch freischaltet: eine Klasse von AI agent-Integrationen, die zuvor hinter erheblichem Implementierungsaufwand verschlossen waren. "Bau einen Agent, der meine Projektaufgaben verwalten kann" erfordert, dass der Agent private Projektdaten liest, authentifizierte API-Aufrufe macht, Multi-User-Zugriff handhabt — alles Dinge, die jetzt viel machbarer sind, wenn man auf WebMCP + Scale Kit OAuth baut, anstatt Authentifizierung von Grund auf zu versuchen.
Das einrichten: was tatsächlich funktioniert (und was nicht)
Ich werde hier spezifisch sein, weil die Dokumentation noch hinter der Implementierung herhinkt und ich mehrere Probleme hatte, die nirgendwo behandelt werden, wo ich nachgeschaut habe.
Chrome Beta mit aktiviertem WebMCP
WebMCP ist ab Februar 2026 experimentell. Man braucht Chrome Beta — nicht Chrome Stable, nicht Chrome Canary, speziell Beta. Lade es vom Beta-Release-Kanal von Google herunter und installiere es separat von deiner regulären Chrome-Installation.
Navigiere nach der Installation zu chrome://flags in Chrome Beta und suche nach "WebMCP." Aktiviere das Flag. Starte Chrome Beta neu. Dieser Schritt ist leicht zu übersehen, weil das Feature in der UI ohne das Flag einfach nicht existiert — du siehst keinen Fehler, es funktioniert einfach nicht.
Die Model Context Tool Inspector-Erweiterung
Die Chrome-Erweiterung fungiert als Brücke zwischen der WebMCP JavaScript API auf der Seite und deinem AI agent. Installiere sie speziell in Chrome Beta. Erweiterungen werden nicht automatisch zwischen deinem regulären Chrome und Chrome Beta übertragen — du musst sie in Beta neu installieren.
Ein Fallstrick, auf den ich gestoßen bin: wenn du die Erweiterung installierst, während Chrome Beta ohne das aktivierte WebMCP-Flag läuft, installiert sich die Erweiterung, aber die WebMCP-Brücke wird nicht vollständig initialisiert. Aktiviere zuerst das Flag, starte neu, dann installiere die Erweiterung.
Tools in deiner Anwendung registrieren
Das ist die entwicklerseitige Arbeit. WebMCP zu einer bestehenden Anwendung hinzuzufügen bedeutet, deine Tools über die JavaScript API zu registrieren. Hier sieht eine realistische Registrierung aus:
// Rufe dies auf, wenn deine App initialisiert
function registerWebMCPTools() {
// Das Optional Chaining bedeutet, dass dies in Browsern,
// die WebMCP nicht unterstützen, still nichts tut — keine Fehler,
// keine kaputte UI für Benutzer ohne die Erweiterung.
window.webmcp?.registerTool({
name: "addTask",
description: "Creates a new task in the user's task list. " +
"Use this when the user wants to add, create, or save a new task. " +
"Returns the new task's ID on success.",
inputSchema: {
type: "object",
properties: {
title: {
type: "string",
description: "The task title or description"
},
dueDate: {
type: "string",
format: "date",
description: "Optional due date in YYYY-MM-DD format"
},
priority: {
type: "string",
enum: ["low", "medium", "high"],
description: "Task priority level"
}
},
required: ["title"]
},
executor: async (params) => {
const task = await taskService.create({
title: params.title,
dueDate: params.dueDate || null,
priority: params.priority || "medium"
});
return { success: true, taskId: task.id, title: task.title };
}
});
window.webmcp?.registerTool({
name: "listTasks",
description: "Retrieves the user's current task list. " +
"Use this to show, view, or check existing tasks. " +
"Can filter by status (pending, completed, or all).",
inputSchema: {
type: "object",
properties: {
status: {
type: "string",
enum: ["pending", "completed", "all"],
description: "Filter tasks by completion status"
}
}
},
executor: async (params) => {
const tasks = await taskService.list(params.status || "all");
return { tasks: tasks.map(t => ({
id: t.id,
title: t.title,
status: t.completed ? "completed" : "pending",
dueDate: t.dueDate
}))};
}
});
}
Das description-Feld leistet mehr Arbeit, als es erscheint. Diese Beschreibung in natürlicher Sprache ist das, was das KI-Modell liest, um zu verstehen, wann jedes Tool aufgerufen werden soll und wie Benutzerintention der richtigen Funktion zugeordnet werden soll. Ich habe mehr Zeit damit verbracht, klare Tool-Beschreibungen zu schreiben, als mit jedem anderen Teil der Implementierung, und es war jede Minute wert.
Vage Beschreibungen wie "Verwaltet Aufgaben" führen dazu, dass das Modell falsche Entscheidungen trifft. Spezifische Beschreibungen wie "Erstellt eine neue Aufgabe — verwende dies, wenn der Benutzer etwas Neues hinzufügen, erstellen oder planen möchte" geben dem Modell, was es braucht, um Anfragen korrekt zu routen.
Authentifizierung für echte Anwendungen hinzufügen
Für alles mit Benutzerdaten willst du Tools hinter Authentifizierung:
window.webmcp?.registerTool({
name: "getMyProjects",
description: "Retrieves all projects belonging to the authenticated user. " +
"Requires the user to be logged in. Returns project names, statuses, " +
"and team member counts.",
requiresAuth: true,
scopes: ["projects:read"],
inputSchema: {
type: "object",
properties: {
includeArchived: {
type: "boolean",
description: "Whether to include archived projects (default: false)"
}
}
},
executor: async (params, authContext) => {
// authContext wird von der WebMCP-Runtime nach der Token-Validierung injiziert.
// Du musst das Token nicht selbst validieren — das ist bereits erledigt.
const projects = await projectService.getUserProjects(
authContext.userId,
{ includeArchived: params.includeArchived || false }
);
return { projects };
}
});
Die authContext.userId wird von der WebMCP-Runtime befüllt, nachdem das OAuth token validiert wurde. Dein Executor-Code verwendet sie einfach — du machst keine Token-Verifizierung, Token-Parsing oder Benutzer-ID-Extraktion selbst. Das ist bereits geschehen, bevor deine Funktion ausgeführt wird.
Claude Desktop verbinden (oder einen anderen Agent)
Die Agent-Konfiguration hängt davon ab, welchen Agent man verwendet. Für Claude Desktop gibt es einen WebMCP-Verbindungseintrag, den man zur Claude Desktop-Konfigurationsdatei hinzufügt. Für browser-basierte Agents, die die Chrome-Erweiterung verwenden, ist die Discovery automatisch, sobald die Erweiterung in Chrome Beta mit aktiviertem Flag installiert ist.
Das häufigste Problem: Claude Desktop zeigt keine WebMCP Tools. Erste Prüfung — läuft Chrome Beta (nicht nur installiert)? Die Erweiterung benötigt eine laufende Chrome Beta-Instanz, um darüber zu kommunizieren. Zweite Prüfung — hat die Seite irgendwelche Tools registriert? Öffne deine Browserkonsole und führe window.webmcp?.listTools() aus, um zu überprüfen, ob die Tools tatsächlich auf der Seite registriert sind.
Wenn Tools in der Konsole erscheinen, aber nicht in Claude Desktop, stellt die Brücke zwischen Chrome Beta und Claude Desktop keine Verbindung her. Starte Claude Desktop neu, während Chrome Beta bereits geöffnet ist, nicht umgekehrt.
Was ich wirklich denke — ohne Marketing-Spin
Gut. Zeit, ehrlich darüber zu sein, wo ich denke, dass WebMCP wirklich steht, denn die Berichterstattung in der Techpresse war ein bisschen zu einheitlich positiv.
Der technische Kerngedanke ist solide. Von vision-basiertem UI-Parsing zu direkten Funktionsaufrufen überzugehen ist kategorisch besser — schneller, billiger, zuverlässiger. Das bestreite ich nicht. Meine 47-Sekunden-fehlgeschlagene Einkaufswagen-Interaktion versus sub-2-Sekunden WebMCP Tool-Aufrufe sind keine sorgfältig ausgewählten Zahlen; sie sind repräsentativ für das, was ich konsistent sehe.
Meine Sorge gilt der Adoptionsgeschwindigkeit, und sie ist nicht technisch — sie ist wirtschaftlich.
WebMCP funktioniert nur, wenn Websites es implementieren. Jede Website, die es nicht implementiert, bleibt für AI agents im Territorium "vision-basiertes Browsen". Und WebMCP zu implementieren erfordert Entwicklerzeit. Man muss identifizieren, welche Benutzeraktionen man als Tools exponieren möchte, die Tool-Definitionen schreiben, die Executor-Funktionen schreiben, den Authentifizierungsflow testen und alles aktualisieren, wenn die zugrunde liegenden API's sich ändern. Für ein Startup, das ein neues Produkt mit einer KI-first-Denkweise baut, könnte das selbstverständlich sein. Für ein etabliertes Unternehmen mit einem vollen Produkt-Backlog und begrenzten Engineering-Ressourcen — konkurriert das mit Features, die Kunden heute aktiv anfordern.
Die RSS-Analogie kommt mir immer wieder in den Sinn. RSS war technisch überlegen gegenüber dem manuellen Überprüfen von Websites auf Updates. Es dauerte ein Jahrzehnt, um bedeutende Adoption zu sehen, Google Reader war nötig, um in seinem Bereich dominant zu werden, und dann kollabierte es, als Google Reader abgeschaltet wurde. Die richtige Technologie zu gewinnen ist nicht garantiert, und es geht nicht schnell.
Ich möchte auch direkt über die Situation der Spec-Stabilität sein. WebMCP ist experimentell. Das Chrome-Flag warnt dich. Dieser Artikel beschreibt die Implementierung von Februar 2026 — spezifische Methodennamen, Parameterformate und Authentifizierungsflows können sich ändern, bevor WebMCP im stabilen Chrome erscheint. Ich habe andere experimentelle Browser-APIs mehrere breaking Revisionen durchlaufen gesehen, bevor sie sich stabilisierten. Baue heute etwas mit WebMCP in dem Wissen, dass du es wahrscheinlich aktualisieren musst, wenn sich die Spec weiterentwickelt.
Eine ehrliche Eingestehung: Ich verwarf anfänglich den in einiger WebMCP-Dokumentation erwähnten deklarativen HTML-Ansatz. Ich nahm an, dass JavaScript-only-Registrierung die offensichtlich richtige Wahl war. Nach weiterem Nachdenken verstehe ich, warum eine deklarative Option für statische Content-Seiten oder server-gerenderte Anwendungen nützlich sein könnte, bei denen client-seitiges JavaScript minimal ist. Ich bin noch nicht vollständig überzeugt, dass es notwendig ist, aber ich war zu schnell damit, es abzuweisen.
Hier ist der Teil, auf den ich speziell zurückdrücken möchte: die Framing von WebMCP als "Ersatz" für traditionelle MCP Server ist falsch und sorgt für Verwirrung.
Traditionelle MCP Server bleiben das richtige Werkzeug für alles, das keine Browser-zu-Website-Interaktion ist. Backend API-Zugriff, Datenbankabfragen, Dateisystem-Operationen, Prozesse starten — nichts davon läuft über einen Browser. Benutzerdefinierte MCP Server handhaben es prima, und WebMCP berührt diese Anwendungsfälle überhaupt nicht.
Das reale Bild: AI agents werden beides verwenden. Benutzerdefinierte MCP Server für Backend-Fähigkeiten, WebMCP für browser-basierte Website-Interaktionen. Sie sind komplementär, nicht wettbewerbsfähig.
Was man realistisch erwarten kann
Für jeden, der bewertet, ob WebMCP es wert ist, jetzt zu integrieren, hier ist die ehrliche Version dessen, was man erwarten kann.
Geschwindigkeitsgewinne sind real und bedeutsam. Sub-2-Sekunden Tool-Aufrufe versus 35-50-Sekunden vision-basierte Interaktionen sind eine echte Produktivitätsverbesserung für jeden Workflow, bei dem ein Mensch auf das Ergebnis wartet. Wenn man KI-agenten-Features für Benutzer baut, macht dieser Unterschied einen Unterschied für deine Benutzer.
Kostenverbesserungen sind bei Skalierung bedeutsam. Vision-Modell-Inference kostet mehr pro Operation als funktionsaufruf-basierte Inference. Bei Workflows mit vielen Interaktionen summiert sich der Unterschied. Ich habe keine formalen Benchmarks über genug Szenarien durchgeführt, um dir ein zuverlässiges Kostenverhältnis zu geben, aber in meinen Tests reduzierte der Wechsel von vision-basierten zu WebMCP-basierten Interaktionen die Modellkosten für gleichwertige Aufgaben um etwa 60-75%.
Zuverlässigkeit verbessert sich dramatisch. Meine informelle Erfolgsquoten-Verfolgung zeigte 97-98% Erfolg bei korrekt geformten WebMCP Tool-Aufrufen versus ungefähr 68-72% bei gleichwertigen vision-basierten Interaktionen. Die Fehler im vision-basierten Modus waren vielfältig — falsches Element identifiziert, Animationstiming-Probleme, unerwarteter UI-Zustand. WebMCP-Fehler waren fast ausschließlich falsch geformte Eingaben (die durch Verbesserung der Tool-Schemata behoben werden können) oder Executor-Fehler (die einfach reguläre Bugs in deinem Code sind, leicht zu debuggen).
Authentifizierung funktioniert, wenn man sie korrekt einrichtet. Sobald Scale Kit OAuth in meiner Testumgebung ordnungsgemäß konfiguriert war, hatte ich null Authentifizierungsfehler über ausgedehnte Tests. Token-Aktualisierung erfolgte transparent. Das Wechseln zwischen mehreren Test-Benutzerkonten funktionierte jedes Mal korrekt.
Was man eintauscht: Implementierungszeit im Voraus. WebMCP zu einer bestehenden Anwendung hinzuzufügen dauert ein paar Stunden für einfache Tool-Sets, möglicherweise ein bis zwei Tage, wenn man auch OAuth und Multi-User-Unterstützung einrichtet. Man akzeptiert auch das Risiko der Spec-Instabilität, bis WebMCP im stabilen Chrome erscheint.
Der realistische Rat: wenn man ein neues KI-orientiertes Produkt von Grund auf baut, implementiere WebMCP von Anfang an. Der Overhead ist gering, wenn man neu baut. Wenn man bewertet, ob man WebMCP zu einer bestehenden Produktionsanwendung hinzufügen soll, beginne mit deinen höchstwertigen Benutzeraktionen — denjenigen, von denen ein AI agent am meisten profitieren würde — und implementiere diese zuerst. Sieh den Qualitätsunterschied, bevor du dich zu einer vollständigen Integration verpflichtest.
Wohin das führt
An dem Tag, als ich die OAuth-Integration zum Laufen brachte, verbrachte ich einige Minuten damit, über ein bestimmtes Hypothetisches nachzudenken: Was würde es bedeuten, wenn jede Website ihre Kernfunktionalität als WebMCP Tools exponieren würde?
Nicht alles — das ist unrealistisch und wahrscheinlich unerwünscht. Aber die hochwertigen Interaktionen. Die Aktionen, die Benutzer wiederholt ausführen. Die Workflows, die wichtig sind.
Du navigierst zu deinem Projektmanagement-Tool und dein KI-Assistent kann deine Aufgabenliste lesen, Elemente als erledigt markieren, neue Aufgaben hinzufügen und Prioritäten aktualisieren — alles ohne jemals einen Screenshot zu machen.
Du navigierst zu deiner Bank und dein KI-Assistent kann deinen Kontostand überprüfen, aktuelle Transaktionen prüfen oder eine Überweisung einleiten — authentifiziert, scope-begrenzt, jederzeit widerrufbar.
Du navigierst zu deiner Reisebuchungsseite und dein KI-Assistent kann Flüge suchen, Preise vergleichen und buchen — direkt, ohne gegen eine dynamische UI zu kämpfen.
Das sind keine Szenarien der fernen Zukunft. Das ist, was WebMCP ermöglichen soll, und sie sind für Entwickler, die bereit sind, die Integration zu implementieren, heute technisch erreichbar.
Die Lücke zwischen "technisch erreichbar" und "breit verfügbar" ist Adoption. Wir befinden uns jetzt am Anfang dieser Adoptionskurve — Chrome Beta, experimentelle Flags, frühe Entwicklerdokumentation. Ob WebMCP kritische Masse erreicht oder ein Nischen-Standard bleibt, hängt von Dingen ab, die nicht rein technisch sind: Entwickler-Tooling, Erweiterung der Browser-Unterstützung, Wachstum des AI agent-Ökosystems und ob genug hochwertige Websites die Integration als der Mühe wert erachten.
Meine Wette ist, dass es kritische Masse erreicht, aber langsamer als die anfängliche Hype-Welle suggeriert. Das zugrunde liegende Problem — AI agents, die effizient mit Websites interagieren müssen — ist real und beständig. Die technische Lösung, die WebMCP bietet, ist eindeutig besser als die Alternativen. Diese beiden Tatsachen finden sich irgendwann.
Die Frage, mit der man sitzen bleiben sollte: wenn jemand mit einem WebMCP-kompatiblen Agent heute zu deiner Anwendung navigiert — kann er etwas Nützliches erreichen? Oder steckt er immer noch fest und schaut zu, wie ein Vision-Modell dein Hover-Menü 47 Sekunden lang falsch identifiziert?
Das ist die Lücke, die WebMCP schließen soll. Etwas zu bauen, um diese Lücke für deine Benutzer zu schließen, ist das Wochenende wert.
🤝 Lass uns zusammenarbeiten
Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.
- 🔗 Fiverr (individuelle Entwicklungen & Integrationen): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (Enterprise-Lösungen): ramlit.com
- 🎨 ColorPark (Design & Branding): colorpark.io
- 🛡 xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io
