Wird WebMCP das Newsletter- & Rabatt-Popup beenden? Wir hoffen es. Wir haben eines auf unserer Website registriert, um es herauszufinden.

Sie klicken auf einen Link, die Seite beginnt zu laden, und ein Popup schiebt sich darüber, bevor Sie einen Satz gelesen haben. Zehn Prozent Rabatt, wenn Sie einer Firma, bei der Sie vor neun Sekunden angekommen sind, eine E-Mail-Adresse überlassen. Sie schließen es. Irgendwo weiter unten wartet ein zweites auf den Moment, in dem Sie sich zum Zurück-Button bewegen.

Dieses Popup ist kein Designfehler. Es tut genau das, wofür es gebaut wurde, und es funktioniert gut genug, dass im Marketingteam niemand für seine Abschaffung argumentiert.

Eine E-Mail-Adresse ist der Schlüssel zum Retention-Programm. Sobald eine Marke eine hat, kann sie die Lifecycle-Strecken fahren, die hinter jeder E-Commerce-Plattform liegen: die Willkommensserie, die bei der Anmeldung auslöst, die Browse-Abandonment-Mail, die rausgeht, wenn jemand ein Produkt ansieht und wieder geht, die Sequenz zu abgebrochenem Warenkorb und Checkout, die Erinnerungen nach dem Kauf und zum Nachbestellen, die Rückgewinnung für alle, die still geworden sind. Keine davon kann ohne die Adresse starten. Alle werden durch Verhalten ausgelöst und verdienen weiter, lange nachdem die Anzeige, die den Besucher gebracht hat, bezahlt ist.

Genau das kaufen die zehn Prozent. Der Rabatt ist der Kaufpreis für eine dauerhafte Kontaktlinie, und er ist billig neben dem bezahlten Klick, der Sie geliefert hat. Ausgelöste Strecken verdienen je Empfänger weit mehr als ein Newsletter an alle, und die Sequenz zum abgebrochenen Warenkorb verdient am meisten, wer also den Wert einer Adresse zählt, zählt nicht eine E-Mail. Er zählt einen Strom davon, der über Jahre läuft.

Es erklärt auch das Timing. Das Popup löst bei der Ankunft aus, bei einer bestimmten Scrolltiefe oder beim ersten Anzeichen, dass Sie auf den Zurück-Button zusteuern, denn ein Besucher, der ohne Adresse geht, ist für immer unerreichbar, während ein Besucher, der eine hergibt, der Anfang einer Sequenz ist. Eine Marke, die bei drei Prozent ihrer Besucher Adressen einsammelt, macht ein sehr gutes Geschäft zum Preis, die anderen siebenundneunzig zu verärgern.

WebMCP rührt daran nichts. Was es ändert, ist der Mechanismus. Eine Seite kann ihre Anmeldung als Funktion veröffentlichen, in klaren Worten beschreiben, was sie tut, und den KI-Agenten, der für den Besucher arbeitet, sie aufrufen lassen, wenn der Besucher tatsächlich nach dem Angebot fragt. Die Adresse kommt weiterhin an, der Rabatt geht weiterhin raus, und nichts unterbricht das Lesen.

Für die Lesenden ist das der ganze Gewinn. Die Frage ist, wie viel davon sich heute einlösen lässt, und die ehrliche Antwort lautet: ein Teil.

Wie ein Besucher es erlebt, wenn das Popup verschwindet

Hier steht dasselbe Angebot, auf zwei Wegen eingesammelt. Links steht, was ein Besucher heute bekommt. Rechts steht, was dieselbe Person bekommt, wenn die Seite ihre Anmeldung als etwas veröffentlicht hat, das ihr Assistent ausführen kann.

Was das Popup wirklich beendet, ist eine Verschiebung im Traffic

Manche in der Marke würden das Popup komplett streichen. Es bleibt, weil Leute zu unterbrechen die einzige Methode ist, die zuverlässig E-Mail-Adressen einsammelt, und weil die Kosten dieser Unterbrechung beim Besucher landen und nicht bei dem Team, das sie gewählt hat. Alle Lesenden bekommen ein schlechteres Erlebnis, damit ein kleiner Prozentsatz von ihnen eine Adresse hergibt, und dieser Handel hält seit rund zwanzig Jahren, weil nichts anderes Adressen ebenso gut eingesammelt hat.

Der Handel bricht erst, wenn eine zweite Methode dieselben Adressen ohne die Unterbrechung einsammelt, und er bricht Besuch für Besuch.

Ein Popup wirkt nur auf einen Menschen, der auf einen Bildschirm schaut. Wenn ein Assistent das Lesen übernimmt, gibt es keinen Bildschirm zu verdecken und kein Zögern, auf das sich ein Timer stützen könnte, dieser Besuch bringt also keine Adressen, egal wie gut das Popup eingestellt war.

