WebMCP

TL;DR — WebMCP ermöglicht es einer Website, ihre Schaltflächen und Funktionen als strukturierte Tools zu beschreiben, die ein KI-Agent aufrufen kann, während die Seite geöffnet ist. Das kann eine echte Seitenaktion—Inventar durchsuchen, Code validieren, Produkte filtern—zuverlässiger machen, als einen Agenten raten zu lassen, welches Steuerelement er anklicken soll. Es macht die Seite nicht einfacher zu ranken, zu crawlen oder zu entdecken. Stand 17. Juli 2026 ist es experimentell: ein Community-Group-Entwurf mit einem Chrome-149-Origin-Trial, kein fertiger Webstandard.

Was WebMCP ist

WebMCP ist eine vorgeschlagene Browser-API, die es einer Webseite ermöglicht, strukturierte Tools für einen KI-Agenten bereitzustellen, der im Browserkontext dieser Seite arbeitet. Ein Tool hat einen Namen, eine Beschreibung, strukturierte Eingaben und Code, der eine Aktion ausführt. Evidence for this claim WebMCP is a proposed browser API through which web applications expose JavaScript-based tools to agents in a browsing context. Scope: WebMCP Draft Community Group Report dated July 10, 2026; the report is not a W3C Standard. Confidence: high · Verified: 2026-07-17 WebMCP Draft Community Group Report

Stellen Sie sich vor, ein Besucher öffnet einen Schema-Validator und bittet seinen Browser-Agenten, “dieses Product-JSON-LD zu validieren.” Ohne WebMCP könnte der Agent den Bildschirm inspizieren, einen Textbereich finden, hinein einfügen, den richtigen Button klicken und das Ergebnis interpretieren. Mit WebMCP könnte die Seite ein validate_schema-Tool mit einem expliziten Eingabeschema anbieten und ein strukturiertes Ergebnis zurückgeben—während die sichtbare Oberfläche synchron bleibt.

Das ist das nützliche mentale Modell: WebMCP ist eine explizite Steueroberfläche für einen Agenten, der die Seite bereits erreicht hat. Es ist keine neue Möglichkeit, Prosa zu veröffentlichen.

Aktueller Stand am 17. Juli 2026

WebMCP entwickelt sich schnell, daher benötigen Code- und Kompatibilitätsaussagen Daten. Die aktuelle Position ist: Evidence for this claim As of July 17, 2026, WebMCP is a Community Group draft rather than a W3C Standard, and Chrome documents an origin trial beginning in Chrome 149. Scope: Standards and Chrome experiment status checked July 17, 2026; these are time-sensitive claims. Confidence: high · Verified: 2026-07-17 WebMCP: Status of This Document Chrome: Join the WebMCP origin trial

Ich habe in diesem Recherche-Durchgang keine Primärquellen-Basis gefunden, um stabile WebMCP-Unterstützung in Edge, Safari oder Firefox zu behaupten. Ein Microsoft-Redakteur, der zum Entwurf beiträgt, ist nicht dasselbe wie ein Browser, der die Funktion ausliefert.

WebMCP versus MCP

Model Context Protocol und WebMCP legen Tools an unterschiedlichen Grenzen offen:

• MCP verbindet normalerweise eine KI-Anwendung mit einem persistenten Server. Der Server kann Tools und Daten bereitstellen, unabhängig davon, ob eine bestimmte Webseite geöffnet ist.
• WebMCP ermöglicht es der geöffneten Seite, ihre aktuellen Frontend-Aktionen und ihren Zustand offenzulegen. Seine Tools können sich ändern, wenn der Besucher navigiert oder wenn eine Aktion nicht mehr verfügbar ist.

Sie ergänzen sich. Ein Geschäft könnte entferntes MCP für einen Produktkatalog und WebMCP für die Filter-, Konfigurations- und Checkout-Schritte verwenden, die im aktuellen Tab des Besuchers sichtbar sind. Evidence for this claim WebMCP is designed for tools owned by an active page and its browser context, while remote MCP commonly connects an AI application to a persistent backend server. Scope: Architecture-selection guidance, not a rule that prevents an application from using both technologies. Confidence: high · Verified: 2026-07-17 Chrome: When to use WebMCP and MCP

Hilft WebMCP bei SEO oder KI-Zitaten?

