WebMCP

document.modelContext statt navigator.modelContext

WebMCP lässt eine Website ihre Fähigkeiten als benannte, typisierte Werkzeuge für KI-Agenten bereitstellen. Am 21. Juli 2026 hat die Spezifikation die Schnittstelle von navigator zu document verschoben, und Chrome 150 hat die alte Position abgekündigt. Dieser Leitfaden zeigt den aktuellen Stand, lauffähigen Code für beide APIs und was wir auf dieser Website selbst damit gebaut haben.

Eigene Website prüfen

Stand: 31. August 2026
Von uns selbst implementiert
Bis zu 25 von 100 Punkten im Check

Planung einer WebMCP- und MCP-Server-Architektur am Flipchart

Grundlagen

Was ist WebMCP?

WebMCP ist eine vorgeschlagene Browser-Schnittstelle, mit der eine Website ihre Fähigkeiten als Werkzeuge erklärt: benannte Funktionen mit einer Beschreibung in natürlicher Sprache und einem JSON-Schema für ihre Argumente. Ein KI-Agent, der den Browser bedient, liest diese Liste und ruft die Funktionen direkt auf, statt Ihr Markup zu interpretieren oder Screenshots davon auszuwerten.

Der Name ist Absicht. WebMCP übernimmt das Werkzeug-Vokabular des Model Context Protocol (MCP) und verlagert es in die Seite selbst, wo die Browser-Sitzung bereits die Anmeldung der Besucherin trägt. Genau das macht den größten Teil des Reizes aus: Es wechselt kein API-Schlüssel den Besitzer, es entsteht kein separater Server, und ein Werkzeug ist für einen Agenten nur dann verfügbar, wenn die Person, in deren Auftrag er handelt, bereits angemeldet ist.

Die Schnittstelle im Entwurf

Die Spezifikation erweitert Document um ein Attribut modelContext. Es ist eine Schnittstelle, die nur in sicherem Kontext (HTTPS) verfügbar ist, mit drei Methoden und einem Ereignis: registerTool, getTools, executeTool und ontoolchange. Ein Werkzeug ist ein Objekt mit name, description, inputSchema, execute und optionalen annotations. Namen sind auf 1 bis 128 Zeichen aus ASCII-Buchstaben, Ziffern, Unterstrich, Bindestrich und Punkt begrenzt — wichtig zu wissen, bevor Sie Namen aus einem CMS-Feld erzeugen.

Der Anlass für diese Seite

Warum ist navigator.modelContext abgekündigt?

Weil die Spezifikation am 21. Juli 2026 die Schnittstelle von navigator zu document verschoben hat und Chrome 150 die alte Position seither als abgekündigt führt. Die Begründung ist inhaltlich stichhaltig: Werkzeuge gehören zu einem Dokument, nicht zum Browser. Ein Tab mit Ihrem Warenkorb und ein Tab mit Ihrem Blog bieten unterschiedliche Fähigkeiten an, und navigator wird über den gesamten Browsing-Kontext geteilt — eine Ebene, auf der sich das nur umständlich abbilden ließ.

Der Origin Trial bedient die alte Position weiter. Genau das ist der gefährliche Teil: Bestehender Code läuft unverändert weiter — bis er es an einem Punkt, den Sie nicht kontrollieren, plötzlich nicht mehr tut. Anleitungen, die vor dem 21. Juli 2026 entstanden sind, zeigen deshalb durchgängig die alte Schnittstelle. Wer danach gebaut hat, baut gegen eine abgekündigte Schnittstelle, ohne es beim Testen zu bemerken.

Vorher — abgekündigt

await navigator.modelContext.registerTool({
  name: "search_products",
  description: "…",
  inputSchema: { /* … */ },
  execute: async (args) => { /* … */ },
});

Nachher — aktuell

await document.modelContext.registerTool({
  name: "search_products",
  description: "…",
  inputSchema: { /* … */ },
  execute: async (args) => { /* … */ },
});

