WebMCP: Wenn KI-Agenten deine Website nicht nur lesen, sondern nutzen

Das Szenario: Von der Suche zur Interaktion (2027?)

Stell dir vor: Ein Vorstand beauftragt seinen KI-Agenten: "Finde mir drei Unternehmensberatungen für Post-Merger-Integration im Mittelstand, prüfe deren Projekterfahrung und buche jeweils ein Erstgespräch."

Phase 1: Gefunden werden

Der Agent durchsucht das Web. Dank Schema.org, llms.txt und gutem Content landen mehrere Beratungen auf der Shortlist. Alle haben relevante Expertise, alle sind technisch auffindbar.

Phase 2: Genutzt werden – hier beginnt das Problem

Jetzt will der Agent interagieren. Was er findet:

• Kontaktformular ohne Context: Ist das für Newsletter, Erstgespräch oder Angebote?
• "Referenzen ansehen" führt zu unstrukturierter PDF-Liste – nicht filterbar, nicht maschinenlesbar
• "Termin vereinbaren" linkt zu Calendly – aber welcher Termin-Typ? Welches Thema? Welche Dauer?

Der Agent muss raten, parsen, interpretieren. Für manche Websites klappt das durch Zufall. Für andere nicht.

Jetzt die Ausnahme: Einige Beratungen haben WebMCP implementiert. Sie bieten klare, maschinenlesbare Aktionen:

• filterProjects (Parameter: Branche, Projektart, Unternehmensgröße)
• scheduleInitialConsultation (Parameter: Thema, bevorzugter Zeitraum)
• requestCaseStudy (Parameter: Branche, Format)

Der Agent kann seine Aufgabe verlässlich abschließen – ohne Umwege, ohne Fehlinterpretationen.

Die Hypothese: Der Vorstand bekommt Vorschläge mit gebuchten Terminen und geprüften Referenzen – von den Websites, die maschinenlesbar waren. Die anderen? Wurden zwar gefunden, aber die Interaktion war zu unsicher.

Wichtig: Das ist ein Gedankenexperiment, kein dokumentierter Case. WebMCP ist 8 Tage alt. Niemand weiß, wie Agenten 2027 tatsächlich arbeiten. Aber die technische Lücke (strukturierte Inhalte vs. strukturierte Aktionen) ist real.

Die neue Barriere: Wenn der Agent dich findet, aber nicht versteht

Hier ist die Kernthese: In einer Welt mit KI-Agenten wird die Hürde nicht "gefunden werden", sondern "genutzt werden".

Die zwei Ebenen der Agent-Readiness

Ebene 1: Discoverability (Gefunden werden)

• Schema.org: Strukturierte Identität
• llms.txt: Strukturiertes Wissen
• Content-Qualität: Relevanz und Autorität
• Technisches SEO: Crawlbarkeit, Performance

→ Das hast du vermutlich schon im Griff (oder kannst es mit überschaubarem Aufwand nachholen)

Ebene 2: Usability (Genutzt werden)

• WebMCP: Strukturierte Interaktionen
• Maschinenlesbare Formulare
• Validierte Parameter
• Klare Tool-Definitionen

→ Das ist neu – und hier entscheidet sich, ob der Agent mit dir arbeiten kann

Die Analogie: Google vs. Conversion-Optimierung

Denk an klassisches SEO:

• Ranking = Sichtbarkeit (du wirst gefunden)
• Landing Page = Nutzbarkeit (Besucher werden zu Leads)

Die beste Position 1 hilft nichts, wenn deine Landing Page chaotisch ist.

WebMCP ist die Landing Page für KI-Agenten.

Der Agent-Ready Stack: Drei Schichten mit unterschiedlichen Jobs

1. Schema.org: Identität & Sichtbarkeit

Wer bist du – und wofür bist du relevant?

Schema.org gibt deiner Website strukturierte Metadaten (Organization, Service, ProfessionalService). Das macht dich auffindbar – für Google, Perplexity, KI-Agenten.

Status 2026: Etabliert. Wenn du es noch nicht hast: Nachholen. Jetzt.

2. llms.txt: Wissen & Kontext

Was weißt du – und wie arbeitest du?

Eine Textdatei im Root (/llms.txt) mit Methoden, Projekterfahrung, Branchenfokus, Honorarmodellen. Das macht dein Angebot verständlich – für Agenten, die dich bereits gefunden haben.

Status 2026: Empfohlen von OpenAI, Anthropic und Perplexity. Umsetzung: 2–3 Stunden.