Es gibt keine dokumentierten Belege, dass das Hinzufügen von WebMCP Rankings, Crawling, Indexierung, KI-Zitate oder Auffindbarkeit verbessert. Die dokumentierte Funktion beginnt, nachdem ein Agent eine Seite erreicht und die dort verfügbaren Tools inspiziert hat. Evidence for this claim The documented Chrome WebMCP experiment requires a browsing context and a client visit to discover page tools; no documented ranking, crawling, indexing, or citation benefit was found in this research pass. Scope: The browser-context and visit requirements are direct documentation; the SEO conclusion is a bounded absence-of-evidence statement as of July 17, 2026, not a prediction about future search systems. Confidence: high · Verified: 2026-07-17 Chrome: WebMCP overview and limitations Google Search guidance for AI experiences

Es könnte die Erledigung einer On-Site-Aufgabe verbessern. Das kann kommerziell wertvoll sein, aber es ist eine Produkt- und Konversionshypothese—kein Ranking-Faktor. Machen Sie weiter die gewöhnliche Arbeit, die eine Seite auffindbar und verständlich macht: semantisches HTML, zugängliche Formulare, interne Links, indexierbare Inhalte und geeignete strukturierte Daten.

Redaktionsseiten benötigen keine Fake-Tools, nur um „agent-ready“ zu wirken. Wenn die Seite nur gelesen werden muss, ist lesbares HTML die richtige Schnittstelle.

Kann Cloudflare WebMCP für meine Website aktivieren?

Nicht von allein. Cloudflare Browser Run bietet derzeit experimentelle Lab-Browser-Sitzungen an, die Seiten mit WebMCP-Tools besuchen und testen können. Ihre Seite muss diese Tools weiterhin selbst definieren und registrieren. Die Cloudflare-Dokumentation sagt außerdem, dass die Lab-Sitzungen nicht für Produktionslasten gedacht sind. Evidence for this claim Cloudflare Browser Run offers experimental lab sessions that can consume and test page-provided WebMCP tools, but the page still owns tool registration and Cloudflare says lab sessions are not for production workloads. Scope: Cloudflare product documentation last updated April 23, 2026; its example API names lag current Chrome documentation and should not be used as the API authority. Confidence: high · Verified: 2026-07-17 Cloudflare Browser Run: WebMCP

Das macht Cloudflare zu einer möglichen Testumgebung oder einem konsumierenden Browser, nicht zu einem Schalter, der jedes vorhandene Formular und jeden Button in WebMCP verwandelt.

Sollten Sie es jetzt implementieren?

Für die meisten Produktionsseiten: warten. Ein kleines privates Experiment kann sinnvoll sein, wenn all dies zutrifft:

• die Seite hat bereits eine begrenzte, nützliche Aktion;
• die normale menschliche Schnittstelle bleibt ohne WebMCP vollständig;
• die Aktion ist schreibgeschützt oder leicht umkehrbar;
• dieselbe Anwendungslogik bedient sowohl die UI als auch das Tool;
• Eingaben, Ausgaben, Autorisierung und Protokolle erhalten eine echte Sicherheitsüberprüfung; und
• der Erfolg kann gemessen werden, ohne vorzutäuschen, dass das Experiment die Sichtbarkeit in der Suche beeinflusst.

Verwenden Sie eine experimentelle Browser-API nicht als einzigen Weg zu einer kritischen Aufgabe.

TL;DR — WebMCP stellt Seiten-eigene Tools aus document.modelContext einem Agenten im aktiven Browsing-Kontext bereit. Die imperative API registriert einen Namen, eine Beschreibung, JSON-Schema-Eingaben, Annotationen und einen asynchronen Callback; Tools können zustandsabhängig sein und mit einem AbortSignal deregistriert werden. Chrome dokumentiert auch eine deklarative Formularebene, aber der Community-Group-Entwurf vom 10. Juli 2026 kennzeichnet seinen deklarativen Abschnitt weiterhin als TODO. Die Funktion befindet sich in einem Chrome-149-Origin-Trial, nicht in einer stabilen, browserübergreifenden Basislinie. Behandeln Sie sie als progressive Verbesserung, nicht als SEO-Infrastruktur, und sichern Sie sie als authentifizierte Anwendungsoberfläche.

Wie WebMCP im Browser funktioniert