Eine Übergangslösung, die beide Positionen bedient

Solange der Origin Trial navigator.modelContext noch bedient, lohnt sich ein einziger Zugriffspunkt, der beide Positionen kennt und den alten Pfad sichtbar markiert:

function modelContext() {
  if ("modelContext" in document) return document.modelContext;
  if ("modelContext" in navigator) {
    console.warn("[webmcp] Fallback auf das abgekündigte navigator.modelContext");
    return (navigator as any).modelContext;
  }
  return null;
}

const mc = modelContext();
if (mc) await mc.registerTool({ /* … */ });

Die Konsolen-Warnung ist kein Beiwerk: Sie ist der einzige Hinweis, der Ihnen verrät, welche Auslieferung noch auf dem alten Pfad läuft, sobald der Origin Trial die alte Position nicht mehr bedient.

Wonach Sie suchen sollten	Wo es sich versteckt
navigator.modelContext	Direkt im Anwendungscode
navigator?.modelContext	Optional verkettete Feature-Erkennung
"modelContext" in navigator	Weichen, die jetzt den falschen Zweig nehmen
@mcp-b/ Paketversionen	Vor Juli 2026 fixierte Polyfills
Kopierte Codeschnipsel	Aus Anleitungen, die vor dem 21. Juli 2026 entstanden
Eigene .d.ts-Typdefinitionen	Erweitern oft noch Navigator statt Document

Zwei Gewohnheiten halten die Kosten künftiger Verschiebungen begrenzt: einen einzigen Wrapper um registerTool schreiben, statt die Schnittstelle im ganzen Code zu verstreuen, und Werkzeugdefinitionen als reine Daten halten, getrennt vom eigentlichen Registrierungsaufruf.

Einordnung

Wie unterscheidet sich WebMCP von einem MCP-Server?

Die entscheidende Frage lautet: Wer hält die Anmeldedaten? Bei WebMCP ist es die bereits angemeldete Sitzung der Besucherin im Browser. Bei einem MCP-Server, einer rohen API oder Browser-Automatisierung muss irgendetwas einen eigenen Schlüssel oder eine eigene Sitzung halten. Alles Weitere in der folgenden Tabelle folgt aus dieser einen Antwort.

	WebMCP	MCP-Server	Browser-Automatisierung
Wo es läuft	Auf der Seite der Besucherin, im Browser	Auf Ihrem Server, unabhängig vom Browser	In einem ferngesteuerten Browser
Wer sich anmeldet	Die bereits angemeldete Sitzung der Besucherin	Ein Token oder OAuth, das jemand ausstellen und pflegen muss	Eine gespeicherte Sitzung oder Zugangsdaten
Vor dem Besuch auffindbar	Nein — die Werkzeuge existieren nur, solange die Seite offen ist	Ja, über ein Discovery-Dokument	Nicht zutreffend
Bricht bei einem Redesign	Nein	Nein	Ständig — jede Layoutänderung trifft die Selektoren
Aufwand pro Aufruf	Gering	Ihre Infrastruktur trägt die Last	Hoch — Screenshots oder das ganze DOM
Baukosten	Ein bis zwei Tage, dann Pflege bei jeder API-Änderung	Ein eigener Dienst, den jemand betreiben muss	Keine für Sie — der Agent bringt sie mit

Das ist keine Entweder-oder-Entscheidung. WebMCP-Werkzeuge existieren nur, solange eine Seite geöffnet ist — ein Agent kann Ihre Fähigkeiten nicht entdecken, ohne vorher auf der Seite gewesen zu sein. Geplante, wiederkehrende und rein headless laufende Aufgaben brauchen weiterhin einen eigenen MCP-Server. Ein sinnvoller Aufbau in Reihenfolge: die vorhandene API dokumentieren, WebMCP-Werkzeuge für die In-Page-Journeys registrieren, ein Discovery-Dokument veröffentlichen, und einen MCP-Server erst dann bauen, wenn tatsächlich jemand headless zugreifen muss. Mehr zum Discovery-Dokument und der Falle mit der robots.txt in unserem Grundlagenartikel zu MCP-Servern und im Vergleich zwischen MCP und dem A2A-Protokoll.