3. WebMCP: Interaktion & Aktion

Was kann der Agent bei dir tun – ohne zu raten?

WebMCP macht aus deiner Website eine API für KI-Agenten. Statt HTML zu parsen, bekommt der Agent strukturierte Aktionen: filterProjects, scheduleConsultation, requestProposal.

Das ist der Fokus dieses Artikels. Denn gefunden zu werden, aber nicht nutzbar zu sein, ist wie eine Visitenkarte ohne Telefonnummer.

Warum WebMCP vermutlich der Standard wird

Google macht den ersten Schritt – Microsoft liefert die Spec mit

Am 10. Februar 2026 kündigte Google über den Chrome Developer Blog die WebMCP Early Preview in Chrome 146 Canary an. Zeitgleich veröffentlichten Google- und Microsoft-Engineers den Draft Community Group Report der W3C Web Machine Learning Community Group.

Das ist bemerkenswert – aber kein "Standard". WebMCP ist aktuell ein Community Group Draft, die niedrigste Stufe im W3C-Prozess. Der Weg zum echten W3C-Standard dauert typischerweise 3-5 Jahre und erfordert mehrere unabhängige Browser-Implementierungen.

Browser-Status (Februar 2026):

• Chrome 146 Canary: Early Preview hinter Feature-Flag – produktive Nutzung nicht empfohlen
• Chrome 145 Stable: Kein WebMCP-Support
• Edge, Firefox, Safari: Keine Implementierung, keine öffentliche Roadmap

Microsoft-Engineers (Brandon Walderman, Leo Lee, Andrew Nolan) haben die Spec mitgeschrieben, aber Edge hat WebMCP nicht implementiert. Kyle Pflug (Edge Product Manager) bestätigte nur "interest and participation" – keine Ankündigung, kein Zeitplan.

Dennoch: Die Signale sind stark. Die Spec wird von der W3C Web Machine Learning Community Group (~188 Teilnehmer, 51 Organisationen) getragen. Google und Microsoft als Co-Autoren signalisieren ernsthaftes Interesse – auch wenn der Weg noch lang ist.

Der Unterschied: Strukturierte Kontrolle statt Parser-Lotterie

Die Theorie: Mit WebMCP definierst du, welche Aktionen ein Agent ausführen darf. Du gibst Parameter vor (z. B. "Projektbudget zwischen 50k und 500k"). Du validierst Eingaben, bevor sie dein CRM erreichen.

Die Hoffnung: Das ist der Unterschied zwischen "Agent rät, was du anbietest" und "Agent nutzt deine offiziellen Daten".

Der Vorbehalt: Das ist Marketing-Sprech von Google/Microsoft, nicht empirisch belegt. Kein Unternehmen kann heute nachweisen, dass WebMCP-Implementierung zu weniger Agent-Fehlern führt – die Technologie ist 8 Tage alt.

Das Argument ist plausibel (strukturierte Daten schlagen Parsing), aber es fehlen Case Studies, A/B-Tests, oder Langzeit-Daten. Nenn es "informierte Spekulation", nicht "bewiesene Tatsache".

WebMCP in der Praxis: Zwei APIs, unterschiedliche Komplexität

WebMCP bietet zwei Ansätze – mit drastisch unterschiedlichem Aufwand:

1. Declarative API: HTML-Attribute für einfache Formulare

Wer profitiert: Websites mit sauberen, statischen HTML-Formularen.

Chrome 146 führt Custom Attributes ein, die aus bestehenden Formularen automatisch maschinenlesbare "Tools" generieren:

<form toolname="scheduleConsultation"
     tooldescription="Bucht ein 60-minütiges Erstgespräch zur Bedarfsklärung"
     toolautosubmit="false">
 
 <input type="email" name="email" required
        toolparamdescription="E-Mail-Adresse des Interessenten">
 
 <select name="topic" required
         toolparamdescription="Beratungsthema">
   <option value="pmi">Post-Merger-Integration</option>
   <option value="restructuring">Restrukturierung</option>
 </select>
 
 <button type="submit">Termin anfragen</button>
</form>


Wichtig zu verstehen:

• toolautosubmit="false" bedeutet: Der Agent füllt das Formular aus, aber der Nutzer muss manuell auf Submit klicken. Das ist der Human-in-the-Loop-Mechanismus.
• Die Attribute sind Chrome-Features, nicht Teil der W3C-Spec. Die finale Syntax könnte sich ändern.
• Browser generieren automatisch JSON-Schema aus den <input>-Feldern.