Ein sinnvoller WebMCP-Lebenszyklus beginnt und endet mit der Seite. Die Seite registriert nur die Aktionen, die in ihrem aktuellen Zustand gültig sind; ein Agent, der bereits in diesem Browsing-Kontext arbeitet, entdeckt und ruft eine davon auf; die Seite führt ihre normale Anwendungslogik aus, aktualisiert die für Menschen sichtbare Oberfläche und gibt ein begrenztes Ergebnis zurück. Wenn sich der Zustand ändert, entfernt die Seite Tools, die nicht mehr zutreffen. Evidence for this claim The imperative API registers named, described, schema-constrained callbacks and supports state-aware cleanup with AbortSignal plus tool-set change notifications. Scope: Current draft and Chrome experiment; API details may change before stable release. Confidence: high · Verified: 2026-07-17 WebMCP ModelContext API Chrome: WebMCP Imperative API

Dieser zustandsbehaftete Lebenszyklus ist ein Grund, warum WebMCP kein statischer Abfall aller Funktionen in einem JavaScript-Bundle werden sollte. Ein Tool, das in der sichtbaren UI unmöglich ist, sollte normalerweise auch für den Agenten nicht verfügbar sein.

WebMCP vs. MCP: zwei unterschiedliche Laufzeitgrenzen

Die Namen laden zur Verwechslung ein, aber die operative Grenze ist unterschiedlich. WebMCP lebt in der Ereignisschleife eines Dokuments und in der aktuellen Browser-Sitzung. Remote-MCP lebt an der Integrationsgrenze der KI-Anwendung und erreicht üblicherweise einen persistenten Backend-Server. Evidence for this claim WebMCP is designed for tools owned by an active page and its browser context, while remote MCP commonly connects an AI application to a persistent backend server. Scope: Architecture-selection guidance, not a rule that prevents an application from using both technologies. Confidence: high · Verified: 2026-07-17 Chrome: When to use WebMCP and MCP

Wählen Sie nicht anhand des Akronyms, sondern anhand des Eigentümers der Aktion. Wenn die Aktion den aktuellen DOM, die Auswahl, den Warenkorb oder den UI-Zustand benötigt, könnte WebMCP passen. Wenn sie im Hintergrund, über viele Websites hinweg oder ohne geöffneten Tab ausgeführt werden muss, verwenden Sie eine API oder ein entferntes MCP.

Die imperative API

Die imperative API registriert ein Tool über document.modelContext.registerTool(). Das Tool enthält einen eindeutigen Namen, eine Beschreibung, ein JSON-Schema-Input, einen execute-Callback und optionale Annotationen. Chrome dokumentiert außerdem getTools(), executeTool() zum Testen und ein toolchange-Ereignis. Evidence for this claim Current Chrome documentation uses document.modelContext and says navigator.modelContext is deprecated beginning in Chrome 150. Scope: Chrome implementation guidance checked July 17, 2026; version and API-name claims expire quickly. Confidence: high · Verified: 2026-07-17 Chrome: WebMCP Imperative API

Dieser illustrative Kandidat zeigt die beabsichtigte Form für einen zukünftigen Schema-Validator-Pilot. Er läuft nicht auf dieser Website, und die API kann sich vor einer stabilen Version ändern:

if (document.modelContext) {
  const registration = new AbortController();

  await document.modelContext.registerTool({
    name: 'validate_schema',
    description: 'Validate pasted JSON-LD and return bounded issues.',
    inputSchema: {
      type: 'object',
      properties: {
        markup: {
          type: 'string',
          description: 'JSON-LD markup to validate.',
          maxLength: 50000
        }
      },
      required: ['markup'],
      additionalProperties: false
    },
    annotations: {
      readOnlyHint: true,
      untrustedContentHint: true
    },
    execute: async ({ markup }) => {
      const result = await validateWithTheSameEngineAsTheUI(markup);
      renderResultInTheVisibleUI(result);
      return minimizeValidationResult(result);
    }
  }, { signal: registration.signal });

  // When this page state no longer supports validation:
  // registration.abort();
}

Die wichtige Architektur ist nicht der Wrapper. Es ist, dass der Callback denselben Validator wie die sichtbare UI aufruft, serverseitige Limits und Autorisierung weiterhin gelten und die Antwort bewusst minimiert wird. Die Feature-Erkennung bewahrt den vollständigen menschlichen Workflow in nicht unterstützten Browsern.