Derselbe Besuch kann trotzdem eine Adresse hervorbringen. Wer seinen Assistenten nach dem Rabatt fragt, gibt eine freiwillig her, mit einem Namen daran, in dem Moment, in dem er sie hergeben wollte. Diese Adresse ist sauberer, die Absicht dahinter ist stärker, und es wurde kein Wohlwollen dafür ausgegeben.

Ein Marketingteam behält das Popup so lange, wie es sich rechnet. Je mehr Besuche über Assistenten kommen, desto kleiner werden Publikum und Ertrag, während der Ärger, den es verursacht, konstant bleibt. Dieselbe Rechnung, die es auf die Seite gebracht hat, nimmt es irgendwann wieder herunter.

Nichts davon kommt nach einem Zeitplan, den eine Spezifikation steuert. Es kommt, wenn genug Menschen das Web durch etwas lesen, das in ihrem Auftrag liest, und das ist eine Frage des Traffics und keine Frage der Standards, und in Ihren eigenen Logs ist sie heute schon messbar.

Klar gesagt gehört dazu, dass das Ziel gut ist. Ein Web, in dem das Angebot für jeden verfügbar ist, der danach fragt, und für alle anderen unsichtbar bleibt, ist besser für die Lesenden und für die Marke nicht schlechter. Das ist eine seltene Kombination, und sie ist der Grund, dafür früh zu bauen statt auf die Reichweite zu warten.

Apples Einwand lautet, dass eine Seite nie erfahren sollte, dass ein Agent steuert

Zwei Apple-Ingenieure haben WebKits Einwand im öffentlichen Standards-Positions-Thread im Juni 2026 dargelegt, und die Position wurde am 11. Juni als Ablehnung festgehalten. Sie nennen sechs Gründe, und der erste betrifft, was ein Agent überhaupt ist.

WebKits Position hält fest, dass ein Agent, der für einen Nutzer handelt, „faktisch assistive Technologie“ ist: Er sollte eine Seite so bedienen, wie der Nutzer es täte, und die Seite sollte ihn nicht für eine gesonderte Behandlung herausgreifen. WebMCP tut das Gegenteil. Es macht „ein Agent steuert“ zu einer beobachtbaren Tatsache, und sobald das getrennt adressierbar ist, hält nichts mehr die beiden Oberflächen im Gleichstand. Eine Seite kann Agenten Fähigkeiten geben, die sie ihrer eigenen Oberfläche vorenthält, oder sie ihnen vorenthalten, was die beiden als „das Problem der Screenreader-Blockade, übertragen auf KI-Agenten“ beschreiben.

Sie bezweifeln auch das Zuverlässigkeitsversprechen. Ein Agent wählt ein Tool weiterhin danach aus, dass er dessen Namen und Beschreibung liest, und die Spezifikation räumt selbst ein, dass beide mehrdeutig und nicht überprüfbar sind, denn es gebe „keine Garantie, dass die erklärte Absicht eines WebMCP-Tools seinem tatsächlichen Verhalten entspricht“. Ein typisiertes Schema legt die Form eines Arguments fest und nicht die Bedeutung, die der Agent erschließen muss, nach ihrer Lesart wandert die Sprödigkeit also aus der Seite in die Tool-Beschreibungen, statt zu verschwinden.

Der Datenschutzeinwand ist schärfer als der übliche. Eine Seite kann mehr Parameter verlangen, als sie braucht, und ein hilfsbereiter Agent füllt sie aus Dingen, die der Nutzer dem Agenten gesagt hat und nicht der Seite. Die Spezifikation nennt das in ihrem eigenen Text eine Pipeline „von der Personalisierung zum Fingerprinting“.

Sie weisen außerdem darauf hin, dass die Teile, die ein Prüfer bräuchte, um irgendetwas davon zu beurteilen, darunter die Cross-Origin-Sicherheitsanalyse und der Einwilligungs-Hook, weiterhin als offene Arbeit markiert sind, und dass eine Gruppe mit einem Mandat rund um maschinelles Lernen der falsche Ort für Änderungen ist, deren eigentliche Heimat HTML und die Semantik der Barrierefreiheit sind.

Eine der von ihnen genannten Invarianten zielt direkt auf das Thema dieses Artikels: „Manche Nutzer werden Agenten nicht verwenden oder können es nicht, das Ergebnis muss also allen Nutzern zugutekommen und darf die nicht bevorzugen, die einen haben.“