Realistischer Aufwand: 1-2 Stunden für ein einfaches Formular, inkl. Testing mit Chrome DevTools und Model Context Tool Inspector Extension.

2. Imperative API: JavaScript für komplexe Interaktionen

Wer braucht das: SPAs, Multi-Step-Workflows, OAuth-Flows, dynamische Prozesse.

navigator.modelContext.registerTool({
 name: "filterProjects",
 description: "Filtert Projektreferenzen nach Branche und Unternehmensgröße",
 inputSchema: {
   type: "object",
   properties: {
     industry: { type: "string", enum: ["automotive", "manufacturing", "logistics"] },
     companySize: { type: "string", enum: ["50-200", "200-500", "500+"] }
   },
   required: ["industry"]
 },
 async execute(params, client) {
   // Geschäftslogik hier
   const results = await fetchFilteredProjects(params);
   
   // Optional: Nutzer-Bestätigung anfordern
   if (results.length > 100) {
     await client.requestUserInteraction({
       prompt: `${results.length} Projekte gefunden. Alle anzeigen?`
     });
   }
   
   return { results };
 }
});


Realistischer Aufwand: Tage bis Wochen für produktionsreife Implementierung, besonders bei tightly-coupled SPAs (React/Redux), wo Geschäftslogik von UI-Rendering getrennt werden muss.

⚠️ Wichtig zur Spec-Syntax: Die W3C-Spec zeigt die JavaScript-API (navigator.modelContext), definiert aber keine Implementierungs-Details für die Methoden registerTool(), unregisterTool(), und requestUserInteraction() – diese enthalten buchstäblich TODO: fill this out Placeholder. Chrome 146 implementiert sie pragmatisch, aber die finale API könnte anders aussehen.

Wer profitiert zuerst – und wer Zeit hat

First-Mover-Vorteil: Branchenabhängig und spekulativ

Branchen mit potenziell hohem Agent-Impact (2027/28?):

• Unternehmensberatung, Rechtsberatung, Steuerberatung: Komplexe Recherche-Prozesse, viele Vergleichskriterien, Multi-Stakeholder-Entscheidungen
• B2B-Software & SaaS: Feature-Vergleiche, Integrations-Checks, Demo-Buchungen sind strukturierbar
• Technische Dienstleister: Kompetenznachweise, Projekt-Portfolios, Verfügbarkeits-Checks

Branchen mit wahrscheinlich niedrigerem Impact:

• Handwerk, Gastronomie, Retail: Lokale Suche und Bewertungen dominieren
• Hochpreisige B2B C-Marken: Emotionale Kaufentscheidungen, menschlicher Touchpoint bleibt zentral

Was passiert, wenn WebMCP tatsächlich relevant wird?

Die Datengrundlage: Gartner prognostiziert, dass bis 2028 90% der B2B-Buying-Prozesse durch Agenten intermediiert werden (nicht vollautomatisiert, sondern unterstützt). Eine separate Studie sagt: 15% der Work Decisions werden autonom von Agenten getroffen.

Wichtige Einordnung: Das sind Trendextrapolationen, keine Fakten. Gartner selbst räumt ein, dass 40% der aktuellen Agentic-AI-Projekte bis Ende 2027 gecancelt werden. Die Zahlen zeigen Potential, nicht Gewissheit.

Drei mögliche Szenarien:

Szenario 1 (plausibel): Du wirst gefunden, aber die Conversion-Rate bei Agent-Traffic ist niedriger, weil Formulare nicht zuverlässig interpretiert werden können.

Szenario 2 (spekulativ): Agenten bevorzugen strukturierte Websites – ähnlich wie Google heute Page Experience berücksichtigt. Keine Beweise, aber technisch naheliegend.

Szenario 3 (sehr spekulativ): Google/Microsoft integrieren WebMCP in Ranking-Faktoren. Aktuell gibt es dafür null Hinweise.

Die ehrliche Einschätzung: Niemand weiß, wie schnell und ob überhaupt Agent-basierte B2B-Recherche relevant wird. WebMCP ist ein Hedge – low cost (wenn Infrastruktur stimmt), potentiell high impact (wenn die Prognosen stimmen).

⚠️ Realitäts-Check (Stand Februar 2026)

WebMCP ist aktuell experimentell (Chrome 146 Canary). Wir bauen hier keine Luftschlösser, sondern bereiten das Fundament. Die Spec ist nicht final, Browser-Support ist begrenzt, produktive Nutzung noch nicht empfohlen.