Zwei Wege

Was unterscheidet die imperative von der deklarativen API?

Die imperative API ist der stabile Weg: Sie schreiben JavaScript und registrieren Funktionen selbst. Die deklarative API soll Werkzeuge aus bereits ausgezeichneten <form>-Elementen ableiten. Heute ist nur die imperative API praxisreif — die deklarative API existiert als Idee, deren konkrete Attributnamen die Spezifikation noch als TODO führt.

Die imperative API

Ein Aufruf registriert ein Werkzeug. Über die Qualität entscheidet die Beschreibung: Ein Agent wählt zwischen Ihren Werkzeugen ausschließlich anhand von Name und Beschreibung — nichts sonst. Eine gute Beschreibung beantwortet in dieser Reihenfolge, was zurückkommt, wann dieses Werkzeug einem anderen vorzuziehen ist, und was es nicht tut.

await document.modelContext.registerTool({
  name: "search_products",
  description:
    "Durchsucht den Produktkatalog per Freitext, mit optionalen " +
    "Preis- und Maßfiltern. Liefert bis zu 20 Treffer mit Preis, " +
    "wichtigsten Merkmalen und Verfügbarkeit. Vor get_product_details " +
    "verwenden, solange die Nutzerin kein konkretes Produkt genannt hat.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "Freitext-Suchbegriff" },
      maxPrice: { type: "number", description: "Preisobergrenze in EUR" },
    },
    required: ["query"],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ query, maxPrice }, { signal }) => {
    const params = new URLSearchParams({ q: query });
    if (maxPrice) params.set("max_price", String(maxPrice));

    const res = await fetch(`/api/search?${params}`, {
      credentials: "same-origin",
      signal,
    });
    if (!res.ok) {
      return { content: [{ type: "text", text: `Suche fehlgeschlagen: ${res.status}` }] };
    }
    return { content: [{ type: "text", text: JSON.stringify(await res.json()) }] };
  },
});

registerTool nimmt ein AbortSignal in den Optionen entgegen; wird es abgebrochen, meldet sich das Werkzeug ab. Das ist, wie eine Single-Page-Anwendung ihren Werkzeugbestand ehrlich hält, wenn eine Nutzerin die Ansicht verlässt — ein Agent, der add_to_cart aus einem Checkout aufruft, den es nicht mehr gibt, ist ein echtes Problem. Das zweite Signal, das an execute übergeben wird, bricht dagegen nur den laufenden Aufruf ab. Beide gehören in jeden fetch-Aufruf.

Die deklarative API

Die Idee: ein Formular auszeichnen, und der Browser synthetisiert daraus ein Werkzeug. Feldnamen werden zu Schema-Eigenschaften, Eingabetypen zu JSON-Schema-Typen, Beschriftungen zu Beschreibungen, und die eigene Übermittlung des Formulars wird zum Handler. Fast alles, was diese API künftig von Ihnen verlangt, ist Arbeit, die sich ohnehin lohnt — sauber ausgezeichnete Formulare helfen schon heute jedem Agenten, der WebMCP gar nicht implementiert, ebenso wie Screenreadern und Passwort-Managern.

<form action="/api/angebot" method="post">
  <label for="leistung">Was benötigen Sie?</label>
  <select id="leistung" name="leistung" required>
    <option value="webmcp-implementierung">WebMCP-Implementierung</option>
    <option value="agent-readiness-audit">Agent-Readiness-Audit</option>
    <option value="monitoring">Laufendes Monitoring</option>
  </select>

  <label for="email">Geschäftliche E-Mail-Adresse</label>
  <input id="email" name="email" type="email"
         autocomplete="email" required
         aria-describedby="email-hinweis">
  <p id="email-hinweis">Wir antworten innerhalb eines Werktags.</p>

  <button type="submit">Angebot anfragen</button>