Stellen Sie das neben das Muster im Code weiter oben. Das Popup zu unterdrücken hängt daran, dass die Seite erfährt, dass ein Agent gehandelt hat, und genau diese Beobachtbarkeit sollte es nach Apples Argument nicht geben. Das ruhige Erlebnis, das oben beschrieben wurde, wird mit einem Signal bezahlt, von dem eine zweite Engine sagt, das Web sollte es nicht preisgeben. Beides kann wahr sein, und wer darauf baut, sollte wissen, dass er sich für eine Seite entscheidet und kein abgeschlossenes Werkzeug aufnimmt.

Googles Editoren haben im selben Thread geantwortet und gefragt, was WebKit zufriedenstellen würde, ohne die imperative API zu entfernen. Die Antwort lautete, man werde nicht Punkt für Punkt antworten, weil jede Frage voraussetze, dass der Ansatz tragfähig sei, und schlug einen Neuanfang vor: eine neue Community Group, das Problem vor jeder Lösung definiert, und ein Workshop rund um die TPAC Ende Oktober 2026.

Kein iPhone kann das ausführen, auch Chrome für iPhone nicht

Apples Position ist nicht nur eine Stimme in einem Standards-Thread. Sie entscheidet über die Funktion für jeden Browser auf der Plattform.

Jeder Browser, der heute auf iOS ausgeliefert wird, rendert mit WebKit. Chrome für iPhone ist Safaris Engine mit Googles Oberfläche darüber, und für Edge, Firefox und den Rest gilt dasselbe. Eine Funktion, die WebKit nicht umsetzt, ist auf einem iPhone deshalb nicht verfügbar, egal auf welches Browser-Symbol jemand tippt.

Das kann sich langsam ändern. Die britische Competition and Markets Authority hat Apples Engine-Vorgabe als Verstoß gegen ihr Regime zum Strategic Market Status gewertet, mit einem Compliance-Plan fällig im Juni 2026 und Änderungen, die im Herbst 2026 in iOS 20 erwartet werden, vor der vollständigen Einhaltung im Januar 2027. Der Digital Markets Act der EU erlaubt alternative Engines seit 2024. In der Praxis hat keines von beidem eine hervorgebracht: Kein Browserhersteller hat eine alternative Engine über den App Store ausgeliefert, und sowohl Google als auch Mozilla haben Portierungen, die unveröffentlicht bleiben.

Für eine E-Commerce-Marke ist das die Zahl, die mehr zählt als jedes Datum einer Spezifikation, denn iPhone-Traffic ist bei den meisten Storefronts ein großer Anteil, und nichts davon erreicht heute ein registriertes Tool.

Zum Testen braucht es einen Chromium-Browser, den die meisten Agenten ohnehin nutzen

Die Agenten, die das Lesen übernehmen, sitzen bereits auf der richtigen Engine. Claude läuft als Erweiterung in Chrome, Gemini ist in Chrome eingebaut, Copilot sitzt in Edge, und Perplexitys Comet ist ein eigener Chromium-Browser. Agentisches Surfen auf dem Desktop ist heute weit überwiegend Chromium, die Engine ist also selten das Hindernis.

Das Hindernis, das übersehen wird, ist, dass nicht jeder Assistent, der Ihre Seite liest, überhaupt ein Browser ist. Bitten Sie ChatGPT oder Claude im Chatfenster, eine URL zu öffnen, und der Abruf läuft meist auf einem Server: Ihr HTML wird geholt, es läuft kein JavaScript, und es entsteht nie eine Tool-Liste. Dieser Assistent kann jedes Wort Ihrer Seite lesen und trotzdem nicht ahnen, dass darauf ein Tool registriert wurde. Nur ein Agent, der in einer echten Chromium-Seite arbeitet, sieht das Tool, was heute etwas wie Gemini in Chrome bedeutet oder eine Erweiterung, die die Erkennung selbst umsetzt.

Das Hindernis ist, dass die Funktion weiterhin hinter einem Gatter liegt, und es gibt zwei Wege hindurch.

Die Website meldet sich für Chromes Origin Trial an und liefert den Token aus. Das ist der Weg, den ein Produktivshop geht, und er hat drei Schritte.

Registrieren Sie den Origin unter developer.chrome.com/origintrials/#/register_trial/4163014905550602241, das ist der WebMCP-Trial, und er läuft von Chrome 149 bis Chrome 156. Tragen Sie den Origin ein, der Ihre Seiten tatsächlich ausliefert, samt Subdomain, denn ein Token für example.com deckt www.example.com nicht ab. Wenn Ihre Apex-Domain auf www weiterleitet, registrieren Sie den www-Host und verzichten auf das Subdomain-Matching, denn eine Weiterleitung lädt nie ein Dokument und braucht deshalb nie den Token.

Liefern Sie den Token aus, den Sie bekommen, entweder als Response-Header oder als Meta-Tag im Head jeder Seite, die ein Tool registriert:

<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">

