Wenn ein KI-Agent heute eine Website bedienen soll, macht er im Kern das, was auch ein Mensch tut: Er lädt die Seite, macht sich ein Bild vom Layout und rät anhand von Screenshots oder DOM-Struktur, wo er klicken muss. Das funktioniert, ist aber fehleranfällig und langsam. Auf naegler.hamburg gehe ich einen anderen Weg: Statt dass ein Agent die Seite errät, stellt die Seite ihre Funktionen selbst als strukturierte, aufrufbare Tools bereit – über WebMCP, das Web Model Context Protocol.
TL;DR: WebMCP bringt die Idee von MCP-Tools für KI-Modelle in den Browser. Auf naegler.hamburg registriert die Seite vier Tools (Blog filtern, Volltextsuche, zu einem Themenbereich springen, Kontaktanfrage bauen), alles als Progressive Enhancement über Vanilla JS, ohne Framework. Die Umsetzung nutzt fast ausschließlich Bestehendes: TYPO3-Menüs, Route Enhancer, einen JSON-Index für die Suche. WebMCP selbst ist aber ein früher, experimenteller Community-Group-Entwurf mit nur einem Browser in einem Origin Trial – kein fertiger, browserübergreifender Standard.
Was WebMCP ist – und was (noch) nicht
WebMCP wurde am 10. Februar 2026 als Draft Community Group Report der Web Machine Learning Community Group veröffentlicht, redaktionell betreut von Brandon Walderman (Microsoft), Khushal Sagar und Dominic Farolino (beide Google). Das ist ausdrücklich kein W3C-Standard und steht nicht auf dem offiziellen W3C-Standards-Track, auch wenn die Community Group unter dem Dach der W3C arbeitet. Praktisch verfügbar ist WebMCP bislang nur in Chrome: erst hinter einem Flag (chrome://flags/#enable-webmcp-testing), inzwischen als Origin Trial ab Chrome 149. Firefox und Safari unterstützen die API nicht.
Ein konkreter Stolperstein bei der Umsetzung: Die W3C-Spezifikation hängt das ModelContext-Objekt an document (document.modelContext), weil die Tools an die Lebensdauer der Seite gebunden sind (page-scoped) – eine Navigation löscht sie wieder. Chromes Origin Trial liefert das Objekt aber, Stand jetzt, unter navigator.modelContext. Beide Namensräume sind nicht konvergiert, die API hat vorher schon einmal den Namen gewechselt (window.agent zu modelContext). Für die Praxis heißt das: beide Fundstellen feature-detecten, document zuerst prüfen.
// W3C-Spec: document.modelContext (page-scoped); Chrome-Origin-Trial: navigator.
var mc = document.modelContext || navigator.modelContext;
if (!mc || typeof mc.registerTool !== 'function' || !config) { return; }Die vier Tools
Site-weit, nicht nur auf der Blog-Seite, registriert naegler.hamburg vier Tools:
| Tool | Zweck | Parameter |
|---|---|---|
filter_blog | Blog-Übersicht nach Kategorie filtern, navigiert dorthin | kategorie (enum), client? |
search_articles | Volltextsuche über alle Blog-Beiträge, liefert strukturierte Treffer | query, limit?, client? |
navigate_to_topic | Sprung zur ersten Navigationsebene | bereich (enum), client? |
contact_request | Baut aus Angaben eine vorausgefüllte E-Mail (mailto), ohne Backend | anliegen (enum), name, nachricht, email?, telefon?, organisation?, client? |
Jedes Tool ist als Progressive Enhancement gebaut: Fehlt modelContext im Browser oder der Konfigurations-Block auf der Seite, deaktiviert sich der jeweilige Teil selbst. Normale Besucher merken davon nichts.
Ein Config-Block als einzige Quelle der Wahrheit
Die Grundlage für alle vier Tools ist ein einziger Konfigurations-Block, der auf jeder Seite gerendert wird: ein Fluid-Partial Page/WebMcp.html im Layout, befüllt vom TYPO3-DataProcessor WebMcpConfigProcessor. Er enthält unter anderem die Blog-URL, den Such-Index, die Kategorien und Themenbereiche samt ihrer URLs sowie die base64-obfuskierte Kontakt-E-Mail-Adresse.
Der aus meiner Sicht wichtigste Grundsatz dabei: Alle URLs werden von TYPO3 selbst erzeugt (ContentObjectRenderer::createUrl), nie im JavaScript zusammengebaut. Ein kategorie=drk wird über einen Route Enhancer mit Static-Value-Mapper automatisch zu /blog/katastrophenschutz. Route-Enhancer-Pfade und cHash stimmen dadurch immer, ohne dass das Frontend-JavaScript etwas über die interne URL-Logik wissen muss. Auch navigate_to_topic funktioniert nach diesem Prinzip: Ein Core-MenuProcessor erzeugt die erste Navigationsebene, der WebMcpConfigProcessor übernimmt sie unverändert in die Tool-Konfiguration. Menüänderungen wie neue Seiten, Umbenennungen oder ein geänderter nav_hide-Status schlagen automatisch durch, ohne dass an der WebMCP-Integration etwas angepasst werden muss.
Eine Suche für Mensch und Agent
Für die Volltextsuche gibt es genau eine Datenquelle: einen JSON-Artikelindex, umgesetzt als eigener TYPO3-Seitentyp unter /blog/index.json (Route-Enhancer-Suffix, gecacht wie der RSS-Feed für eine Stunde). Ein BlogIndexProcessor liefert darüber alle Beiträge mit Titel, Teaser, Kategorie und URL. Auf der sichtbaren Blog-Seite filtert ein Suchfeld client-seitig live über genau diesen Index, mit Mehrwort-UND-Matching über Titel, Teaser und Kategorie und einem Deep-Link der Form /blog#q=begriff. Das Agenten-Tool search_articles greift auf denselben Index zu und liefert strukturierte Treffer inklusive searchUrl zurück. Es gibt also keinen doppelten Code und keine separate "Agenten-API" – ein Endpoint versorgt beide Seiten.
contact_request ohne Formular und ohne Backend
Beim vierten Tool habe ich mich bewusst gegen ein klassisches Kontaktformular entschieden. Der Agent sammelt die nötigen Angaben, das Tool baut daraus einen -Link mit strukturiertem Betreff ("Anfrage über naegler.hamburg – <Anliegen>") und Body und öffnet das Mailprogramm des Nutzers. Es gibt keine serverseitige Speicherung, kein Formular und damit auch keine zusätzliche Spam- oder DSGVO-Verarbeitungsfrage. Die Zieladresse stammt aus dem TYPO3-Setting naeglerhamburg.person.email und liegt im Config-Block base64-obfuskiert vor, passend zum bestehenden spamProtectEmailAddresses-Ansatz; erst im JavaScript wird sie wieder dekodiert. Nicht jedes Tool braucht ein Backend – manchmal gewinnt der schlankste, datensparsamste Weg.
Nutzungs-Analytics ohne Drittanbieter
Damit sich überhaupt beantworten lässt, welches Tool wie oft genutzt wird, sendet jede execute-Funktion einen navigator.sendBeacon('/webmcp-event', {tool, client}). sendBeacon statt fetch ist hier kein Detail, sondern die Voraussetzung dafür, dass das Event überhaupt ankommt: filter_blog und navigate_to_topic navigieren sofort weg, ein laufender fetch-Request würde beim Seitenwechsel abgebrochen. Auf der Empfängerseite nimmt eine PSR-15-Middleware WebMcpEventMiddleware, die im Frontend-Stack vor typo3/cms-frontend/site sitzt, ausschließlich POST-Requests auf /webmcp-event an, prüft den Tool-Namen gegen eine Allowlist und verlangt Sec-Fetch-Site als Same-Origin-Nachweis. Sie sanitisiert den client-Wert und schreibt eine Zeile in die Datenbank, die Antwort ist immer ein schlichtes 204. Ausgewertet wird das über ein eigenes TYPO3-Backend-Modul ("Web → WebMCP") mit Filtern nach Tool, Client und Zeitraum sowie dependency-freien CSS-Balkendiagrammen. Gespeichert werden ausschließlich Tool-Name und ein kurzer Client-Hinweis, keine Freitexte wie Suchbegriffe oder Nachrichteninhalte, keine IP-Adressen, keine Cookies.
Die ehrliche Grenze: Wer ruft das Tool eigentlich auf?
Hier muss ich eine Erwartung dämpfen. Die W3C-Spezifikation übergibt der execute-Callback ausschließlich die Input-Parameter, keine Information über die Identität des aufrufenden Systems. Ob tatsächlich Claude, ChatGPT oder ein anderer Agent das Tool aufgerufen hat, lässt sich damit nicht zuverlässig feststellen. Der User-Agent-String hilft in der Praxis oft nicht weiter, weil viele Agenten mit einem gewöhnlichen Chrome-Kennzeichen unterwegs sind. Mein Best-Effort-Ansatz besteht aus drei Stufen: erstens ein optionaler client-Parameter, den der Agent selbst mitgeben kann, zweitens ersatzweise eine grobe User-Agent-Heuristik, drittens andernfalls schlicht "unbekannt". Das ist nicht fälschungssicher und soll auch nicht so verkauft werden – es handelt sich um eine Systemgrenze von WebMCP, nicht um eine Schwäche der eigenen Umsetzung.
Auffindbarkeit über llms.txt
Damit Agenten die Tools überhaupt finden, beschreibt ein eigener Abschnitt "WebMCP – Tools für KI-Agenten" in der llms.txt der Seite die vier Tools, den client-Parameter und den JSON-Index.
Fazit
- WebMCP erlaubt es, Website-Funktionen als strukturierte Tools direkt für KI-Agenten bereitzustellen, ist aber ein früher Community-Group-Entwurf mit Origin-Trial-Support bislang nur in Chrome.
- Die Umsetzung auf naegler.hamburg nutzt konsequent vorhandene TYPO3-Mechanismen (Route Enhancer, MenuProcessor, ein JSON-Index) statt eigener Parallel-Infrastruktur, und alles ist als Progressive Enhancement gebaut.
- Wer nutzt, lässt sich zählen; wer genau ruft (Claude, ChatGPT oder ein anderer Agent), lässt sich mit WebMCP nach heutigem Stand nur mit Einschränkungen sagen – das ist eine Systemgrenze, keine Umsetzungslücke.
- Je nachdem, wie sich WebMCP weiterentwickelt, könnte daraus am Ende eine eigene TYPO3-Extension werden. Aktuell ist das aber eher ein Experiment mit unklarem Ausgang.
Häufige Fragen
Ist WebMCP schon ein fertiger Web-Standard?
Nein. WebMCP ist ein Draft Community Group Report der Web Machine Learning Community Group, veröffentlicht am 10. Februar 2026, ohne Status auf dem offiziellen W3C-Standards-Track. Praktisch nutzbar ist die API bislang nur in Chrome, aktuell im Origin Trial.
Funktioniert WebMCP auch in Firefox oder Safari?
Nach aktuellem Stand nicht. Nur Chrome bietet die API an, zunächst hinter einem Flag, inzwischen im Origin Trial.
Merken normale Besucher der Seite etwas von WebMCP?
Nein. Die gesamte Integration ist als Progressive Enhancement umgesetzt: Fehlen modelContext im Browser oder der Konfigurations-Block, deaktivieren sich die Tools selbst, ohne dass sich am normalen Seitenbetrieb etwas ändert.