Verwenden Sie document.modelContext, nicht veraltete Beispiele, die um navigator.modelContext herum aufgebaut sind; Chrome markiert letzteres ab Chrome 150 als veraltet. Datieren Sie diesen Hinweis, da die Funktion experimentell bleibt.

Die deklarative API hat eine Normen-Diskrepanz

Chrome dokumentiert einen deklarativen Ansatz, der gewöhnliche Formulare mit Attributen wie toolname, tooldescription und toolparamdescription annotiert. Es dokumentiert auch optionales toolautosubmit; andernfalls klickt der Benutzer auf Senden. SubmitEvent.agentInvoked identifiziert eine agentenausgelöste Übermittlung. Evidence for this claim Chrome documents declarative WebMCP form annotations, but the July 10, 2026 Community Group draft says its Declarative WebMCP section is entirely TODO. Scope: A direct comparison between Chrome implementation documentation and the current draft; it does not imply Chrome's experimental implementation is unavailable. Confidence: high · Verified: 2026-07-17 Chrome: WebMCP Declarative API WebMCP: Declarative WebMCP

Der Community-Group-Bericht vom 10. Juli sagt jedoch, dass sein Abschnitt zu Declarative WebMCP “entirely a TODO” ist und den Formular-zu-JSON-Schema-Algorithmus undefiniert lässt. Das bedeutet nicht, dass das Experiment von Chrome imaginär ist. Es bedeutet, dass die Implementierungsdokumentation dem normativen Entwurf voraus ist. Behandeln Sie deklaratives Markup als experimentelle Chrome-Oberfläche, nicht als etabliertes Cross-Browser-HTML.

Für jetzt bleiben gewöhnliche semantische Formulare die dauerhafte Basis. Eine experimentelle Annotationsschicht sollte sie verbessern, niemals Labels, Validierung, Barrierefreiheit, Bestätigung oder serverseitige Autorisierung ersetzen.

Tool-Erkennung, Lebenszyklus und Cross-Origin-Grenzen

Die aktuelle API hat mehrere Grenzen, die es wert sind, explizit entworfen zu werden:

• Browsing-Kontext: Das Experiment von Chrome erfordert einen Browser-Kontext. Der Client besucht die Website, bevor er die Tools der Website entdeckt.
• Dynamische Verfügbarkeit: Registrieren Sie Tools, wenn sie gültig sind, und brechen Sie ihre Registrierung ab, wenn Zustand oder Navigation sie ungültig machen. Beobachter können auf toolchange hören.
• Gleichherkunft standardmäßig: Die tools-Permissions-Policy standardmäßig auf 'self'. Cross-Origin-Iframes benötigen explizite Delegation wie allow="tools".
• Zweiseitige Cross-Origin-Zustimmung: Ein Tool kann exposedTo verwenden, um erlaubte sichere Ursprünge aufzulisten, während ein Aufrufer Tools von benannten Ursprüngen mit fromOrigins anfordert. Eine Seite, die zustimmt, reicht nicht aus.
• Progressive Verbesserung: Nicht unterstütztes oder deaktiviertes WebMCP muss die gewöhnliche Seite vollständig nutzbar lassen.

Dies sind nützliche Plattformkontrollen, aber sie machen eine riskante Anwendungsaktion nicht zu einer sicheren.

Sicherheit: Die Browser-Sitzung erhöht die Einsätze

Ein Browser-Agent kann innerhalb der authentifizierten Sitzung des Benutzers arbeiten. Das kann das Feature sein – Zugriff auf den aktuellen Warenkorb, das Konto oder den Arbeitsbereich – und die Gefahr. Chrome und der Entwurf diskutieren Prompt-Injection, irreführende Tool-Metadaten, kontaminierte Tool-Ausgaben, übermäßig breite Parameter, Datenschutzlecks, Cross-Origin-Exposition und Missbrauch der angemeldeten Autorität. Evidence for this claim WebMCP tool hints can communicate read-only and untrusted-output intent, but they do not eliminate prompt injection, misleading metadata, privacy leakage, cross-origin risk, or misuse of authenticated browser authority. Scope: Threat-model and defensive guidance; application authorization and confirmation remain implementation responsibilities. Confidence: high · Verified: 2026-07-17 WebMCP security and privacy considerations Chrome: WebMCP tool security Chrome: Agent security considerations