Geben Sie ihn nur aus, wenn Sie einen haben. Ein leerer oder abgelaufener Token schreibt bei jedem Seitenaufruf einen Fehler in die Konsole, machen Sie das Tag also bedingt, statt ein leeres Attribut einzufügen und es zu vergessen.

Edge fährt einen eigenen Trial mit eigener Registrierung und eigenem Token. Die Anmeldung beim einen bringt für den anderen nichts.

Oder der Besucher aktiviert es selbst, indem er Chrome mit --enable-blink-features=WebMCP startet oder in chrome://flags die experimentellen Web-Plattform-Funktionen einschaltet. Das ist der Weg eines Entwicklers, nicht der eines Kunden.

Diese Seite geht den ersten Weg. Jede Seite dieser Website liefert einen WebMCP-Origin-Trial-Token aus, ein Besucher in Chrome 149 bis 156 bekommt also document.modelContext, ohne etwas einschalten zu müssen, und das Panel weiter oben sagt es ihm. Dieser Token läuft am 17. November 2026 ab, ab dann wird das Tool für gewöhnliche Besucher still, bis der Trial verlängert wird oder die Funktion regulär erscheint, und das Formular läuft weiter wie immer. Wer Safari nutzt, wer irgendeinen Browser auf einem iPhone nutzt oder wer ein Chrome außerhalb dieses Versionsbereichs nutzt, sieht das Formular und sonst nichts.

Alte Anleitungen funktionieren nicht, und die meisten haben das Datum falsch

WebMCP ist kein fertiger Webstandard. Es ist ein Entwurf, herausgegeben von Ingenieuren bei Google und Microsoft, und Entwürfe ändern sich, während Leute bereits darauf bauen. Dieser hat sich so geändert, dass Code bricht.

Der Name, den Sie aufrufen, ist umgezogen. Früher war es navigator.modelContext, jetzt ist es document.modelContext. Chrome hat beide Namen eine Zeit lang akzeptiert und Entwickler in der Konsole gewarnt, dann hat es den alten in Chrome 152 nicht mehr angenommen, und diese Version hat am 25. August 2026 alle erreicht. Code in der alten Schreibweise wird nicht langsamer und nicht schlechter. Er hört auf.

Wir weisen darauf hin, weil sich die Berichte über den Zeitpunkt nicht einig sind. Mehrere setzen die Änderung in den August 2026. Die eigene Historie des Projekts setzt sie in den Mai, drei Monate früher:

Nutzen Sie document.modelContext. Ein Tutorial, das nach navigator greift, wurde gegen etwas geschrieben, das es nicht mehr gibt, und ein Datum aus einem Blogbeitrag ist weniger wert als dasselbe Datum aus der Commit-Historie des Projekts.

Unterstützt wird es von Chromium und sonst nichts. Chrome hat im Juni 2026 einen öffentlichen Test eröffnet, der bis Chrome 156 läuft. Edge fährt ab Edge 150 einen eigenen, und Brave hat es experimentell, und beide bauen auf Chromes Engine. Apple hat den Vorschlag am 11. Juni 2026 förmlich abgelehnt. Mozilla hat sich nicht positioniert und hält einen Prototyp offen.

Ein Tool ist eine Funktion plus die Worte, die einem Assistenten sagen, wann er sie nutzt

Ein Tool ist ein Dictionary mit einem Namen, einer Beschreibung, einem JSON-Eingabeschema und einem execute-Callback. Der Name akzeptiert 1 bis 128 alphanumerische ASCII-Zeichen sowie Unterstrich, Bindestrich und Punkt. Die Anforderung eines Secure Context gilt für die gesamte Schnittstelle, getTools und executeTool eingeschlossen, und der Zugriff wird über ein Permissions-Policy-Feature namens tools gesteuert, dessen Standard-Allowlist 'self' ist.

Die Beschreibung wiegt schwerer als der Name. Ein Agent wählt zwischen Tools, indem er Beschreibungen liest, eine Beschreibung für ein Entwickler-Changelog verliert also gegen eine, die für die entscheidende Person geschrieben ist.

Die Anmeldung als Tool zu schreiben kostet rund dreißig Zeilen

Das Muster hat zwei Hälften. Registrieren Sie das Angebot als Tool, und bringen Sie dem Modal bei, sich zurückzuziehen, sobald das Angebot angenommen wurde.

const modelContext = document.modelContext || navigator.modelContext;

