WebMCP: Wie deine Website zum Werkzeug für KI-Agenten wird

KI-Agenten, die im Browser Aufgaben erledigen, haben heute ein Wahrnehmungsproblem: Sie sehen Websites als Pixel und DOM-Bäume, raten, wo man klickt, und scheitern an allem, was vom Standard abweicht. WebMCP dreht die Richtung um – die Website sagt dem Agenten selbst, was sie kann. Wir haben das nicht nur gelesen, sondern gebaut: Sechs Tools laufen produktiv auf dieser Site. Dieser Artikel erklärt den Vorschlag und teilt die Praxiserfahrung.

Das Problem: Agenten raten, statt zu wissen

Ein Browser-Agent, der auf einer fremden Website ein Kontaktformular ausfüllen soll, arbeitet heute wie ein sehr geduldiger Praktikant ohne Einweisung: Screenshot machen, Felder erkennen, Koordinaten klicken, hoffen. Das funktioniert erstaunlich oft – und bricht bei Custom-Dropdowns, mehrstufigen Formularen oder ungewöhnlichem Markup lautlos.

Für Website-Betreiber heißt das: Ob ein Agent deine Seite bedienen kann, entscheidet heute der Zufall deines Markups. WebMCP macht daraus eine bewusste Entscheidung.

Der Vorschlag: document.modelContext

WebMCP (Web Model Context) ist ein Entwurf der W3C Web Machine Learning Community Group, maßgeblich von Google- und Microsoft-Ingenieuren getrieben. Der Kern ist eine kleine JavaScript-API:

document.modelContext.registerTool({
  name: 'lookup_glossary_term',
  description: 'Schlägt einen Webentwicklungs-Begriff im Glossar nach.',
  annotations: { readOnlyHint: true },
  inputSchema: {
    type: 'object',
    properties: { term: { type: 'string' } },
    required: ['term'],
  },
  execute: async ({ term }) => findInGlossary(term),
});

Ein agentenfähiger Browser sammelt diese Registrierungen ein und bietet sie dem Agenten als Werkzeuge an – mit Name, Beschreibung und Parametern als Schema statt als Rätsel. Wer das serverseitige MCP kennt, erkennt das Muster: dieselbe Idee, nur dass die Website selbst der Tool-Anbieter ist und nichts weiter gehostet werden muss.

Der Stand (bei Veröffentlichung dieses Artikels): Die API läuft in Chrome als Origin Trial und hat im Sommer 2026 bereits ihren Namespace gewechselt – von navigator.modelContext zu document.modelContext. Das ist die ehrliche Einordnung: ein Standard im Werden, keine fertige Plattform.

Unser Praxis-Case: sechs Tools auf dieser Website

Wir wollten nicht über Agenten-Web schreiben, ohne es zu betreiben. Auf codeaeffchen.de laufen produktiv:

Tool	Typ	Zweck
Kontaktformular-Info	lesend	Felder, Pflichtangaben und Budget-Optionen als Schema
Formular vorausfüllen	schreibend	Trägt Daten des Nutzers ins Formular ein – absenden bleibt beim Menschen
Kontakt-Modal öffnen	UI	Öffnet den Kontakt-Dialog mit vorbelegtem Betreff
Glossar-Lookup	lesend	69 Fachbegriffe mit Definition und zitierbarer URL
Leistungs-Übersicht	lesend	Angebote mit öffentlichen Preisankern und Seiten-URLs
Wartungspakete	lesend	Die drei Pakete mit Preisen, Reaktions- und Servicezeiten

Die wichtigsten Lektionen aus dem Bau:

1. Progressive Enhancement ist nicht verhandelbar. Unsere Einbindung ist ein kompletter No-op, wenn document.modelContext fehlt – kein Fehler, kein Performance-Kostenpunkt, kein Verhalten ändert sich für normale Besucher. Das macht die Investition risikofrei: Im schlechtesten Fall passiert nichts.

2. Lesende Tools zuerst. Fünf unserer sechs Tools sind read-only (readOnlyHint: true). Sie beantworten die Fragen, die ein Agent für seinen Nutzer klären will – was bietet diese Agentur, was kostet Wartung, was heißt dieser Fachbegriff – ohne dass irgendetwas passieren kann. Schreibende Aktionen brauchen mehr Sorgfalt: Unser Formular-Tool füllt aus, aber der Mensch sendet ab.

3. Strukturierte Daten zahlen doppelt ein. Die Tools liefern dieselben Preise und Fakten wie die Seiten selbst, aus derselben zentralen Quelle. Wer seine Inhalte schon als Daten pflegt (statt als Fließtext-Kopien), registriert Tools in Minuten. Wer nicht, hat das eigentliche Problem woanders.

4. Ein API-Wechsel ist eingepreist. Der Namespace-Umzug von navigator zu document hat uns eine Zeile gekostet, weil die Registrierung zentral liegt. Bei experimentellen APIs gehört genau das zum Design: eine Stelle, die sich ändert – nicht zwanzig.

Sicherheit: öffentliche API-Fläche, bewusst gestaltet

Ein registriertes Tool ist eine Einladung an fremde Software. Die Regeln, nach denen wir gebaut haben:

• Nur, was die UI auch kann. Kein Tool tut etwas, das ein Besucher nicht ohnehin per Klick könnte. WebMCP ist eine Bedienhilfe, keine Hintertür.
• Nichts Vertrauliches. Tools liefern ausschließlich öffentliche Seiteninhalte – strukturiert, aber nicht exklusiv.
• Mensch behält die Hand auf irreversiblen Aktionen. Ausfüllen ja, absenden nein.
• Schema streng halten. Enge Input-Schemas sind hier nicht Pedanterie, sondern Angriffsflächen-Begrenzung.

Lohnt sich das jetzt?

Ehrlich: Der messbare Nutzen ist heute klein, weil agentenfähige Browser erst als Origin Trial und hinter Flags existieren. Wer nur auf kurzfristige Effekte schaut, kann warten.

Wir sehen drei Gründe, trotzdem jetzt zu bauen: Die Kosten sind minimal (unsere sechs Tools waren zusammen ein überschaubarer Nachmittag – weil die Datenbasis stand). Das Risiko ist null (No-op ohne API). Und die Lernkurve ist real – wer heute versteht, wie Websites sich Agenten erklären, gestaltet mit, statt 2027 hinterherzubauen. Es ist dieselbe Logik wie bei allen GEO-Maßnahmen: Die Website wird schrittweise maschinenlesbarer, jede Stufe steht für sich.

Wenn du wissen willst, wie deine Website agentenfähig wird – von strukturierten Daten über llms.txt bis zu WebMCP-Tools: Genau diese Art Fundament bauen wir in unseren Website-Projekten mit ein.