Behandeln Sie jedes Tool als öffentlichen Anwendungsendpunkt mit einem ungewöhnlichen Aufrufer:

1. Halten Sie das Tool eng umrissen. Eine Aufgabe, explizite Eingaben, enge Aufzählungen und Längen, kein versteckter “Alleskönner”-Parameter.
2. Erzwingen Sie die Autorisierung in der Anwendungslogik. Der Agent erhält nicht mehr Befugnisse als der angemeldete Benutzer, und ein Hinweis ist keine Berechtigung.
3. Trennen Sie Lese- von Schreibvorgängen. readOnlyHint und untrustedContentHint kommunizieren Risiken; sie erzwingen sie nicht.
4. Verlangen Sie eine sichtbare Bestätigung für Konsequenzen. Käufe, Übermittlungen, Löschungen, Nachrichten und Kontenänderungen benötigen einen für Menschen verständlichen Kontrollpunkt.
5. Minimieren Sie die Ausgabe. Geben Sie nur das zurück, was die Aufgabe benötigt; geben Sie niemals Sitzungsdaten, rohe Header, Geheimnisse oder nicht zusammenhängende Datensätze preis.
6. Behandeln Sie die Ausgabe als nicht vertrauenswürdig. Eine Zeichenfolge, die von einem Tool zurückgegeben wird, kann zur Eingabe für spätere Modellüberlegungen werden. Lassen Sie nicht zu, dass sie Anweisungen oder Befugnisse einschmuggelt.
7. Protokollieren Sie die Grenze. Erfassen Sie das Tool, die Eingabeklasse, die Autorisierungsentscheidung, die Bestätigung, die Ergebnisklasse, den Fehler, die Herkunft und den Lebenszyklus, ohne Geheimnisse zu protokollieren.

Die sichere Frage ist nicht “Kann ein Agent dies aufrufen?” Es ist “Würde ich dies als überprüften Endpunkt einem Aufrufer aussetzen, der Anweisungen missverstehen und nicht vertrauenswürdigen Text weiterleiten kann?”

Testen Sie Verträge und Agentenverhalten getrennt

Chromes eval-Richtlinien trennen deterministische Produkttests von probabilistischen Agententests. Evidence for this claim WebMCP testing should combine deterministic contract and UI-state tests with probabilistic evaluation of agent tool selection and use. Scope: Chrome's evaluation guidance; teams must define product-specific tasks, models, risks, and thresholds. Confidence: high · Verified: 2026-07-17 Chrome: Evals for WebMCP Beides ist wichtig:

Deterministische Tests sollten Registrierung, Schema-Ablehnung, gültige und ungültige Eingaben, Autorisierung, Ratenbegrenzungen, Nebenwirkungen, Fehlerform, Ausgabeminimierung, UI-Parität, Abmeldeverhalten und Fallback für nicht unterstützte Browser verifizieren.

Probabilistische Evals sollten messen, ob repräsentative Agenten das richtige Tool entdecken, irrelevante Tools vermeiden, die korrekten Parameter wählen, bei Bedarf um Klärung bitten, Bestätigungen respektieren, nach Erfolg aufhören und sich gegen feindselige Beschreibungen oder Ausgaben wehren.

Verwenden Sie nicht einen einzigen Demo-Prompt als Freigabegate. Ein erfolgreicher Callback beweist, dass der Code ausgeführt wurde; er beweist nicht, dass Modelle ihn zuverlässig auswählen oder dass die Aktion sicher ist.

Cloudflare Browser Run: nützliches Labor, keine Aktivierung

Cloudflare dokumentiert WebMCP-Unterstützung im experimentellen Laborpool von Browser Run und sagt, dass Laborsitzungen nicht für Produktionsworkloads verwendet werden sollten. Die Seite vom 23. April enthält auch ältere Testnamen aus der Chrome-Ära, verwenden Sie diese Seite also als Beleg für das aktuelle Produktangebot von Cloudflare – nicht als Autorität für die neueste WebMCP-API-Form. Evidence for this claim Cloudflare Browser Run offers experimental lab sessions that can consume and test page-provided WebMCP tools, but the page still owns tool registration and Cloudflare says lab sessions are not for production workloads. Scope: Cloudflare product documentation last updated April 23, 2026; its example API names lag current Chrome documentation and should not be used as the API authority. Confidence: high · Verified: 2026-07-17 Cloudflare Browser Run: WebMCP

