Ein Browseragent sieht einen Knopf und schätzt dessen Position. Das kann funktionieren. Eine Webanwendung kann ihre Bedeutung aber auch ausdrücklicher mitteilen: Diese Aktion sucht freie Termine, sie erwartet ein Datum und liefert eine Liste zurück. Genau diese Verschiebung von der Klickposition zum beschriebenen Werkzeug macht WebMCP interessant.
WebMCP ist zum dokumentierten Stand ein experimenteller Vorschlag. Der aktuelle Explainer behandelt imperative Registrierung über JavaScript und document.modelContext. Deklarative HTML-Formularwerkzeuge werden separat untersucht und gehören derzeit nicht zu dieser Spezifikation. Die Chrome-Grundlagenseite vom 18. Mai 2026 ist deshalb kein Anlass, eine neue universelle Oktober-Browserfunktion zu behaupten.
Ein Werkzeug beginnt mit einer begrenzten Handlung
Unser eigenes Beispiel heißt „freie Termine suchen“. Seine Aufgabe endet bei Informationen. Es legt keine Reservierung an. Das sollte schon die Beschreibung erkennen lassen, damit ein Agent nicht aus einem Suchergebnis einen bestätigten Termin macht.
Die Eingabe enthält ein Datum und eine angebotene Leistung. Das Ergebnis nennt denselben Bezug zusammen mit den freien Zeitfenstern. Ein isolierter Wert wie „10:30“ wäre schwächer: Er könnte zu einem anderen Tag oder Angebot gehören. Ein strukturiertes Ergebnis ist vor allem dann hilfreich, wenn seine Einträge eindeutig interpretierbar sind.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Das ist unser Lehrschema, keine kopierfertige WebMCP-Registrierung. Das zukünftige Datum und die Leistung sind erfunden. Es zeigt den Vertrag, den eine tatsächliche Implementierung präzisieren müsste. Für konkrete API-Syntax ist die jeweils aktuelle experimentelle Dokumentation maßgeblich.
Auch Fehler brauchen eine verständliche Bedeutung
Ein ungültiges Datum, keine freien Termine und ein technisch nicht erreichbarer Dienst sind drei unterschiedliche Ergebnisse. Wenn alle nur eine leere Liste erzeugen, müsste der Agent die Ursache erraten. Die Werkzeugantwort sollte deshalb einen verständlichen Zustand und die für die nächste Entscheidung benötigten Angaben tragen.
Das gilt auch für teilweise Informationen. Ist die Suche abgeschlossen oder fehlen noch Daten? Gehört die Antwort zur letzten Anfrage? Hat die Person das Datum inzwischen geändert? Solche Fragen bestehen unabhängig davon, ob die Oberfläche als Screenshot oder über ein Werkzeug angesprochen wird.
Beschreibung ist keine Berechtigung
Ein korrektes Eingabeschema sagt, welche Form eine Anfrage haben soll. Es entscheidet nicht, ob der Aufrufer diese Information lesen darf. Die Anwendung muss ihre eigenen Regeln weiterhin durchsetzen. Ein wohlklingender Werkzeugname ist weder Anmeldung noch Zugriffskontrolle.
Auch der Übergang zur Buchung braucht eine eigene Bedeutung. „Suche nach freien Zeiten“ und „reserviere diese Zeit für mich“ haben unterschiedliche Folgen. Sie sollten nicht unbemerkt in einer einzigen Funktion zusammenfallen. Eine tatsächliche Reservierung müsste den bestätigten Gegenstand und den vorgesehenen Auftrag berücksichtigen.
Für eine erste ungefährliche Entwurfsübung reichen daher feste Beispieldaten. Beschreibe drei Antwortzustände und verfolge, welche nächste Handlung daraus jeweils vernünftig wäre. Damit prüfst du die Verständlichkeit des Vertrags, ohne eine echte Buchung oder eine vorhandene WebMCP-Laufzeit vorzutäuschen.
WebMCP ist nicht automatisch ein vorhandener Remote-MCP-Server
Das Wort MCP taucht in verschiedenen technischen Zusammenhängen auf. Eine browserseitig beschriebene Aktion ist nicht allein deshalb dieselbe Anbindung wie ein entfernter, per HTTP erreichbarer Werkzeugserver. Für eine konkrete Verbindung zählen Client, Transport, Anmeldung und tatsächlich angebotene Werkzeuge.
Ein vorhandener Remote-MCP-Zugang beweist daher keine WebMCP-Unterstützung einer Website. Ebenso garantiert ein experimenteller Browservorschlag nicht, dass jeder Agent ihn bereits verwenden kann. Diese Unterscheidung ist praktisch: Sie verhindert, dass aus einer ähnlichen Bezeichnung ein falscher Integrationsplan entsteht.
Die übertragbare Frage bleibt klar. Kann eine Anwendung ausdrücken, welche Handlung mit welchen Eingaben welches Ergebnis und welche Wirkung hat? Je genauer diese Antwort ausfällt, desto weniger muss ein Agent aus einer Bildschirmposition erraten. Gute Werkzeugverträge machen den Spielraum verständlicher; die Regeln der Anwendung bleiben trotzdem ihre eigene Aufgabe.
Quellen und Stand
Recherche- und Dokumentationsstand: 25. Oktober 2026. WebMCP · WebMCP explainer.