Aber: Schema.org und llms.txt funktionieren heute. WebMCP-Attribute schaden nicht (werden ignoriert, wenn Browser sie nicht kennt). Früh verstehen = Vorsprung haben.

Die kritischen Stimmen: Was gegen WebMCP spricht

Nicht jeder ist begeistert. Die Skepsis ist berechtigt und sollte Teil der Abwägung sein.

"Wir bauen das Web für Maschinen um, nicht für Menschen"

Kritiker argumentieren: WebMCP macht Websites maschinenfreundlicher, aber nicht nutzerfreundlicher. Der Aufwand fließt in Agent-Optimierung statt in UX-Verbesserung.

Gegenargument: Eine gut strukturierte Website hilft beiden. Klare Call-to-Actions, validierte Formulare, strukturierte Daten – das sind auch für Menschen bessere Websites. WebMCP formalisiert nur, was ohnehin gute Praxis ist.

"Das ist der nächste SEO-Wahnsinn"

Die Befürchtung: WebMCP wird das neue Keyword-Stuffing. Websites werden mit Tools vollgestopft, um in Agent-Rankings aufzutauchen – Qualität spielt keine Rolle mehr.

Gegenargument: Möglich. Aber: Agenten sind darauf trainiert, Spam zu erkennen. Ein Tool scheduleConsultation, das zu einer 404-Seite führt, schadet mehr als es nützt. Die Qualität der dahinterliegenden Prozesse bleibt entscheidend.

"Wir wissen noch gar nicht, wie Agenten wirklich arbeiten werden"

Die vielleicht stärkste Kritik: WebMCP löst ein Problem, das wir noch nicht vollständig verstehen. Wie Agenten in 3 Jahren tatsächlich mit Websites interagieren – das ist Spekulation.

Gegenargument: Korrekt. Aber: Strukturierte Daten schaden nie. Selbst wenn WebMCP scheitert, sind sauber definierte Tools, Parameter und Validierungen auch für andere Technologien nützlich. Der Aufwand ist überschaubar, das Risiko gering.

Sicherheit: Kontrolle ja, aber unvollständig

Die unbequeme Wahrheit: Die W3C-Spec enthält null Security-Guidance. Section 3 ("Security and privacy considerations") ist komplett leer. Alle Security-Mechanismen stammen aus Chromes Implementierung, nicht aus normativen Spec-Vorgaben.

Was Chrome 146 implementiert:

• HTTPS-Pflicht (SecureContext)
• Origin-Isolation (Tools erben die Origin der Host-Seite)
• Browser-Mediation (Agenten kontaktieren Seiten nie direkt)
• User-Consent-Prompts für neue Agent-Website-Pairs
• SubmitEvent.agentInvoked-Flag (Server kann Agent-Requests erkennen)

Was NICHT existiert:

• ❌ Kein eingebautes Rate Limiting (Entwickler müssen selbst implementieren)
• ❌ requestUserInteraction() ist opt-in, nicht mandatory
• ❌ destructiveHint-Annotation ist rein advisory
• ❌ Keine OAuth-ähnliche Permission-Granularität

Bekannte, ungelöste Vulnerabilities:

"Lethal Trifecta" (benannt von W3C-Mitglied Tom Jones): Agent liest sensible Daten aus Tab A → begegnet malicious Content → nutzt Tool aus Tab B zur Exfiltration. Jeder Einzelschritt ist legitim, die Kombination gefährlich.

Prompt Injection: Tool-Descriptions sind für LLMs sichtbar und können versteckte Instruktionen enthalten. Google-Engineers bestätigen: "Protection is the responsibility of individual AI agents."

Session Hijacking: Tools erben User-Sessions. Kompromittiertes Tool = voller Account-Zugriff.

Bottom Line: WebMCP 2026 ist für Experimente geeignet, nicht für produktive Workflows mit sensiblen Daten. Mehrere unabhängige Sicherheitsforscher empfehlen: Sandbox-Umgebungen, explizite Validierung, Audit-Trails.

Technische Realitäten: Was WebMCP nicht kann

Performance: Zusätzliche Attribute erhöhen HTML-Größe minimal (< 1% bei typischen Sites). Kein messbarer Performance-Impact.

Fallback: Browser ohne WebMCP-Support ignorieren die Attribute – die Website funktioniert normal. Kein Risiko für bestehende User.

Limitationen: WebMCP macht Formulare maschinenlesbar, aber ersetzt keine API. Komplexe Workflows (Multi-Step-Prozesse, OAuth, Payments) brauchen weiterhin echte Integrationen.