</form>

Markup	Wird zu
name-Attribut	Schlüssel der Eigenschaft
type / inputmode	Typ der Eigenschaft
<label>-Text	Beschreibung der Eigenschaft
<option>-Werte	enum-Einschränkung
required	Eintrag in der required-Liste
action und method	Ziel des Aufrufs

Noch offen: Die konkreten Attributnamen für die deklarative API sind im Explainer-Repository weiterhin als TODO markiert, und die dazugehörige Chrome-Dokumentationsseite lieferte bei der Prüfung dieses Textes einen 404-Fehler. Wir drucken deshalb keine Attributnamen, die wir nicht belegen können — ein falsches Attribut in einer Anleitung schadet mehr als keine Anleitung. Der stabile Weg heute ist die imperative API oben.

Ehrlichkeit als Interface

Was bedeuten readOnlyHint und untrustedContentHint?

readOnlyHint erklärt einem Agenten, dass ein Werkzeug ausschließlich liest, damit er es ohne Rückfrage aufrufen kann. untrustedContentHint erklärt, dass die Rückgabe Inhalt enthält, den nicht Sie verfasst haben — Bewertungen, Kommentare, hochgeladene Dokumente —, damit der Agent sein Vertrauen in diese Antwort entsprechend senkt. Beide sind Deklarationen an den Agenten, keine vom Browser erzwungenen Garantien: Nichts hindert ein als lesend markiertes Werkzeug technisch daran, doch zu schreiben.

Genau deshalb liegt ehrliche Kennzeichnung im eigenen Interesse. Ihre serverseitige Autorisierung ist ohnehin das Einzige, was etwas tatsächlich verhindert — die Annotation entscheidet nur, wie viel ein Agent von sich aus wagt, bevor er einen Menschen fragt. Wer readOnlyHint großzügig auf Werkzeuge setzt, die in Wirklichkeit Zustand verändern, bekommt genau die unbeaufsichtigten Aufrufe, vor denen die Annotation eigentlich schützen sollte. untrustedContentHint ist dabei die günstigste Annotation auf der ganzen Seite und wird regelmäßig übersprungen — setzen Sie sie auf jedes Werkzeug, das nutzergenerierten Inhalt zurückgibt.

Lesend zuerst ist eine Strategie, kein Kompromiss

Der Reflex in einem regulierten Geschäft ist, die ganze Kategorie abzulehnen. Der bessere Zug ist, die lesende Hälfte auszuliefern — sie trägt den größten Teil des Kundennutzens und fast kein Risiko:

const readOnly = { readOnlyHint: true };

register("find_my_policy",   "Listet die Verträge dieses Kontos auf.", readOnly);
register("explain_coverage", "Prüft, ob ein Szenario abgedeckt ist.",  readOnly);
register("get_claim_status", "Liefert Status und nächsten Schritt.",   readOnly);

// Alles, was schreibt, stoppt zuerst für einen Menschen.
register("prefill_claim_draft",
  "Bereitet einen Schadensentwurf zur Prüfung vor. Sendet nicht ab.",
  { readOnlyHint: false });

Sicherheitsmodell

Wie sicher ist WebMCP, und was bleibt offen?

Die bestehende Sitzung der Besucherin zu nutzen, ist ein echter Fortschritt gegenüber einem API-Schlüssel, der in die Konfiguration eines Assistenten kopiert wird: Es entsteht keine neue Anmeldedaten, nichts landet im Kontextfenster eines Modells, und Widerruf bedeutet Abmelden. Das ist aber kein vollständiges Bedrohungsmodell, und die Spezifikation sagt das selbst.

Was die Plattform gibt