Cloudflare kann eine Browsersitzung und einen Agentenpfad bereitstellen, der Tools konsumiert. Es kann den sicheren Vertrag für Ihre Anwendung nicht ableiten oder seitenbezogene Tools registrieren, die Sie nicht erstellt haben.

Vorgeschlagener patrickstox.com-Pilot: Schema-Validator

Der Schema-Markup-Validator ist ein guter zukünftiger Pilotkandidat, keine Live-WebMCP-Implementierung. Er hat bereits eine begrenzte eingefügte Eingabe, deterministische Logik, strukturierte Probleme und ein sichtbares Ergebnis. Ein zukünftiges validate_schema-Tool könnte dieselbe Validierungs-Engine wie die UI und die vorhandene Remote-MCP-Tool-Suite wiederverwenden.

Der Pilot sollte warten, bis die Browser-API eine stabile, nicht experimentelle Version erreicht und eine frische Sicherheitsüberprüfung besteht. Die erste Version sollte schreibgeschützt, funktionserkannt, eingabebegrenzt, antwortminimiert und auf Vorschau-, Admin- oder nur-Eigentümer-Oberflächen nicht verfügbar sein. Diese Website beansprucht derzeit keine WebMCP-Unterstützung.

Entscheidung: bauen, experimentieren, warten oder überspringen

KI-Zusammenfassung

• Definition: WebMCP ist eine vorgeschlagene Browser-API zur Bereitstellung strukturierter, seitenbezogener Tools für einen Agenten in einem aktiven Browsing-Kontext.
• Status am 17. Juli 2026: Community-Group-Entwurf, kein W3C-Standard; Chrome-149-Origin-Trial/lokales Flag, keine stabile Cross-Browser-Unterstützung.
• Aktuelle Chrome-API: document.modelContext; Chrome stellt navigator.modelContext ab Chrome 150 ein.
• Nicht Remote-MCP: WebMCP ist an Tab- und Seitenstatus gebunden; Remote-MCP verbindet üblicherweise eine KI-Anwendung mit einem persistenten Backend-Server.
• Keine Entdeckung oder kein Ranking: kein dokumentierter Nutzen für Crawling, Indexierung, Rankings, KI-Zitate oder das Erreichen der Seite überhaupt.
• Deklarativer Vorbehalt: Chrome dokumentiert Formularannotationen, während der Community-Group-Entwurf vom 10. Juli diesen normativen Abschnitt weiterhin als TODO markiert.
• Sicherheit: authentifizierter Browserstatus, Prompt-Injection, manipulierte Metadaten oder Ausgaben, breite Eingaben und Cross-Origin-Exposition machen Least Privilege, Bestätigung, Serverautorisierung und Protokolle unerlässlich.
• Cloudflare: Browser Run kann WebMCP in experimentellen Lab-Sitzungen konsumieren/testen; es erstellt keine Tools auf der Website.
• Empfehlung: die menschliche UI vollständig beibehalten und auf stabile Unterstützung warten; private Experimente sollten begrenzt, reversibel und messbar sein.
• Kandidat dieser Website: ein zukünftiger, schreibgeschützter Schema-Validator-Pilot. Er ist vorgeschlagen, nicht implementiert.

Was die Primärquellen festlegen

Status und Kompatibilität wurden am 17. Juli 2026 überprüft. Überprüfen Sie diese Quellen erneut, bevor Sie Code kopieren oder eine Produktionsentscheidung treffen.

WebMCP-Implementierungs-Checkliste

Produktpassung

• Die Seite hat eine begrenzte Aktion, die als Tool wesentlich zuverlässiger ist.
• Das Tool löst eine Benutzeraufgabe; es wird nicht für spekulative Rankings hinzugefügt.
• Eine normale semantische, zugängliche Oberfläche bleibt die Quelle der Wahrheit.
• Die Aktion gehört zur aktuellen Seite/Sitzung und nicht zu einer Hintergrund-API.

Vertrag und Lebenszyklus

