WebMCP im Oktober 2026: Eine Website für KI-Agenten nutzbar machen, und was der Origin Trial wirklich bedeutet

WebMCP lässt eine Webseite einem KI-Agenten eine kurze Liste dessen übergeben, was er tun kann, jeweils mit Namen, Beschreibung und Eingabeschema, statt den Agenten die Seite aus Screenshots und DOM selbst entschlüsseln zu lassen. Findet ein Agent ein Tool check_order_status, kann er es mit einer Bestellnummer aufrufen. Ohne dieses Tool muss er das richtige Feld finden und den richtigen Button anklicken.

Das ist das Versprechen. Der Stand am 22. Oktober 2026 ist enger, als die meisten Beiträge vermuten lassen. WebMCP ist ein Vorschlag einer W3C Community Group, kein Standard. Chrome betreibt es als Origin Trial, ohne dass schon entschieden wäre, es auszuliefern. Ein einziger Verbraucher-Agent ruft die Tools auf (der in die ChatGPT-Desktop-App eingebaute Browser), und dieser Agent ignoriert die deklarative Formularvariante, die am 8. Oktober aus der Spezifikation gestrichen wurde. Das Engine-Team von Safari lehnt den Vorschlag ab; Mozilla ist neutral.

Dieser Artikel richtet sich an Entwickler und Product Owner, die entscheiden, ob sie WebMCP jetzt einbauen. Er behandelt, was die API ist, wer sie aufruft, wie man sie für echte Besucher einschaltet, wie man Tools schreibt, die einem Agenten keine geladene Waffe in die Hand drücken, und was Sie zuerst beheben sollten, wenn Agenten Ihre Website überhaupt nutzen sollen.

Was WebMCP ist

Die Spezifikation definiert eine JavaScript-API auf document.modelContext, über die eine Seite Tools registriert: „Die WebMCP-API ermöglicht es Webanwendungen, KI-Agenten JavaScript-basierte Tools bereitzustellen.“ Ein Tool hat einen name, eine description und einen execute-Callback sowie optional einen title, ein inputSchema (JSON Schema) und annotations. Beim Aufruf des Tools durch den Agenten läuft der eigene Code der Seite, mit der Sitzung des Nutzers.

Drei Dinge daran versteht man leicht falsch:

• Es ist kein Standard. Das Dokument ist ein Draft Community Group Report der Web Machine Learning Community Group und sagt das selbst: „Es ist weder ein W3C-Standard noch auf dem W3C-Standardisierungsweg.“ Die eigene Dokumentation von Chrome nennt es „einen vorgeschlagenen Webstandard“. Das Datum des Berichts ändert sich im Oktober alle paar Tage; seine Editoren kommen von Microsoft und Google.
• MCP steckt nicht darin. Die Spezifikation sagt, Seiten, die sie nutzen, „können als Model-Context-Protocol-Server betrachtet werden, die Tools in clientseitigem Skript implementieren“, und dann, sie „schreibt das Format nicht vor, in dem Tools dem Browser-Agenten bereitgestellt werden“. Die Prüfung durch Mozilla sagte es unverblümt: „Der Name führt in die Irre ... Hier gibt es kein MCP.“ Ein WebMCP-Tool verbindet sich nicht mit Ihrem MCP-Server im Backend und ersetzt auch keinen.
• Es macht Sie nicht auffindbar. Die Dokumentation von Chrome nennt die Einschränkung selbst: „Clients und Browser müssen eine Website direkt besuchen, um zu wissen, ob sie aufrufbare Tools hat.“ WebMCP hilft einem Agenten, der schon auf Ihrer Seite ist. Für die Auffindbarkeit tut es nichts.

Die API ist auf sichere Kontexte beschränkt und durch eine Permissions Policy tools abgesichert, deren Standard-Allowlist 'self' ist; ein Cross-Origin-iframe kann also keine Tools registrieren, es sei denn, die einbettende Seite erlaubt es.

Stand am 22. Oktober 2026

Chrome 156, die letzte Version im ursprünglichen Zeitfenster des Trials, ist am 20. Oktober 2026 in den Stable-Kanal gelangt. Chrome 162, das Ende der beantragten Verlängerung, ist für den 2. Februar 2027 als Stable geplant. Ob die Verlängerung schon gilt, ließ sich in der Konsole des Trials nicht bestätigen; planen Sie also so, als sei sie wahrscheinlich, aber nicht sicher.