if (modelContext) {
  modelContext.registerTool({
    name: "subscribe_to_offer",
    title: "Get the first-order discount code",
    description:
      "Starts a first-order discount signup by sending a confirmation email to an " +
      "address. The code arrives only after the address is confirmed. Call this when " +
      "the visitor asks for the discount or asks to join the mailing list.",
    inputSchema: {
      type: "object",
      properties: {
        email: {
          type: "string",
          format: "email",
          description: "The address the visitor wants the code sent to."
        }
      },
      required: ["email"]
    },
    annotations: { readOnlyHint: false },
    execute: async ({ email }, { signal }) => {
      const res = await fetch("/api/subscribe", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ email, source: "webmcp" }),
        signal
      });

      if (!res.ok) {
        return "The signup did not go through. The form near the foot of the page still works.";
      }

      // Silence the popup for the rest of this visit. Make it permanent from the
      // server when the confirmation link is clicked, never from here.
      try { sessionStorage.setItem("offer_asked", "1"); } catch (e) {}

      return "Confirmation email sent. The code arrives once the address is confirmed.";
    }
  });
}

Das Popup wird in dem Moment still, in dem das Tool läuft, und darum geht es bei der ganzen Sache.

Das Flag hält absichtlich nur für diesen Besuch. Das Popup dauerhaft abzuschalten, bevor jemand den Bestätigungslink geklickt hat, nimmt einem Besucher, dessen Adresse nie bestätigt wurde, die Anmeldung weg und lässt ihm gar keinen Weg zum Abonnement. Legen Sie das Popup für den Besuch von der Seite aus still. Dauerhaft machen Sie es von Ihrem Server aus, sobald die Bestätigung geklickt ist.

annotations: { readOnlyHint: false } sagt dem Agenten, dass der Aufruf etwas ändert statt etwas zu lesen. Das ist ohnehin der Standard, und es auszuschreiben bringt den nächsten Leser auf eine Zeile Abstand zu untrustedContentHint, und das ist die Annotation, die für jedes Tool zählt, das Text zurückgibt, auf den ein Agent hin handelt.

Das signal ist ein Abbruchsignal, das der Browser jedem Tool übergibt, das er ausführt. Es in die Anfrage durchzureichen bedeutet, dass ein Agent, der auf halbem Weg aufgibt, keine Anmeldung für jemanden zu Ende laufen lässt, der nicht mehr fragt.

Es gibt keine Möglichkeit, die Seite zu fragen, ob ein Agent sie beobachtet. Die Spezifikation bietet getTools, executeTool und ein toolchange-Ereignis, und keines davon beantwortet die Frage. Dass Ihr eigenes Tool aufgerufen wird, ist das einzige verlässliche Signal, das Sie bekommen. Schreiben Sie dasselbe Flag, das Ihr Popup ohnehin prüft, dann löst es für diesen Besucher nicht mehr aus, genauso wie es aufhört, nachdem jemand das Formular ausgefüllt hat.

Die Fassung, die auf dieser Seite läuft

Diese Website registriert ein Tool namens contact_wislr, und es ist seit der Veröffentlichung dieses Artikels live. Das Kontaktformular dieser Website öffnet sich auf einen Klick, statt bei Exit-Intent auszulösen, das Tool nimmt hier also keine Unterbrechung weg. Es nimmt das Tippen weg.

Drei Entscheidungen dieser Umsetzung sind es wert, kopiert zu werden.

Das Schema fragt mehr ab als das Formular. Das Formular ist ein einzelnes Textfeld mit einem Platzhalter, der daran erinnert, Name und E-Mail anzugeben. Viele Nachrichten kommen ohne beides an, und eine Nachricht ohne Antwortadresse ist ein Lead, der nicht beantwortet werden kann. Das Tool deklariert name, email und website als benannte Eingaben neben der Nachricht, ein Agent, der den Aufruf füllt, hat also einen offensichtlichen Platz dafür.

Der Rückgabewert gibt dem Agenten etwas an die Hand. Der execute-Callback kann auf beliebiges auflösen, und executeTool reicht dem Agenten einen String, den er liest. Wenn eine Nachricht ohne E-Mail-Adresse ankommt, sagt unserer das und bittet den Agenten, eine einzuholen und eine zweite Nachricht zu senden. Eine Bestätigung, die nur „gesendet“ sagt, verschenkt die eine Gelegenheit, den Aufruf zu korrigieren, solange der Besucher noch da ist.

Der Agent teilt sich das Sendebudget des Formulars. Das Formular erlaubt drei Nachrichten je Browsersitzung, gezählt in sessionStorage. Das Tool liest und schreibt denselben Zähler, ein Agent und ein Besucher auf derselben Seite bekommen also drei zusammen und nicht drei für jeden. Dafür war eine Änderung am Formular nötig, das den Zähler bislang einmal beim Seitenaufbau gelesen und in einer Variablen gehalten hatte. Eine zwischengespeicherte Kopie gibt jeder Oberfläche ihr eigenes Budget und lässt die zuletzt schreibende die andere zurückrollen, und das ist die Art Fehler, die erst auftaucht, sobald es eine zweite Oberfläche gibt.