Nur sicherer Kontext — ohne HTTPS keine Werkzeuge.
Herkunftsisolation: Werkzeuge sind gleichherkünftigen Dokumenten sichtbar, sofern Sie andere Herkünfte nicht ausdrücklich über exposedTo zulassen.
Berechtigungsrichtlinie tools, standardmäßig auf ['self'] beschränkt; ein fremdherkünftiger iFrame braucht allow="tools", sonst wirft der Aufruf NotAllowedError.
Handler rufen mit credentials: "same-origin" auf — die Sitzung reist mit, das Token nicht.

Was offen bleibt

Die lethale Trias: Ein Agent, der private Daten lesen, nicht vertrauenswürdigen Inhalt verarbeiten und Informationen nach außen senden kann, lässt sich zur Kombination dieser drei Fähigkeiten verleiten. Jede einzelne Fähigkeit ist für sich vertretbar — die Kombination ist das Problem, und keine Seite kann das allein lösen.
Annotationen sind beratend, nicht erzwungen — nichts hindert ein als lesend markiertes Werkzeug daran, zu schreiben.
Ein Bestätigungsmechanismus für folgenreiche Aktionen wird in Sekundärquellen unter dem Namen requestUserInteraction() beschrieben, erscheint aber nicht im WebIDL der von uns geprüften Spezifikation. Prüfen Sie den aktuellen Entwurf, bevor Sie den Namen in ein Konzept oder eine Compliance-Unterlage übernehmen — das Prinzip, folgenreiche Aktionen in der eigenen Oberfläche von einem Menschen bestätigen zu lassen, gilt unabhängig davon, wie der Aufruf am Ende heißt.

Prompt Injection reicht bei WebMCP weiter als anderswo: Ein Agent behandelt alles, was er auf der Seite findet, als Information. Rendert Ihre Seite Inhalt, den andere Personen geschrieben haben — Bewertungen, Kommentare, hochgeladene Dokumente —, kommt eine darin versteckte Anweisung über denselben Kanal an wie Ihre eigenen Werkzeugbeschreibungen. Genau dafür existiert untrustedContentHint.

Prüfliste für die Sicherheitsabnahme

Jedes lesende Werkzeug trägt readOnlyHint: true.
Jedes Werkzeug mit nutzergeneriertem Inhalt trägt untrustedContentHint: true.
Die serverseitige Autorisierung gilt unabhängig von jeder Annotation.
Kein Werkzeug nimmt eine roh durchzählbare ID entgegen — stattdessen auf die Sitzung beschränken.
Folgenreiche Aktionen stoppen für eine ausdrückliche Bestätigung in der eigenen Oberfläche.
Werkzeugbeschreibungen enthalten keine Geheimnisse, internen Hostnamen oder Ticketnummern.
Ratenbegrenzung gilt pro Sitzung und liefert Retry-After, statt einen Agenten hart abzuweisen.
Fremdherkünftige iFrames erhalten allow="tools" bewusst, nicht standardmäßig.

Auslieferung

Wie liefert man WebMCP aus, bevor der Browser mitzieht?

Mit einem Polyfill, der document.modelContext dort bereitstellt, wo der Browser die Schnittstelle noch nicht nativ kennt. Chrome führt WebMCP hinter einem Flag beziehungsweise im Origin Trial, Edge experimentell hinter einem Flag, und Firefox und Safari haben sich zu nichts verpflichtet. Wer auf flächendeckende Unterstützung wartet, schreibt sein erstes Werkzeug in einem Jahr, das noch nicht angekündigt ist.

Das MCP-B-Projekt füllt diese Lücke mit einem Polyfill und passenden Adaptern:

Paket	Wofür
@mcp-b/webmcp-polyfill	Stellt document.modelContext bereit, wo der Browser es nicht nativ kann
@mcp-b/webmcp-types	TypeScript-Typen für die Schnittstelle
usewebmcp	React-Hook, der ein Werkzeug registriert und beim Unmount wieder abmeldet
@mcp-b/global	Ein Import: Polyfill plus ein MCP-Server direkt in der Seite
@mcp-b/webmcp-local-relay	Macht Seiten-Werkzeuge über WebSocket und stdio für Desktop-MCP-Clients erreichbar