Die ehrliche Roadmap: Experimentieren ja, Produktion nein

Status Quo (Februar 2026)

• Chrome 146 Canary: Early Preview hinter Feature-Flag (chrome://flags/#web-mcp)
• Chrome 145 Stable: Kein WebMCP (aktuell produktiv)
• Chrome 146 Stable: Erwartet ~10. März 2026, aber WebMCP bleibt flag-gated
• Andere Browser: Keine Implementierung, keine Timeline
• W3C-Status: Draft Community Group Report – kein Standard, keine formale Endorsement

Das heißt: WebMCP ist für Experimente und Proof-of-Concepts gedacht, nicht für produktive Business-Prozesse. Google selbst empfiehlt: "Developers should test and provide feedback, not deploy to production."

Realistische Zeitachse

Jetzt (Q1/Q2 2026):

• [ ] Schema.org auditieren – Basis-Hygiene für maschinelle Lesbarkeit
• [ ] llms.txt erstellen – 2-3 Stunden, sofort wirksam für LLM-Suche
• [ ] WebMCP Canary-Build testen – Verstehen, wie die API funktioniert
• [ ] GitHub-Issues verfolgen (github.com/webmachinelearning/webmcp)

Später (Q3/Q4 2026):

• [ ] Erste Attribute testen – Wenn Chrome Stable Support bringt
• [ ] Feedback geben – Chrome DevRel nimmt aktiv Rückmeldungen entgegen
• [ ] Spec-Änderungen beobachten – Syntax könnte sich noch ändern

2027+ (wenn W3C Working Group adoptiert):

• [ ] Multi-Browser-Support abwarten – Minimum 2 unabhängige Implementierungen nötig
• [ ] Security-Audits – Erst wenn Spec Security-Section hat
• [ ] Produktiv-Rollout evaluieren

Was du heute nicht tun solltest

❌ WebMCP für geschäftskritische Prozesse nutzen
❌ Davon ausgehen, dass Syntax stabil bleibt
❌ Sensible User-Daten über WebMCP-Tools verarbeiten
❌ Auf Edge/Firefox/Safari-Support spekulieren

Der pragmatische Mittelweg: Technologie verstehen, Konzepte testen, aber produktive Infrastruktur nicht darauf aufbauen – noch nicht.

Fazit: Früh verstehen schlägt blindes Warten – aber nicht blindes Umsetzen

WebMCP ist kein Hype, aber auch kein fertiger Standard. Es ist ein substantieller Versuch von Google und Microsoft, das Agent-Web-Problem zu lösen – mit offenem W3C-Prozess, klaren technischen Konzepten, und einer funktionierenden (wenn auch experimentellen) Implementierung.

Was wir wissen:

• Die Technologie funktioniert (Chrome 146 Canary)
• Zwei Tech-Giganten investieren Engineering-Ressourcen
• Die W3C Community Group trägt die Spec mit
• Das Problem (Agenten brauchen strukturierte Interaktionen) ist real

Was wir nicht wissen:

• Ob andere Browser nachziehen
• Wann (und ob) das W3C Working Group die Spec adoptiert
• Ob die Security-Lücken adressiert werden können
• Wie schnell sich Adoption entwickelt

Die Frage ist nicht: "Kommt WebMCP garantiert?"
Die Frage ist: "Was verliere ich, wenn es kommt und ich bin nicht vorbereitet – vs. was verschwende ich, wenn ich zu früh investiere?"

Für die meisten B2B-Unternehmen lautet die Antwort: Vorbereiten (Schema.org, llms.txt), beobachten (GitHub, ChromeStatus), verstehen (Canary-Tests) – aber nicht produktiv ausrollen.

Wer 2026 die Grundlagen legt, gewinnt 2027 oder 2028 Zeit. Wer 2026 alles auf WebMCP setzt, trägt unnötiges Risiko.

Ist deine Website agent-ready?

In 30 Minuten weißt du:

• Ob deine Schema.org-Metadaten vollständig sind (oder welche fehlen)
• Wie du llms.txt für dein Geschäftsmodell aufbauen solltest
• Welche 3 CTAs du zuerst mit WebMCP ausstatten solltest

Das Ergebnis: Eine priorisierte Checkliste – keine Marketing-Präsentation.

30 Minuten, unverbindlich, ohne Verkaufsgespräch.

Weil wir glauben: Wer heute vorbereitet ist, gewinnt morgen – wann immer morgen kommt.

→ Discovery Call buchen (Ja, dieser Button wird agent-ready sein.)

‍