Die Verlängerungsanfrage erklärt, warum Chrome mehr Zeit will: „Das Feedback aus dem Origin Trial hat Verbesserungen an der API nahegelegt, die wir umsetzen.“ Im selben Thread schrieb Dominic Farolino von Google, das Team „hofft, innerhalb des Verlängerungszeitraums zu I2S überzugehen“, also die Auslieferung zu beantragen, und: „Die imperative API ist deutlich beliebter als die deklarative, deshalb investieren wir als Reaktion auf die Bedürfnisse der Nutzer mehr in sie.“ Er erwähnte außerdem eine Continuation-API, eine Tool-Stability-API und Größenbeschränkungen für Tools, die gerade prototypisch umgesetzt werden. Die API, gegen die Sie heute schreiben, wird sich ändern.

Wer die Tools tatsächlich aufruft

Tools zu registrieren kostet nichts. Sie zu nutzen braucht einen Agenten, und die Liste der Agenten ist kurz.

Chromes eigene Test-Extensions. Die Dokumentation von Chrome bietet zwei Extensions an, darunter den Model Context Tool Inspector, um Tools in Demos und auf eigenen Seiten auszuprobieren. Sie brauchen Ihren eigenen API-Schlüssel für ein Modell, und Chrome weist darauf hin: „Diese Extensions sind getrennt von Gemini in Chrome.“ Es sind Entwicklerwerkzeuge, keine Kunden.

Der integrierte Browser von ChatGPT. Ein Beitrag eines OpenAI-Mitarbeiters im Entwicklerforum sagte am 25. August 2026: „Site Tools sind die Umsetzung des vorgeschlagenen WebMCP-Standards in ChatGPT.“ Die Dokumentation nennt Bedingungen: bestimmte Modelle, die neueste Desktop-App, in Enterprise-Workspaces die Freigabe durch einen Admin, keine Edu-Workspaces, und „Die Verfügbarkeit hängt auch vom Rollout ab“. Sie listet auch auf, was nicht unterstützt wird: „Deklarative API: Tools, die über HTML-Formularattribute definiert werden, sind als Site Tools nicht verfügbar“, außerdem Tools, die in iframes registriert werden, auch in solchen derselben Origin. Die Anweisung von OpenAI ist klar: „Verwenden Sie JavaScript, um Tools auf der Seite der obersten Ebene zu registrieren“. Die Dokumentation sagt nicht, ob eine Seite ein Origin-Trial-Token von Chrome braucht, damit ChatGPT ihre Tools sieht.

Gemini in Chrome. Google sagte im Mai, es „wird bald WebMCP-APIs unterstützen“. Eine Primärquelle, die seitdem sagt, dass es das tut, haben wir nicht gefunden. Bauen Sie darauf noch keinen Plan auf.

Alle anderen weichen aus. Jeder Agent in jedem Browser liest Seiten weiterhin auf die alte Art. Chrome sagt das in der eigenen Risikobewertung: „Browser-Agenten in Chrome können Websites weiterhin wie bisher bedienen, indem sie Nutzerverhalten simulieren.“ OpenAI: „Wenn kein passendes Tool verfügbar ist, kann der Agent möglicherweise trotzdem seine normalen Browserfunktionen nutzen.“ Eine Website ohne WebMCP ist für Agenten nicht unsichtbar. Eine Website mit kaputten Buttons und unbeschrifteten Feldern ist für alle schwer zu bedienen.

Die imperative API

Das ist die Version, die die Spezifikation definiert, die ChatGPT unterstützt und die laut Chrome die Entwickler bevorzugen. Ein Tool kapselt Logik, die die Seite schon hat. Hier ein reiner Lesezugriff für einen angemeldeten Kunden, nach dem Muster der Dokumentation von Chrome und der Feature-Erkennung von OpenAI:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

Worauf es dabei ankommt:

