WebMCP: Ich habe meine Website für KI-Agenten bedienbar gemacht
Elf Werkzeuge, feste Obergrenzen, ein bewusst fehlender Absende-Knopf: ein Werkstattbericht über den W3C-Entwurf document.modelContext – und die ehrliche Antwort, ob ein kleiner Betrieb das braucht.
Wenn heute ein KI-Agent im Browser eine Website bedienen soll, macht er im Kern dasselbe wie ein Mensch mit verbundenen Augen: Er schaut sich ein Bild der Seite an, rät, wo ein Knopf sein könnte, klickt, schaut wieder. Das funktioniert erstaunlich oft und scheitert zuverlässig an Kleinigkeiten – einem Cookie-Banner, einem Dropdown, einem Formularfeld ohne Beschriftung.
WebMCP dreht das um. Statt dass der Agent die Website errät, übergibt die Website dem Agenten eine Liste dessen, was sie kann: Name, Beschreibung, erwartete Parameter. Der Agent ruft auf, statt zu klicken.
Ich habe das auf dieser Website umgesetzt – nicht als Studie, sondern weil ich wissen wollte, was dabei tatsächlich herauskommt. Hier ist der Werkstattbericht, einschließlich der Teile, die ich bewusst weggelassen habe.
Der Stand der Technik
Ehrlich vorweg, weil das bei diesem Thema selten passiert:
- Es ist ein Entwurf, kein Standard. Die Spezifikation liegt bei einer Community Group des W3C, bearbeitet von Leuten bei Google und Microsoft, zuletzt aktualisiert Ende Juli 2026.
- Chrome 146 hat die Schnittstelle im Februar 2026 ausgeliefert, seit Mai läuft ein Origin Trial für den Einsatz auf echten Websites. Andere Browser haben nichts zugesagt.
- Der Name wandert gerade von
navigator.modelContextzudocument.modelContext. Wer heute etwas baut, baut auf beweglichem Grund. - Ohne Token bleibt es unsichtbar. Für den Einsatz auf einer echten Domain braucht es ein Origin-Trial-Token, das befristet ist. Meines läuft im November 2026 aus.
Wer daraus schließt, dass das Thema für einen Handwerksbetrieb in Pirna heute keine Priorität hat, liegt richtig. Ich schreibe trotzdem darüber, weil der Umbau etwas anderes zutage gefördert hat – dazu am Ende.
Was auf dieser Website liegt
Elf Werkzeuge. Sieben davon auf jeder Seite:
| Werkzeug | Was es tut |
|---|---|
get_site_overview |
Anbieter, Leistungen mit Preisspannen, Region, Kontaktwege |
search_site |
Volltextsuche über alle Seiten, mit Ausschnitt und Adresse |
list_services |
die fünf Leistungen mit Preisspanne von–bis |
list_references |
Kundenprojekte, filterbar nach Branche, Leistung, Jahr |
list_articles |
Ratgeberartikel, zuletzt aktualisierte zuerst |
get_page_outline |
Überschriftenbaum der offenen Seite |
get_section |
Text eines Abschnitts – liest auch zugeklappte FAQ-Antworten |
Vier weitere melden sich nur dort an, wo die Seite sie hergibt: das Kontaktformular vorausfüllen, die Fragen des Preisrechners abrufen, eine Preisspanne berechnen, die 34 Prüfpunkte des DSGVO-Checks ausgeben.
Das interessanteste ist estimate_price. Es rechnet nicht selbst. Es bedient denselben Preisrechner, den ein Mensch bedient – über eine schmale Schnittstelle, die der Rechner ohnehin bereitstellt. Ergebnis: Die berechnete Spanne steht danach sichtbar auf der Seite und lässt sich ganz normal mit „Anfrage senden“ weiterreichen. Kein zweiter Rechenweg, der irgendwann von der Website abweicht.
Die Grenzen stehen im Code, nicht im Vertrauen
Der Teil, den ich beim Bauen am wichtigsten fand. Fünf feste Obergrenzen, über keinen Parameter zu überschreiben:
| Grenze | Wert |
|---|---|
| Datensätze je Aufruf | 25 |
| Suchtreffer je Aufruf | 8 |
| Zeichen je Antwort | 1.500 |
| Zeichen je Textausschnitt | 180 |
| Aufrufe je Werkzeug und Minute | 12 |
Wird eine Antwort zu lang, fallen ganze Datensätze weg statt Zeichen, und das Werkzeug meldet, dass gekürzt wurde. Jede Liste hat eine Blätterfunktion – ein Agent holt sich die nächste Seite, statt einmal alles abzuräumen. Fehler kommen als lesbarer Text zurück, nicht als Absturz, damit ein Agent darauf reagieren kann statt es erneut zu versuchen.
Was ich bewusst weggelassen habe
Hier wird es für alle interessant, die selbst so etwas planen.
Kein Absenden des Kontaktformulars. Ein Agent kann Name, E-Mail und Nachricht eintragen. Abschicken muss ein Mensch. Zwei Gründe:
Erstens würde ein vom Agenten ausgelöster Versand mit einer beliebigen fremden Adresse meinen Server zum Weiterleiter für Mails an Dritte machen. Das ist kein theoretisches Risiko, das ist ein offenes Scheunentor.
Zweitens – und grundsätzlicher – kann ein Agent Anweisungen aus Text übernehmen, den er unterwegs gelesen hat. Die Schnittstelle sieht einen Hinweis vor, mit dem eine Website eine Aktion als folgenreich markieren kann. Das ist ein Hinweis, keine Sperre. Auf einen Hinweis baut man keine Sicherheit.
Keine Kontaktdaten Dritter, nichts hinter Login, keine internen Nummern. Alles, was ein Werkzeug herausgibt, steht ohnehin öffentlich auf der Website.
Kein Volltext am Stück. Die Suche gibt einen Ausschnitt und die Adresse zurück. Wer den ganzen Bestand will, nimmt die JSON-Datei, die es sowieso gibt – derselbe Inhalt, der auch in der Sitemap steht.
Lohnt sich das für einen kleinen Betrieb?
Heute: nein. Die ehrliche Rechnung sieht so aus:
| Dafür | Dagegen |
|---|---|
| Wer früh dabei ist, versteht es, bevor es gebraucht wird | Nur ein Browser, nur mit befristetem Token |
| Die Schnittstelle passt gut zu Buchung, Rechner, Verfügbarkeit | Spezifikation ändert sich noch, Namen wandern |
| Gute Vorarbeit für das, was ohnehin kommt | Heute praktisch null Besucher, die es nutzen |
Ich würde es einem Kunden nur dann vorschlagen, wenn die Website einen echten Vorgang hat, den man automatisieren kann – Terminbuchung, Verfügbarkeitsabfrage, Konfiguration – und wenn alles Grundlegende erledigt ist. Bei einer Visitenkarten-Website mit fünf Seiten gibt es schlicht kein Werkzeug, das sich anzumelden lohnt.
Der Nebeneffekt, der es trotzdem wert war
Beim Bauen muss man eine Frage beantworten, die sonst niemand stellt: Was kann man auf dieser Website eigentlich tun?
Nicht „welche Seiten gibt es“. Sondern: Welche Handlung führt ein Besucher hier aus? Bei mir kam heraus: Leistungen vergleichen, Referenzen nach Branche filtern, Preisspanne berechnen, Artikel durchsuchen, Kontakt aufnehmen. Fünf Vorgänge.
Und dann sieht man, welche davon auf der Website selbst umständlich sind. Der Preisrechner hatte keine saubere Schnittstelle nach innen – die musste ich erst bauen, und seitdem ist er auch im normalen Betrieb besser zu warten. Die Artikelsuche gab es gar nicht.
Das ist der eigentliche Gewinn und der Grund, warum ich das hier aufschreibe: Die Übung, eine Website als Liste von Handlungen statt als Liste von Seiten zu beschreiben, verbessert sie für Menschen genauso. Wer das einmal für seinen eigenen Betrieb macht – auf Papier, ohne eine Zeile Code –, findet zuverlässig zwei Dinge, die zu kompliziert sind.
Wer stattdessen bei den Grundlagen anfangen will: Der Selbsttest in zwölf Checks prüft genau das, und Check 10 bis 12 sind derselbe Gedanke ohne Schnittstelle.
Häufige Fragen
Was ist WebMCP in einem Satz?
Eine Browser-Schnittstelle, über die eine Website einem KI-Agenten eine Liste ihrer Funktionen übergibt – mit Namen, Beschreibung und erwarteten Parametern –, damit der Agent sie aufrufen kann, statt sich durch Screenshots und geratene Klickpunkte zu arbeiten.
Welche Browser unterstützen das?
Derzeit im Wesentlichen nur Chrome. Die Schnittstelle kam mit Chrome 146 im Februar 2026, seit Mai 2026 läuft ein Origin Trial für den Einsatz auf echten Websites. Edge dürfte folgen, weil es dieselbe Basis nutzt; Firefox und Safari beteiligen sich an der Spezifikation, haben aber nichts zugesagt. Es ist ein Entwurf einer W3C-Arbeitsgruppe, kein verabschiedeter Standard.
Braucht mein Betrieb das jetzt?
Nein. Die Zahl der Besucher, die heute mit einem Agenten kommen, der die Schnittstelle nutzt, liegt bei den meisten Websites bei null. Es ist eine Wette auf die nächsten zwei Jahre, kein Pflichtprogramm. Wer die Grundlagen nicht erledigt hat – Indexierung, Ladezeit, verständliche Seiten –, arbeitet an der falschen Stelle.
Ist es gefährlich, einem Agenten Werkzeuge zu geben?
Es kommt darauf an, welche. Lesende Werkzeuge sind unkritisch. Alles, was nach außen wirkt – Nachrichten versenden, Bestellungen auslösen –, ist heikel, weil ein Agent Anweisungen aus fremdem Text übernehmen kann. Deshalb schickt auf dieser Website kein Werkzeug etwas ab; Formulare werden höchstens ausgefüllt, abgeschickt wird von Hand.