Der Endpunkt ist derselbe, an den das Formular ohnehin postet. Die benannten Felder werden vor dem Absenden in den Nachrichtentext zusammengesetzt, der bestehende Handler brauchte also keine Änderung, um sie zu lesen, und die Nutzlast trägt ein source-Feld, damit von Agenten gesendete Nachrichten getrennt von getippten gezählt werden können, ohne Prosa zu parsen.

Wie Sie es in Aktion sehen

Diese Website liefert den Trial-Token aus, es muss also nichts eingeschaltet werden. Öffnen Sie hier eine beliebige Seite in Chrome 149 bis 156, dann sagt Ihnen das Panel weiter oben in diesem Artikel, ob Ihr Browser das Tool hat, und der Button darunter ruft es tatsächlich auf.

Um es selbst zu prüfen, fragen Sie den Browser, welche Tools ihm angeboten wurden:

const mc = document.modelContext || navigator.modelContext;
const tools = await mc.getTools();
console.log(tools.map(t => t.name));
// ["contact_wislr"]

In Chrome 151 haben beide Namen noch aufgelöst, das ist der Alias in seinem letzten Meilenstein. Ab Chrome 152 antwortet nur noch document.modelContext.

Auf einer Website, die sich nicht für den Trial angemeldet hat, ist document.modelContext undefined, und nichts davon läuft. Chrome mit --enable-blink-features=WebMCP zu starten schaltet die API lokal ein, und so entwickelt man dagegen, bevor ein Token existiert.

Einen Unterschied zwischen Spezifikation und Umsetzung sollte man kennen, bevor er einen Nachmittag kostet. Das IDL typisiert das zweite Argument von executeTool als Objekt, und ein Objekt zu übergeben scheitert mit UnknownError: Failed to parse input arguments, was weder sagt, welches Argument gemeint ist, noch warum. Chrome will die Argumente serialisiert:

await mc.executeTool(tool, JSON.stringify({ message: "How do you measure AI referrals?" }));

getTools() antwortet auf dieselbe Weise. Das inputSchema eines zurückgegebenen Tools kommt als JSON-String an und nicht als das Objekt, das registriert wurde, alles, was es zurückliest, muss also zuerst parsen.

Auf derselben Seite liegen nützlichere Dinge

Bei der Anmeldung fängt man an, weil Endpunkt, Einwilligungsstrecke und Bestätigungsmail bereits existieren. Sie ist zugleich das kleinste Ding auf der Seite, das es wert ist, freigegeben zu werden.

Jede Interaktion, die ein Besucher von Hand erledigt, ist ein Kandidat, und die mit mehreren Schritten gewinnen am meisten, wenn sie auf einen einzigen Aufruf zusammenschrumpfen.

Nur lesende Tools sind der sicherere Anfang. readOnlyHint: true auf einem Such- oder Bestandstool sagt dem Agenten, dass der Aufruf nichts ändert, und ein Fehler kostet eine verschwendete Abfrage statt eines Datensatzes, der in Ihre Datenbank geschrieben wird.

Was hinter einer Authentifizierung liegt, bleibt hinter der Authentifizierung. Ein registriertes Tool läuft in der Seite mit der Sitzung, die der Besucher ohnehin hat, get_order_status ist also genau so geschützt wie die Kontoseite, aus der es liest, und nicht mehr.

Nichts hier ändert, wozu das Popup gebaut wurde

Ein Tool läuft erst, nachdem jemand nach etwas gefragt hat. Diese Person hat ihrem Assistenten gesagt, er solle den Rabatt holen, und der Assistent hat die Funktion gefunden, die das tut. Diese Person hätte eine Adresse über jeden Weg hergegeben, den Sie ihr anbieten.

Das Popup zielt auf die gegenteilige Person. Auf jemanden, der nichts entschieden hat und auf dem Weg nach draußen ist, gefangen von einem Timer oder von der Maus, die zum Zurück-Button wandert. Es verdient seinen Platz, indem es Leute konvertiert, die nicht konvertiert hätten, und nur deshalb akzeptiert ein Team, alle anderen zu verärgern, um sie zu bekommen.

Das Popup für Agenten-Traffic abzuschalten kostet deshalb nichts, denn diese Besucher waren nie sein Ziel. Es für alle zu löschen gibt die Adressen auf, für deren Fang es gebaut wurde, und dazu die Jahre an E-Mails, die daraus laufen.

Marketingteams werden daran gemessen, wie schnell die Liste wächst und wie viel Umsatz die Lifecycle-Mails bringen. WebMCP bewegt keine der beiden Zahlen. Es gibt einem willigen Besucher einen saubereren Weg und lässt den Grund für die Unterbrechung unangetastet.