• Name, Beschreibung und Schema liest das Modell. Chrome empfiehlt höchstens 500 Zeichen pro Tool-Beschreibung, 150 pro Parameterbeschreibung, 30 pro Tool- und Parameternamen und 1,5 Tausend Zeichen pro Tool-Ausgabe und weist darauf hin, dass „diese Empfehlungen Änderungen unterliegen“. Das Explainer-Dokument der Spezifikation warnt: „Zu viele Tools (z. B. Dutzende oder Hunderte) bereitzustellen, kann die Leistung des Agenten stark beeinträchtigen“: Registrieren Sie, was der aktuelle Zustand der Seite braucht, und entfernen Sie den Rest über das Signal des AbortController.
• Das zweite Argument von execute trägt ein AbortSignal, damit ein abgebrochener Aufruf eine laufende Anfrage stoppen kann.
• Annotationen sind Hinweise. readOnlyHint kennzeichnet einen Lesezugriff. consequentialHint kennzeichnet alles, was bucht, kauft, sendet, löscht oder überträgt, und laut Dokumentation von Chrome „ermöglicht es Agenten und Browsern, verpflichtende Bestätigungsabfragen beim Nutzer durchzusetzen“. untrustedContentHint kennzeichnet Ausgaben mit Bewertungen, nutzergenerierten Inhalten oder Daten Dritter. Eine debugging-Annotation gibt es ab Chrome 156.
• Auch Seitencode kann Tools auflisten und ausführen, mit document.modelContext.getTools() und executeTool(), und ein toolchange-Ereignis wird ausgelöst, wenn sich die Liste ändert. Als JSON-String übergebene Argumente für executeTool() sind ab Chrome 155 veraltet.

React, Angular und Vue haben jeweils experimentelle Hilfsbibliotheken, und das npm-Paket webmcp-types liefert TypeScript-Typen. Ältere Tutorials, die navigator.modelContext aufrufen, sind überholt: Die Spezifikation hat die API am 27. Mai 2026 nach document verschoben.

Die deklarative API: im Trial von Chrome, nicht mehr in der Spezifikation

Die deklarative Version macht aus einem vorhandenen HTML-Formular mit zwei Attributen ein Tool. Für alte, formularlastige Websites ist das attraktiv, weil sich sonst nichts ändern muss:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

Im Trial von Chrome gilt: „Ruft ein Agent toolname auf, rückt der Browser das Formular in den Fokus und füllt dessen Felder aus. Das Formular bleibt für den Nutzer sichtbar.“ Der Browser baut die Parameter aus den Steuerelementen: aus ihren Namen, ihren <label>s, required und den Optionen eines <select>. Sofern das Formular nicht toolautosubmit trägt, „muss der Nutzer manuell auf Senden klicken, um die Aufgabe abzuschließen“, und genau das wollen Sie bei allem, was eine Bestellung auslöst oder einen Lead absendet. SubmitEvent.agentInvoked sagt Ihrem Handler, dass ein Agent das Formular ausgefüllt hat, und respondWith() gibt nach preventDefault() das Ergebnis an den Agenten zurück. Hören Sie mit addEventListener auf die Ereignisse toolactivated und toolcancel auf document.modelContext: window.ontoolactivated und window.ontoolcancel werden ab Chrome 156 nicht mehr unterstützt.

Der Haken ist ihr Status. Die jüngste Änderung am Explainer, vom 8. Oktober 2026, heißt „Remove declarative API from the spec for now“ und besagt jetzt, dass ein deklaratives Gegenstück „separat untersucht wird ... aber derzeit nicht Teil der Spezifikation ist.“ ChatGPT unterstützt es nicht. Chrome dokumentiert es im Trial weiterhin, und Farolino von Google argumentierte im Thread von Mozilla: „Wir sehen den Wert des deklarativen Vorschlags schlicht für Legacy-Websites, besonders formularbasierte.“ Betrachten Sie es als Chrome-Experiment innerhalb eines Experiments: ausprobieren ist in Ordnung, als einziger Weg ist es unklug.

Für echte Besucher einschalten