• Name und Beschreibung sind kurz, eindeutig, spezifisch und nicht aus nicht vertrauenswürdigem Inhalt generiert.
• Das JSON-Schema lehnt unbekannte Felder ab und begrenzt Zeichenfolgen, Arrays, Bereiche und Aufzählungen.
• Der Callback verwendet dieselbe Engine und denselben Autorisierungspfad wie die sichtbare Benutzeroberfläche.
• Die Benutzeroberfläche spiegelt den resultierenden Zustand sichtbar wider.
• Das Tool wird abgemeldet, wenn Navigation oder Zustand es ungültig machen.
• Nicht unterstützte Browser behalten den vollständigen Workflow.

Sicherheit und Datenschutz

• Lese-/Schreibverhalten ist explizit; Anmerkungen werden nur als Hinweise behandelt.
• Die Serverautorisierung wird unabhängig vom Agenten durchgesetzt.
• Sensible Aktionen erfordern eine sichtbare, informierte Bestätigung.
• Cross-Origin-Exposition wird verweigert, es sei denn, ein benannter Anwendungsfall erfordert sie.
• Die Tool-Ausgabe wird minimiert und als nicht vertrauenswürdige Downstream-Eingabe behandelt.
• Geheimnisse, Cookies, lokaler Verlauf, rohe private Datensätze und nicht zusammenhängender Zustand sind ausgeschlossen.
• Protokolle unterstützen die Überprüfung von Vorfällen, ohne sensible Nutzlasten zu speichern.

Veröffentlichung und Bewertung

• Registrierung, Validierung, Fehler, Nebenwirkungen, Ausgabe, UI-Parität und Bereinigung haben deterministische Tests.
• Repräsentative Agenten haben probabilistische Auswahl- und Parametrisierungs-Evaluierungen.
• Adversariale Prompts, Metadaten, Ausgabe und Confused-Deputy-Fälle werden getestet.
• Die aktuelle Spezifikation, der Chrome-Meilenstein, Flags/Trial und die Anbieterdokumentation wurden erneut überprüft.
• Die Funktion ist keine Produktionsabhängigkeit, solange die Unterstützung experimentell bleibt.

WebMCP-Entscheidungs-Spickzettel

Aktuelle Syntax und Status

Current object:       document.modelContext
Deprecated in C150:  navigator.modelContext
Chrome status:        149 origin trial / testing flag
Standards status:     Community Group draft, not W3C Standard
Discovery moment:     after the client visits the page
Cloudflare role:      experimental consuming/test browser

Das ACTION-Gate

Verwenden Sie ACTION, bevor Sie eine Seitenfunktion freigeben:

• A — Aktion ist begrenzt. Ein Zweck, explizite Eingabe, vorhersehbare Ausgabe.
• C — Kontext gehört zur Seite. Der aktuelle Tab oder sichtbare Zustand ist wirklich erforderlich; andernfalls bevorzugen Sie eine API oder Remote-MCP.
• T — Vertrauensgrenze ist überprüft. Authentifizierung, Ursprünge, nicht vertrauenswürdiger Inhalt, Bestätigung und Ausgabeminimierung haben Verantwortliche.
• I — Schnittstelle bleibt vollständig. Die gewöhnliche Benutzeroberfläche ist zugänglich und voll funktionsfähig ohne experimentelle Browserunterstützung.
• O — Eine Implementierung. UI, API/MCP und WebMCP rufen dieselbe kanonische Engine auf, anstatt in separate Geschäftslogik abzudriften.
• N — Zahlen können gemessen werden. Definieren Sie Aufgabenabschluss-, Fehler-, Klärungs-, Abbruch-, unsichere Versuchs- und Fallback-Raten vor dem Start.

Wenn ein Buchstabe fehlschlägt, ist das Tool nicht produktionsreif.

WebMCP-Anti-Patterns