Über den Rest entscheidet die Unterstützung. Nur Chromium, in Tests, die bei Chrome 156 enden, und mit Apple dagegen. Ein Anmeldeformular durch ein Tool zu ersetzen würde den Weg entfernen, den fast jeder Besucher nutzt, im Tausch gegen einen, der in einem Bruchteil eines einzigen Browsers funktioniert.

Vorerst ist es ein zusätzlicher Weg hinein. Das Popup löst seltener aus, je mehr Besuche über Assistenten kommen, und es verschwindet ganz an dem Tag, an dem sich das Einsammeln einer Adresse nicht mehr rechnet. Keine Spezifikation kann diesen Tag vorziehen.

Eine offene Anmeldung ist der Weg, wie Menschen in Post ersticken

Ein Anmelde-Tool nimmt eine E-Mail-Adresse entgegen, die es nicht prüfen kann, und schickt Post dorthin. Wer einen Agenten steuern kann, kann ihn auf jedes beliebige Postfach richten. Ihr Formular hat dasselbe Loch, denn hinter beiden steht eine öffentliche URL, an die ein Skript posten kann, ohne je Ihre Seite zu laden.

Der Angriff hat einen Namen. Bei einem List-Bombing-Lauf wird die Adresse eines Opfers gleichzeitig bei Hunderten oder Tausenden Websites eingetragen, je eine Anfrage pro Website. Jede Website sieht eine einzelne unauffällige Anmeldung, und nirgends sieht etwas falsch aus. Das Opfer bekommt in einer Stunde Tausende Bestätigungsmails, und die Flut ist meist Tarnung für etwas anderes, das im selben Postfach eintrifft: eine Betrugswarnung der Bank, ein Passwort-Reset, eine Quittung für einen Kauf, den jemand mit ihrer Karte getätigt hat. Auch Ihre Versandreputation nimmt Schaden, und das ist der kleinste Teil des Geschehens.

Diese Form hebelt die Abwehr aus, zu der die meisten greifen. Eine Ratenbegrenzung zählt Anfragen, und ein Lauf, der Ihnen genau eine Anfrage schickt, gibt ihr nichts zu zählen.

Vier Dinge helfen tatsächlich.

Setzen Sie eine Challenge vor die Anmeldung, damit ein automatisierter Eintrag etwas bestehen muss, das ein echter Mensch unbemerkt passiert.

Entdoppeln Sie nach Adresse und führen Sie eine Sperrliste, damit dasselbe Postfach nicht immer wieder angemeldet werden kann und eine zweite Anfrage für eine Adresse mit bereits offener Bestätigung gar nichts versendet.

Bitten Sie um eine Bestätigung, bevor Sie jemanden auf eine Liste setzen, damit ein missbrauchter Aufruf kein Abonnement erzeugen kann. Ein Vorbehalt, über den viele stolpern: Nach dem kanadischen Anti-Spam-Gesetz gilt eine Bestätigungsmail selbst als kommerzielle Nachricht, sie an eine Adresse zu schicken, die nie gefragt hat, ist also der Verstoß und nicht der Schutz. Deutsche Gerichte sind in derselben Frage geteilter Meinung. Die Bestätigung ist an den meisten Orten die richtige Voreinstellung, und universell ist sie nicht.

Halten Sie beim Schreiben der Zeile fest, woher jede Anmeldung kam. Das nach einem Vorfall zu rekonstruieren heißt zu raten, welche Adressen echt waren.

Einwilligung zu belegen ist schwerer, wenn Software geklickt hat

Ein Formularversand erzeugt einen Nachweis dessen, was der Besucher gesehen hat. Die Checkbox, das Label daneben, der Datenschutzlink und der Zeitstempel liegen alle auf Ihrer Seite.

Ein Tool-Aufruf erzeugt eine E-Mail-Adresse in einem Funktionsargument. Was dem Besucher gesagt wurde, bevor der Agent handelte, ist in einem Gespräch passiert, zu dem Sie keinen Zugang haben. Nach der DSGVO muss eine Einwilligung freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich erfolgen, und der Verantwortliche muss sie nachträglich nachweisen können. Eine Adresse, die über einen Agenten eintrifft, erfüllt davon von sich aus nichts.

Das Double-Opt-in trägt hier zum zweiten Mal den größten Teil der Last. Die Bestätigungsmail geht an die Adresse selbst, und sie zu klicken erzeugt eine zeitgestempelte Handlung des Abonnenten und nicht von etwas, das für ihn handelt. Halten Sie die über Agenten vermittelten Anmeldungen in der Speicherung unterscheidbar, damit eine Prüfung sie von Formulareinsendungen trennen kann, statt die ganze Liste als eine einzige Herkunft zu behandeln.

Diese Anmeldungen verschwinden leise, bauen Sie das Zählen also zuerst ein

