WebMCP: Der Standard, der KI-Agenten das Handeln auf Websites ermöglicht

Zuletzt aktualisiert: August 2026

KI-Agenten können bereits das Web durchsuchen, Formulare ausfüllen und Aktionen auslösen. Das Problem liegt darin, wie sie das tun. Der dominierende Ansatz - einen Headless Browser starten, Klicks über synthetisierte CSS-Selektoren injizieren und gerendertes HTML scrapen - ist langsam, brüchig und in der Produktion fehleranfällig. WebMCP ist die Spezifikation, die das ändert.

Was ist WebMCP und wie unterscheidet es sich von MCP?

WebMCP erweitert Anthropics Model Context Protocol (MCP) - den offenen Standard, der definiert, wie KI-Agenten strukturierte Tools entdecken und aufrufen - auf web-gehostete Oberflächen. Während MCP die Agent-zu-Server-Kommunikation in kontrollierten Umgebungen regelt, erlaubt WebMCP jeder Website, ihre Fähigkeiten als strukturierte, aufrufbare Tools zu beschreiben, die Agenten entdecken und aufrufen, ohne menschliches Browser-Verhalten zu simulieren. Die Integrationsoberfläche verschiebt sich vom DOM zu einem deklarierten Action-Schema.

Der praktische Unterschied: MCP erfordert eine eigens entwickelte Server-Integration. WebMCP ermöglicht es einer öffentlichen Website, ein eigenes Capability-Discovery-Manifest zu veröffentlichen - genauso wie eine REST API sich über eine OpenAPI-Spezifikation selbst beschreibt.

[Bitte Zitat eines Seven Labs-Ingenieurs einfügen zu den Kosteneinsparungen strukturierter WebMCP-Tool-Aufrufe gegenüber Headless-Browser-Agenten in der Produktion]

Warum Browser-Automatisierung im Enterprise-Maßstab versagt

Jedes Team, das KI-Agenten auf Basis von Browser-Automatisierung in der Produktion eingesetzt hat, kennt das Muster. Die Demo funktioniert. In der dritten Produktionswoche bricht eine Frontend-Änderung den Agenten - und niemand bemerkt es, bis sich ein Kunde beschwert.

Browser-Use-Agenten - Agenten, die einen Browser steuern, um mit dem Web zu interagieren - haben drei strukturelle Fehlerquellen, die im WebMCP-Modell nicht existieren:

1. Selektor-Fragilität. CSS-Selektoren und XPath-Ausdrücke brechen bei jeder DOM-Umstrukturierung. Eine Klassen-Umbenennung ist für den Agenten ein Breaking Change.
2. Rechenaufwand. Eine Chromium-Instanz kostet 200–400 MB RAM pro Session. Bei 50 gleichzeitigen Agent-Runtime-Sessions sind das 10–20 GB, verbraucht bevor eine einzige Geschäftsaktion abgeschlossen ist.
3. Compliance-Risiko. Der Zugriff auf eine Website durch Simulation eines menschlichen Nutzers kann gegen die Nutzungsbedingungen verstoßen. Strukturiertes Tool Calling über eine deklarierte Schnittstelle nicht.

In über 50 Produktions-KI-Deployments hat Seven Labs festgestellt, dass der operative Support-Aufwand für browserbasierte Agenten etwa dreimal höher ist als bei gleichwertigen strukturierten API-Integrationen. Die Agenten sind nicht das Problem. Der Schnittstellenvertrag ist es.

Wie WebMCP den Agent-Website-Interaktionsvertrag definiert

Eine Website, die WebMCP implementiert, veröffentlicht ein Manifest - typischerweise unter

/.well-known/webmcp.json

1{
2  "schema_version": "1.0",
3  "site": "https://example.com",
4  "tools": [
5    {
6      "name": "submit_inquiry",
7      "description": "Submit a product inquiry",
8      "inputSchema": {
9        "type": "object",
10        "properties": {
11          "name": { "type": "string" },
12          "email": { "type": "string", "format": "email" },
13          "message": { "type": "string", "maxLength": 2000 }
14        },
15        "required": ["name", "email", "message"]
16      }
17    }
18  ]
19}

Das beseitigt Selektor-Fragilität, reduziert den Rechenaufwand und schafft eine auditierbare, berechtigungsgesteuerte Schnittstelle. Ein Accessibility-Graph der berührbaren Elemente ersetzt das unbegrenzte Crawlen des gesamten DOM.

Strukturierte Web-Interaktion ermöglicht zudem Intent Recognition auf Serverebene - die Website weiß, was der Agent zu tun versucht, bevor er es tut. Das ermöglicht Rate-Limiting, Audit-Logging und Human-in-the-Loop-Eskalationspfade, die unmöglich sind, wenn Agenten als anonyme Browser-Sessions eintreffen.