import "@mcp-b/webmcp-polyfill";

await document.modelContext.registerTool({
  name: "get_page_summary",
  description: "Liefert Titel, kanonische Adresse und Abschnittszahl dieser Seite.",
  inputSchema: { type: "object", properties: {} },
  annotations: { readOnlyHint: true },
  execute: () => ({
    content: [{
      type: "text",
      text: JSON.stringify({
        title: document.title,
        url: location.href,
        sections: document.querySelectorAll("h2").length,
      }),
    }],
  }),
});

Der Polyfill ist dort, wo der Browser die Schnittstelle bereits nativ implementiert, ein No-op — es gibt also keinen Zweig zu pflegen. Ein Vorbehalt bleibt: Ein Polyfill pinned vor dem 21. Juli 2026 zielt unter Umständen noch auf navigator statt document — Version prüfen, bevor Sie ihn einbinden.

Aus erster Hand

Was haben wir auf dieser Website selbst umgesetzt?

Drei rein lesende WebMCP-Werkzeuge, registriert über document.modelContext, dazu ein Discovery-Dokument unter /.well-known/mcp.json. Kein Demoprojekt — der Code läuft produktiv auf genau der Seite, die Sie gerade lesen.

search_ratgeber

Durchsucht die Ratgeberartikel der Website nach einem Suchbegriff und liefert Titel, Kurzfassung und Adresse der Treffer.

list_leistungen

Gibt das Leistungsangebot samt Branchenseiten zurück, optional gefiltert auf eine Branche — jeweils mit Adresse und Kurzbeschreibung.

check_agent_readiness

Prüft eine beliebige öffentliche Website darauf, ob Agenten sie lesen, verstehen und bedienen können, und liefert Punktzahl, Note und die größten Hebel zurück.

Ehrlich annotiert, wo es zutrifft

Alle drei Werkzeuge tragen readOnlyHint: true — sie schreiben nichts. check_agent_readiness trägt zusätzlich untrustedContentHint: true, weil die Rückgabe (Befunde und Hinweise) von einer fremden Website stammt, nicht von uns. Die Werkzeuge stehen im Code als literale Objekte, nicht als Ergebnis einer Fabrikfunktion oder Schleife — ein Prüfer, der nur das gebaute JavaScript-Bundle durchsucht, ohne es auszuführen, muss Name, Beschreibung, Eingabeschema und Annotationen als Textwerte finden können.

Unterstützt der Browser document.modelContext bereits, nutzen unsere Werkzeuge ihn unverändert. Fehlt er, legt unsere Registrierung eine schlanke Ablage an, damit die Werkzeuge trotzdem deklariert sind — ein Agent, der die Seite liest statt sie auszuführen, findet sie im Bundle, und sobald echte Unterstützung da ist, greift automatisch der native Weg. Eine bestehende native Implementierung überschreiben wir nie.

Prüfverfahren

Was zählt WebMCP im Agent-Readiness-Check?

21 Punkte, die auf jeder Website zählen — und 4 weitere, sobald die Website Formulare hat, die sich als Werkzeuge auszeichnen lassen. Bei einer Website mit Kontakt- oder Suchformular sind es also 25 von 100. Unser kostenloser Agent-Readiness-Check prüft fünf WebMCP-Teilaspekte einer Website und gewichtet sie so:

document.modelContext wird genutzt

6 Punkte

Prüft, ob überhaupt Werkzeuge registriert sind — und ob das über die aktuelle Position der Schnittstelle geschieht oder noch über das abgekündigte navigator.modelContext.

Namen und Beschreibungen der Werkzeuge

5 Punkte

Namen zwischen 1 und 128 Zeichen aus dem erlaubten Zeichensatz, Beschreibungen, die sagen, was zurückkommt und wann das Werkzeug das richtige ist.

Typisierte Eingabeschemata

5 Punkte