1. Ein Tool zu jedem Artikel hinzufügen. Lesbarer Inhalt wird nicht auffindbarer, nur weil eine Seite eine bedeutungslose read_article-Aktion registriert.
2. Annotationen als Durchsetzung behandeln. readOnlyHint kommuniziert Absicht; es verhindert keine versteckten Schreibvorgänge und garantiert kein sicheres Modellverhalten.
3. navigator.modelContext-Beispiele ohne Datum kopieren. Chrome dokumentiert den Wechsel zu document.modelContext und die Veraltung ab Chrome 150.
4. Dem Agenten einen generischen Befehlsausführer geben. Breite Eingaben löschen den Vorteil eines strukturierten Vertrags aus und vergrößern die Auswirkungen von Prompt-Injection.
5. Veraltete Tools registriert lassen. Wenn die Seite eine Aktion deaktiviert, sollte ihr Tool nicht aufrufbar bleiben.
6. Das gesamte Anwendungsobjekt zurückgeben. Minimieren Sie die Ausgabe; private oder nicht vertrauenswürdige Felder können Daten leaken oder spätere Überlegungen vergiften.
7. Cloudflare-Status als Ersatz für Seitenarbeit zulassen. Ein Beta-Browser, der WebMCP konsumiert, erstellt, registriert, sichert oder testet Ihre Tools nicht.
8. Das Formular durch das Experiment ersetzen. Progressive Enhancement bedeutet, dass die menschliche Schnittstelle fehlende Browserunterstützung und API-Änderungen überlebt.
9. Eine private Demo als produktionsreif bezeichnen. Vertragserfolg ist nicht Agentenzuverlässigkeit, Interoperabilität oder ein abgeschlossenes Bedrohungsmodell.

Verwandte Tools auf dieser Seite

• Schema-Markup-Validator: der vorgeschlagene erste WebMCP-Pilot, weil seine Eingaben und Ergebnisse begrenzt und deterministisch sind. WebMCP ist darauf heute nicht aktiviert.
• MCP-Tool-Suite: die Live-Remote-MCP-Oberfläche der Website und der klarste Weg, eine persistente Serverintegration mit einem zukünftigen Seitentool zu vergleichen.
• Agent-Readiness-Checker: prüft mehrere server-sichtbare Agentensignale. Er sollte WebMCP absichtlich nicht bewerten, weil ein serverseitiger Fetch Tools, die in einem Live-Dokument registriert sind, nicht zuverlässig beobachten kann.
• Schema-Markup-Generator: ein weiteres Beispiel für einen deterministischen menschlichen Workflow, der unabhängig von der Agentenunterstützung vollständig bleiben muss.

Primärquellen

• WebMCP Draft Community Group Report — aktueller Entwurf, API-Definitionen, Berechtigungen, Sicherheit und expliziter Standardstatus.
• Chrome: WebMCP-Übersicht — Einstiegspunkt für Origin-Trial, Einschränkungen und Testeinrichtung.
• Chrome: Imperative API — aktueller Objektname, Registrierung, Lebenszyklus, Tests, Ereignisse und Cross-Origin-Kontrollen.
• Chrome: Deklarative API — experimentelle Formularannotationen und Übermittlungsverhalten.
• Chrome: WebMCP-Toolsicherheit — Annotationen, Origin-Exposition und Schutzmaßnahmen für Tool-Anbieter.
• Chrome: Sicherheitsüberlegungen für Agenten — bösartige Metadaten, kontaminierte Ausgaben, authentifizierte Sitzungen und Defense in Depth.
• Chrome: Best Practices für WebMCP — Tool-Umfang, Beschreibungen, Zustand und Zuverlässigkeit.
• Chrome: WebMCP-Evaluierungen — deterministische Tests und probabilistische Agentenbewertung.
• Chrome: Wann WebMCP und MCP verwenden — Frontend-/Seitenkontext versus persistente Backend-Grenzen.
• Chrome: Am WebMCP-Origin-Trial teilnehmen — Ankündigung des Experiments in Chrome 149.
• Chrome DevTools: WebMCP-Tools debuggen — Inspektion registrierter und aufgerufener Tools.
• Lighthouse: Registrierte WebMCP-Tools — informativer Audit für registrierte Tools.
• Cloudflare Browser Run: WebMCP — Beta-Lab-Sitzungen und Produktionseinschränkungen; API-Beispiele auf dieser Seite entsprechen nicht dem aktuellen Stand der Chrome-Dokumentation.

Verwandte Anleitungen

• Model Context Protocol
• Agentic Search
• llms.txt
• Schema-Markup für KI
• Für KI-Agenten — die derzeit verfügbaren agentenorientierten Dateien und die Remote-MCP-Oberfläche der Website; es wird keine WebMCP-Unterstützung beansprucht.

Kompatibilitäts- und Statusangaben wurden am 17. Juli 2026 verifiziert. Vor der Implementierung erneut prüfen, da Meilensteine, Flags, API-Namen und Entwurfstexte sich ändern können.

Änderungsprotokoll