WebMCP vs. MCP vs. Browser-Automatisierung: Ein Vergleich

Was ändert WebMCP am agentischen Produktdesign?

WebMCP verändert das agentische Produktdesign, indem es Agenten-Zugänglichkeit zu einer erstklassigen Produktanforderung macht - nicht zu einem nachträglichen Scraping-Gedanken. Jedes Web-Produkt, das 2026 KI-Agenten-Traffic erwartet, benötigt ein WebMCP-Manifest, wenn diese Agenten zuverlässig interagieren sollen. Ohne eines fallen Agenten auf Computer-Use-Simulation zurück - was langsamer, teurer ist und der Website keine Transparenz oder Kontrolle darüber gibt, wie ihre Schnittstelle konsumiert wird.

Für Teams, die auf unseren KI-Plattform- und Agent-Engineering-Services aufbauen, behandeln wir agenten-orientierte Schnittstellen bereits als eigene Produktoberfläche. Das gilt ebenso für unsere Automatisierungssysteme, wo Agenten innerhalb mehrstufiger Pipelines mit externen Web-Tools interagieren müssen - und ein kaputter Selektor mitten im Workflow ein operativer Vorfall ist, nicht nur ein Demo-Versagen.

Der Wandel ist vergleichbar mit Mobile: Teams, die 2012 Mobile als erstklassige Schnittstelle behandelten, mussten 2015 nicht von Grund auf neu aufbauen. Teams, die Agenten-Zugänglichkeit jetzt priorisieren, werden 2028 nicht von Browser-Automatisierung migrieren müssen.

Wie sollten Engineering-Teams sich auf WebMCP vorbereiten?

Engineering-Teams sollten sich auf WebMCP vorbereiten, indem sie überprüfen, welche Web-Oberflächen KI-Agenten bereits aufrufen, und dann strukturierte Manifeste für diese Oberflächen veröffentlichen, bevor Agenten standardmäßig auf Browser-Simulation zurückfallen.

Konkrete Schritte:

1. Eingehenden Agenten-Traffic prüfen. Server-Logs nach GPTBot, ClaudeBot, PerplexityBot, Google-Extended und Applebot-Extended durchsuchen. Wenn diese Ihre Site aufrufen, versuchen Agenten bereits, Struktur aus Ihren Seiten zu extrahieren.
2. Hochwertige Interaktionsoberflächen identifizieren. Kontaktformulare, Buchungsabläufe, Suchendpunkte und Produktanfrage-Seiten sind die primären Kandidaten.
3. Ein
   textCopy

   /.well-known/webmcp.json

   -Manifest veröffentlichen. Mit zwei bis drei Tools beginnen. Das Manifest muss nicht jede Seite abdecken - nur die Oberflächen, bei denen zuverlässige Agenten-Interaktion wichtig ist.
4. Authentifizierungsbereiche definieren. Festlegen, welche Tools Anmeldedaten erfordern und in welchem Format Agenten diese liefern sollen.
5. Mit einer MCP-kompatiblen Runtime testen. Claude, GPT-4o mit Tool-Use sowie Open-Source-Agent-Frameworks wie LangGraph unterstützen alle MCP-kompatibles Tool Calling, das WebMCP erweitert.

Das verbindet sich direkt mit den Orchestrierungsmustern in unserer Multi-Agent-Systems-Engineering-Arbeit - WebMCP ist das Web-Layer-Pendant zur Agent-zu-Agent-Koordinationsschicht.

Ist WebMCP jetzt schon produktionsreif?

WebMCP befindet sich in der Entstehung, ist aber implementierbar. Die Spezifikation wird aktiv weiterentwickelt und ist bereits mit MCP's bestehenden Tool-Calling-Konventionen kompatibel, die heute in der Produktion eingesetzt werden. Die Implementierung eines

webmcp.json

Das Risiko liegt nicht in der frühen Implementierung. Das Risiko liegt darin, die nächsten zwei Jahre agentische Produktoberflächen auf Browser-Automatisierung aufzubauen und dann zu migrieren, wenn der Standard reift und Ihre Konkurrenten bereits saubere, strukturierte Schnittstellen haben.

Seven Labs konzipiert und liefert produktionsreife Agenten-Systeme, einschließlich agentenorientierter Web-Interface-Architektur. Wenn Ihr Produkt zuverlässig mit KI-Agenten interagieren muss - oder für diese zugänglich sein soll - starten Sie ein Gespräch mit unserem Team.