Ein Agent, der ein registriertes Tool aufruft, führt einen Callback in der Seite aus. Es gibt keinen Seitenaufruf, kein Formular-Submit-Ereignis und häufig gar keine Sitzung in dem Sinn, den ein Browser-Analytics-Werkzeug meint. Die Conversion passiert und der Abonnent ist echt, während der Bericht nichts zeigt. Richten Sie das falsch ein, dann ist der Fehler stumm: Die Abonnenten steigen, keine Quelle erklärt sie, und in der Oberfläche sieht nichts kaputt aus.

Das ist dieselbe strukturelle Lücke, die KI-Crawler und KI-Referrals vor Browser-Analytics verbirgt, nur auf einer neuen Ebene. Ein Crawler führt das JavaScript nie aus, das ihn melden würde. Ein Agent führt das JavaScript aus, und zwar den Teil, der die Conversion abschließt, während er jeden Teil überspringt, der sie gemessen hätte.

Die Anfrage, die Ihren Anmelde-Endpunkt trifft, ist der einzige Ort, an dem die Conversion in einer Form existiert, die Ihnen gehört. Markieren Sie sie dort, in First-Party-Logs, und der Kanal wird zu etwas, das Sie im nächsten Quartal beziffern können.

Vier Dinge, die verhindern, dass sie verschwinden

Stempeln Sie die Quelle auf dem Server auf, im selben Schreibvorgang, der den Abonnenten anlegt. Die Seite schickt ein Quellenfeld mit der Anfrage, und der Server legt es in die Zeile neben Adresse und Zeitstempel. Das im Nachhinein aus dem Wortlaut der Nachricht abzuleiten ist Raterei, und der Referrer rettet Sie nicht, denn Agenten senden häufig gar keinen.

Melden Sie die Anmeldung vor dem Netzwerkaufruf statt im Erfolgs-Handler. Ein Aufruf, der auf halbem Weg abgebrochen wird oder der scheitert, nachdem der Server die Arbeit schon getan hat, erreicht den Erfolgszweig nie. Melden Sie ihn auf dem Weg hinaus, dann zählen Sie den Versuch, und das ist die Zahl, die Sie tatsächlich wollen.

Legen Sie das Ereignis in Ihrem Analytics-Werkzeug an, bevor Sie das Tool ausliefern. Eigene Ereignisse werden üblicherweise angenommen und dann aus jedem Bericht verworfen, solange kein Ziel mit passendem Namen existiert, ein nicht registriertes Ereignis liefert also einen Erfolgscode und taucht nirgends auf. Stille im Dashboard ist kein Beleg dafür, dass nichts ausgelöst hat, und sie ist der leichteste Weg, eine Woche mit dem Debuggen von Code zu verbringen, der die ganze Zeit funktioniert hat.

Gleichen Sie bewusst einmal pro Woche ab. Zählen Sie die Zeilen in Ihren eigenen Daten, die die Agentenquelle tragen, und vergleichen Sie das mit dem, was Ihre Analytics für dieselben Tage zeigt. Zwei Zahlen, die zueinander passen, heißen, dass die Leitung intakt ist. Eine Lücke ist die Größe Ihres blinden Flecks. Traffic auf der einen Seite und eine Null auf der anderen heißt, dass das Ereignis gar nicht ankommt, und Sie wissen das jetzt nach einer Woche statt am Ende des Quartals.

Was Sie in diesem Quartal damit tun

Ein Tool zu registrieren kostet einen Nachmittag. Fangen Sie mit dem Angebot an, für das Sie Leute ohnehin unterbrechen, denn Endpunkt, Einwilligungsstrecke und Bestätigungsmail sind gebaut und laufen.

Behalten Sie das Formular. Fast jeder Besucher wird es weiterhin nutzen, und das bleibt so, solange Apple bei seiner Position bleibt.

Nutzen Sie document.modelContext, und melden Sie sich für den Chrome-Trial an, wenn gewöhnliche Besucher das Tool erreichen sollen und nicht nur Entwickler mit gesetztem Flag.

Ergänzen Sie das Quellenfeld an Ihrem Anmelde-Endpunkt, bevor das Tool live geht. Es danach zu tun heißt, dass Sie bei den Anmeldungen, die schon in Ihrer Datenbank liegen, nicht mehr erkennen können, welche von einem Agenten kamen.

Lesen Sie die Ergebnisse von Ihrem eigenen Server ab. Eine Analytics-Property zeigt Ihnen diese Anmeldungen überhaupt nicht, und nichts darin sieht kaputt aus, während sie ungezählt bleiben.

Die Zahl, die es zu beobachten lohnt, ist keine der obigen. Es ist der Anteil Ihrer Besuche, die über einen Assistenten kommen, denn er entscheidet, wann das hier aufhört, ein Experiment zu sein, und Sie können ihn heute aus Ihren Logs messen, ob Sie je ein Tool registrieren oder nicht.