Jedes Werkzeug braucht ein inputSchema mit typisierten Eigenschaften, einer Beschreibung je Eigenschaft und einer expliziten required-Liste.

Ehrliche Annotationen

5 Punkte

readOnlyHint auf jedem rein lesenden Werkzeug, untrustedContentHint überall dort, wo die Antwort fremden Text enthält.

Deklarative Werkzeuge an Formularen

4 Punkte, nur wenn die Website Formulare hat

Ausgezeichnete Formulare, die sich zu Werkzeugen synthetisieren lassen, sobald die Attributnamen der Spezifikation feststehen. Hat eine Website keine Formulare, gilt die Prüfung als nicht zutreffend statt als nicht bestanden.

Prüfungen, die auf eine Website nicht zutreffen, fallen aus der Wertung heraus, statt als Fehler zu zählen — das ist ein bewusstes Merkmal des Verfahrens. Hat eine Website keine Formulare, ist Deklarative Werkzeuge an Formularen „nicht zutreffend": Die vier Punkte fehlen weder in der erreichten noch in der möglichen Punktzahl. Eine Website ohne Formulare wird also nicht für etwas abgewertet, das sie gar nicht hat — sie kommt bei den WebMCP-Prüfungen auf bis zu 21 statt auf bis zu 25 Punkte, nicht auf 21 von 25.

Die übrigen Prüfungen betreffen alles, was einem Agenten vorausgeht — serverseitiges Rendern, Crawlbarkeit, Formular-Semantik, Discovery-Dokumente, Authentifizierung und Zahlungswege für Agenten. WebMCP ist der letzte Schritt, nicht der erste: Ein Agent muss Ihre Seite erst erreichen, verstehen und bedienen können, bevor eine Werkzeugliste überhaupt etwas bedeutet. Mehr zu den übrigen Ebenen — Sichtbarkeit, Schnittstellen, Bezahlung — auf unserer Seite zur Agent-Readiness.

Welche Punkte holt Ihre Website beim WebMCP-Teil heraus?

Der Check ist kostenlos und dauert wenige Minuten. Er zeigt, ob document.modelContext genutzt wird, wie vollständig Ihre Werkzeuge annotiert sind — und was der größte Hebel ist, um die restlichen Punkte zu holen.

Website kostenlos prüfen

Verwandte Leistungen und Grundlagen

Tiefer einsteigen

WebMCP ist ein Baustein von Agent-Readiness. Diese Seiten führen die übrigen Bausteine und die Grundlagen aus.

Häufige Fragen

Antworten zu WebMCP

Was ist WebMCP in einem Satz?

WebMCP ist eine vorgeschlagene Browser-Schnittstelle, über die eine Website ihre Fähigkeiten als benannte, typisierte Werkzeuge mit Beschreibung und JSON-Schema bereitstellt, sodass ein KI-Agent sie direkt aufrufen kann, statt Ihr Markup zu interpretieren oder Screenshots davon auszuwerten.

Funktioniert Code mit navigator.modelContext noch?

Ja, aber nur solange, wie der Origin Trial die alte Position noch bedient. Chrome 150 hat navigator.modelContext abgekündigt, doch die Schnittstelle bleibt dort während der Übergangszeit nutzbar. Das ist der gefährliche Teil: Ihr Code läuft auf Ihrem eigenen Rechner mit gesetztem Flag scheinbar weiter, während er für echte Besucherinnen und Besucher an einem Punkt, den Sie nicht kontrollieren, verschwindet. Migrieren Sie auf document.modelContext, und lassen Sie eine Konsolen-Warnung auf dem alten Pfad stehen, damit Sie sehen, welche Auslieferung noch betroffen ist.

Ersetzt WebMCP einen MCP-Server?

Nein. WebMCP-Werkzeuge existieren nur, solange eine Seite geöffnet ist — ein Agent kann Ihre Fähigkeiten nicht entdecken, ohne vorher auf der Seite gewesen zu sein. Geplante, wiederkehrende oder serverseitige Aufrufe brauchen weiterhin einen MCP-Server mit eigener Authentifizierung. WebMCP übernimmt die In-Page-Journeys — Suchen, Vergleichen, Konfigurieren, Buchen —, ein MCP-Server bleibt zuständig für alles, bei dem niemand angemeldet vor dem Bildschirm sitzt.