Ein Flag (chrome://flags/#enable-webmcp-testing) schaltet WebMCP im eigenen Browser zum Testen ein. Für Besucher bewirkt es nichts. Für sie braucht die Seite ein Origin-Trial-Token.

1. Registrieren Sie die Origin auf der WebMCP-Trial-Seite von Chrome. Origin Trials „sind öffentlich und für alle Entwickler offen“, und ein Token „aktiviert eine Funktion für alle Nutzer Ihrer Origin“.
2. Liefern Sie das Token auf jeder Seite aus, die Tools bereitstellen soll, als <meta http-equiv="origin-trial" content="..."> im <head> oder als Response-Header Origin-Trial:. Ein Token lässt sich auch per Skript einfügen. Ein Token gilt für eine Origin; eine Seite kann mehrere tragen.
3. Erneuern Sie es. Wird ein Trial verlängert, bittet Chrome die Registrierten, „für jede im Trial angemeldete Origin ein neues Token bereitzustellen“, und „Chrome ignoriert ungültige oder abgelaufene Tokens“. Ein abgelaufenes Token versagt stillschweigend: Die Tools erscheinen einfach nicht mehr.
4. Für Edge registrieren Sie sich separat auf der Trial-Seite von Edge. Dessen Bedingungen verlangen: „Wo möglich, stimmen Sie zu, Feature-Erkennung / Graceful Degradation anzuwenden.“

Auch die WebMCP-Audits von Lighthouse setzen die Trial-Registrierung voraus; wer sie ohne Token testet, sieht sie fehlschlagen.

Tools schreiben, die sich gefahrlos aufrufen lassen

Der Sicherheitsabschnitt der Spezifikation ist nicht normativ und sagt offen, wo die Last liegt: Zu verhindern, dass ein Agent manipuliert wird, sei „in erster Linie Aufgabe des Sicherheitsmodells des Agenten selbst und nicht etwas, das diese Spezifikation normativ durchsetzen kann.“ Ihre Tools entscheiden trotzdem, wie viel Schaden ein manipulierter Agent anrichten kann.

• Hinweise können lügen, deshalb vertrauen Agenten ihnen nicht. Die Spezifikation: „Eine bösartige Website kann diese Hinweise weglassen oder falsch darstellen.“ OpenAI: „Der Name eines Tools oder die Behauptung, es lese nur Daten, ist kein Beweis dafür, was es tut“, und jeder Aufruf in seinem Browser durchläuft eine Sicherheitsprüfung, wobei bei Käufen und ähnlichen Aktionen weiterhin eine Bestätigung verlangt wird. Annotieren Sie trotzdem ehrlich. Daran entscheidet ein sorgfältiger Agent, wann er den Nutzer fragt.
• Beschreiben Sie Wirkungen exakt. Das schlechte Beispiel der Spezifikation selbst ist ein Tool, das mit „Schließt den aktuellen Warenkorb ab“ beschrieben ist und „tatsächlich einen Kauf auslöst. Der Nutzer wollte nichts kaufen.“ Wenn ein Tool eine Karte belastet, steht das in der Beschreibung, und consequentialHint ist true.
• Autorisieren Sie jedes Mal auf dem Server. Das Tool läuft mit der Sitzung des Nutzers; die Spezifikation merkt an: „Agenten können Identität und Authentifizierungskontext des Nutzers aus dem Browser erben.“ Ein Tool-Aufruf ist eine Anfrage dieses Nutzers und unterliegt denselben Prüfungen. Der Rat des Explainers gilt: „Im Code streng validieren, im Schema locker“, denn strenge Schemafehler können Agenten ins Stocken bringen.
• Rechnen Sie mit Prompt Injection. Die Spezifikation nennt sie an erster Stelle, in drei Formen: Anweisungen, die in Tool-Metadaten versteckt sind, in der Tool-Ausgabe, und Angriffe, die Tools als Ziel nutzen. Ausgaben mit Text, den andere Personen geschrieben haben (Bewertungen, Nachrichten, Produktfragen), gehören unter untrustedContentHint und sollten als Daten zurückgegeben werden, nicht als Prosa, die ein Agent für Anweisungen halten könnte.
• Schließen Sie Seiten bewusst aus. Ein Header Permissions-Policy: tools=() macht die API für ein Dokument und alles, was es einbettet, unverfügbar. Kandidaten sind Kontoeinstellungen, Zahlungsseiten und Admin-Bereiche.

Eine Anmerkung zur Dokumentation von Chrome: Ihre Sicherheitsseite sagt, der Entwurf enthalte eine Methode requestUserInteraction(), um den Nutzer mitten in einem Tool zu fragen. Der Entwurf der Spezifikation vom 20. Oktober 2026 hat keine solche Methode, und der Explainer führt die Nutzerbestätigung weiterhin als offene Frage. Planen Sie nicht darum herum.

Was die Ingenieure von Safari und Firefox beanstanden

Die Einwände sind auch dann lesenswert, wenn Sie nur für Chrome bauen, denn sie beschreiben, wie WebMCP in der Praxis schiefgehen kann.

Die Position von WebKit, am 3. Juni 2026 veröffentlicht, argumentiert, schwer bedienbare Seiten sollten in HTML und ARIA repariert werden, „wovon Nutzer, assistive Technologien und Agenten gleichermaßen profitieren“, und dass bei Tools „die Brüchigkeit nur vom DOM in die Tool-Beschreibungen wandert.“ Sie behandelt einen Agenten wie assistive Technologie, die nicht herausgehoben werden sollte: „WebMCP tut das Gegenteil und macht ‚ein Agent steuert‘ zu einer beobachtbaren Tatsache.“ Und sie hält fest, dass der Vorschlag „kein Einwilligungs- und Umkehrbarkeitsmodell für folgenreiche Aktionen hat“.

Mozilla hat sich im August auf neutral festgelegt: WebMCP „führt eine potenziell wertvolle Abstraktion ein“, „öffnet aber eine Angriffsfläche, deren reale Dynamik zu viele offene Fragen lässt, um sie uneingeschränkt zu befürworten“. Es warnt, Websites könnten „Tools bereitstellen, die nicht zur Erfahrung eines Nutzers auf der Seite passen“, zum Beispiel, um „Prompt Injection zu liefern, die für typische Nutzer unsichtbar ist“. Einzelne Mozilla-Ingenieure haben Interesse an einem imperativen Function-Calling-Primitiv gezeigt; das ist keine Billigung durch Mozilla.

Chrome selbst stuft das Risiko, dass andere Engines WebMCP nicht übernehmen, für Nutzer als gering ein. Die Kehrseite: Eine Website gewinnt in Safari oder Firefox heute nichts, wenn sie Tools ergänzt.

Was heute für jeden Agenten funktioniert

Jeder Browser-Agent liest Screenshots, HTML und den Accessibility Tree. Googles Leitfaden auf web.dev zu agentenfreundlichen Websites sagt, Agenten „nutzen das DOM und den Accessibility Tree, um eine saubere, strukturierte Liste interaktiver Elemente zu erhalten, und gleichen sie dann mit einer visuellen Darstellung ab“. Die praktische Liste ist kurz:

• Verwenden Sie echte Elemente vom Typ <button> und <a>, keine anklickbaren <div>s und <span>s.
• Verknüpfen Sie jedes <label> per for mit seinem Eingabefeld.
• Keine transparenten Overlays über interaktiven Elementen, und nichts Interaktives, das kleiner als 8 Quadratpixel ist.
• Ein stabiles Layout, das sich nicht verschiebt, während der Agent gerade klicken will.

Ihr Fazit: „Alles, was wir vorschlagen, um eine Website ‚agententauglich‘ zu machen, macht Websites auch für Menschen besser.“ Das ist, fast Wort für Wort, auch das, was WebKit anstelle von WebMCP verlangt. Fällt Ihr Checkout bei einem Accessibility-Audit durch, beheben Sie das, bevor Sie ein einziges Tool schreiben.

Lighthouse hat seit Version 13.2.0 (1. Mai 2026) eine Kategorie Agentic Browsing, in Chrome ab Version 150 verfügbar und in Lighthouse 13.4.1 (20. Juli 2026) für die PageSpeed-Insights-API aktiviert. Sie prüft die Teilmenge der Accessibility-Audits, die für Maschinen zählen, die Layoutstabilität, registrierte WebMCP-Tools und Formulare ohne sie, die Gültigkeit des Schemas und das Vorhandensein einer Datei llms.txt. Chrome nennt sie „informativ und ohne Benchmark“: Es gibt keinen Wert von 0 bis 100. Zu llms.txt gilt die eigene Empfehlung der Google Suche, dass solche Dateien ignoriert werden: Eine hinzuzufügen „wird der Sichtbarkeit oder den Rankings Ihrer Website in der Google Suche weder schaden noch nützen“. Dass Lighthouse nach der Datei sucht, ändert daran nichts.

Sollten Sie WebMCP jetzt einbauen?

Auf Shopify mit einem Liquid-Theme: keine Arbeit. Die Tools für Storefront, Warenkorb und Checkout von Shopify sind schon live, „Es gibt nichts zu installieren oder zu konfigurieren“, mit dem eigenen Vorbehalt von Shopify, dass „die Agentenunterstützung derzeit über einen Origin Trial auf Chromium-basierte Browser beschränkt ist“. Headless-Storefronts sind nur in der Hydrogen Developer Preview abgedeckt. Eine andere Commerce-Plattform, einen Zahlungsanbieter oder ein CDN, das WebMCP für seine Kunden einschaltet, haben wir nicht gefunden.

Auf einer individuellen, Headless- oder Legacy-Website: Es kommt darauf an, wer Ihre Nutzer sind.

• Wenn Ihre Kunden oder Mitarbeiter den Browser der ChatGPT-Desktop-App nutzen, sind imperative Tools auf der Seite der obersten Ebene die einzigen, die sie erreichen. Beginnen Sie mit zwei oder drei reinen Lese-Tools rund um Ihre häufigste Aufgabe (Bestellstatus, Verfügbarkeit, ein Angebot), hinter Feature-Erkennung, mit einem Origin-Trial-Token, und messen Sie, ob sie jemand aufruft.
• Wenn Sie in Chrome günstig experimentieren wollen, sind deklarative Attribute an bestehenden Formularen ein paar Stunden Arbeit. Bleiben Sie dabei nicht stehen: ChatGPT sieht sie nicht, und die Spezifikation enthält sie nicht mehr.
• Wenn Sie keinen Beleg haben, dass Agenten Sie besuchen, beheben Sie zuerst Semantik, Beschriftungen und Layout. Diese Arbeit hilft jedem Agenten und jedem Menschen, der assistive Technologie nutzt, und nichts davon wird verworfen, wenn sich die API ändert.

Lassen Sie in jedem Fall die normale Oberfläche vollständig. Der Rat von OpenAI: „Behalten Sie die normale Oberfläche für Menschen und Browser bei, die WebMCP nicht unterstützen.“

Was sich ändern könnte

• Ein Intent to Ship. Das Team von Chrome hofft, ihn innerhalb des Verlängerungszeitraums zu stellen, der mit Chrome 162 (2. Februar 2027) endet, falls die Verlängerung Bestand hat. Eine Auslieferung würde die Tokens in Chrome überflüssig machen.
• Form der API. Eine Continuation-API (Ergebnisse, die nach einer Navigation auf der nächsten Seite ankommen), eine Tool-Stability-API und Größenbeschränkungen werden prototypisch umgesetzt. Neuere Versionen haben window.ontoolactivated und als String übergebene Argumente bereits entfernt.
• Das Schicksal der deklarativen API. „Vorerst“ aus der Spezifikation entfernt, noch im Trial von Chrome.
• Aufrufer. Die Unterstützung durch Gemini in Chrome ist angekündigt, aber nicht ausgeliefert. Die Seite zum Implementierungsstand der Spezifikation führt WebMCP für Webanwendungen auf der Ray-Ban Display von Meta als demnächst verfügbar und experimentelle Unterstützung im Assistenten Leo von Brave.

Wenn Sie jetzt Tools hinzufügen, halten Sie sie in einem Modul, hinter Feature-Erkennung, damit die nächste Änderung eine einzige Anpassung ist.

Wo Sie Hilfe bekommen

Wir bauen die Teile einer Website und ihres Backends, die Agenten berühren: Tools, die bestehende Logik für Bestellungen, Buchungen und Konten kapseln, eine Autorisierung, die den Aufruf eines Agenten wie jede andere Anfrage dieses Nutzers behandelt, und die Korrekturen an Semantik und Barrierefreiheit, die eine Website nutzbar machen, bevor es irgendein Tool gibt. Unsere Leistung zur Entwicklung von KI-Agenten und MCP-Integration umfasst WebMCP-Tools ebenso wie MCP-Server im Backend, die trotz des Namens etwas anderes sind.

Wenn Sie wissen möchten, was ein Agent heute auf Ihrer Website sieht und ob Tools für Ihre Kunden etwas ändern würden, schreiben Sie an office@c9group.dev.