Ist WebMCP schon ein offizieller Web-Standard?

Nein. Die Spezifikation ist ein Draft Community Group Report der W3C Web Machine Learning Community Group und steht nicht auf dem W3C-Standardisierungspfad. Chrome führt sie experimentell hinter einem Flag beziehungsweise im Origin Trial, Edge testet ebenfalls hinter einem Flag. Firefox und Safari beteiligen sich an der Diskussion, ohne sich festzulegen. Eine Verschiebung wie die vom 21. Juli 2026 ist bei diesem Status keine Ausnahme, sondern das, was ein Entwurfsstadium bedeutet.

Warum sollte man trotzdem jetzt schon Werkzeuge registrieren?

Weil die Nachfrageseite angekommen ist. Bis Ende August 2026 war der Einwand gegen WebMCP kaum zu entkräften: Browser lieferten die Schnittstelle aus, kein verbreiteter Agent rief sie auf, also hatte niemand einen Grund, Werkzeuge zu registrieren. Seit ChatGPT Desktop WebMCP seit dem 25. August 2026 konsumiert, gibt es einen Konsumenten mit echter Nutzerbasis. Das macht den Standard nicht sicher vor weiteren Änderungen, verschiebt aber die Frage von „ruft das je jemand auf" zu „wie viel vom frühen Verkehr wollen Sie abbekommen".

Was bedeutet readOnlyHint konkret, und wird es erzwungen?

readOnlyHint markiert ein Werkzeug als rein lesend, damit ein Agent es ohne Rückfrage aufrufen kann. Die Annotation ist eine Erklärung an den Agenten, keine technische Schranke: Der Browser verhindert nicht, dass ein als lesend markiertes Werkzeug tatsächlich schreibt. Die eigentliche Kontrolle bleibt Ihre serverseitige Autorisierung — die Annotation entscheidet nur, wie viel Vertrauen ein Agent dem Aufruf entgegenbringt, bevor er zurückfragt.

Braucht jede Website ein WebMCP-Werkzeug?

Nein, aber die meisten profitieren von zwei bis drei rein lesenden. Der praktische Deckel liegt deutlich unter fünfzig Werkzeugen pro Seite — darüber verschlechtert sich die Auswahl, weil der Agent mehr plausible Optionen hat, als er sicher unterscheiden kann. Die meisten Websites brauchen drei bis acht: finden, ansehen, vergleichen, handeln.

Was ist die deklarative API, und kann man sie schon nutzen?

Die deklarative API soll Werkzeuge direkt aus ausgezeichneten Formularen ableiten, ohne eigenen JavaScript-Code. Die konkreten Attributnamen dafür sind in der Spezifikation aber noch als TODO markiert, und die zugehörige Chrome-Dokumentation lieferte bei Prüfung dieses Textes einen 404-Fehler. Nutzbar und wertvoll ist schon heute die Formular-Semantik selbst — Beschriftungen, Namen, Typen, Autocomplete —, die später ohne Umbau in die deklarative API übernommen werden kann.

Was ist der Unterschied zwischen dem Abbruchsignal bei registerTool und bei execute?

Es sind zwei verschiedene Signale mit unterschiedlicher Wirkung. Das AbortSignal in den Optionen von registerTool meldet die Registrierung ab — genau das hält den Werkzeugbestand einer Single-Page-Anwendung ehrlich, wenn eine Nutzerin die Ansicht verlässt. Das Signal, das an execute übergeben wird, bricht dagegen nur den laufenden Aufruf ab. Beide sollten in jeden fetch-Aufruf durchgereicht werden, damit ein abgebrochener Agenten-Zug keine offenen Anfragen hinterlässt.