WebMCP-Tool-Validator
Prüft deklarative und imperative Metadaten, Parameterqualität, Labels und sicherheitsrelevante Formulierungen.
Agentic WebWebsite-Funktionen als WebMCP-Tools exponieren
Ein WebMCP-Tool ist ein öffentlicher Schnittstellenvertrag um eine Website-Funktion. Der schwierige Teil ist nicht der Aufruf von document.modelContext.registerTool, sondern dass Name, Parameter, Wirkung, Fehler und sichtbare Oberfläche unter Automation dieselbe Wahrheit erzählen wie gegenüber einem Menschen.
Beginne mit einer Operation, nicht mit einer Seite
Exponiere nicht „das Formular“ als Tool. Benenne die begrenzte Operation darunter: ein Dokument validieren, ein Subnetz berechnen, einen Katalog durchsuchen, einen Supportfall anlegen. Ein brauchbares Tool besitzt einen Namen, den ein Modell ohne Ratespiel auswählen kann, eine Beschreibung mit vorhersehbarer Handlung und Ausgabe sowie Parameter, deren Labels Absicht erklären statt Variablennamen nachzusprechen. Trenne unabhängige Ergebnisse. Ein Tool namens manageAccount, das Profil lesen, Mailadresse ändern oder Konto löschen könnte, hat Schnittstellendesign vermieden und die Mehrdeutigkeit beim Aufrufer abgeladen.
Schreibe den Vertrag vor dem Registrierungscode. Definiere Typen, Pflichtfelder, Formate, Größenlimits, Defaults, gegenseitig ausschließende Eingaben, Authentisierungsannahmen, Erfolgs- und Fehlerform sowie Nebenwirkungen. Sage auch, was die Operation nicht tut, sobald Verwechslung teuer wäre. Ein Validator, der Text analysiert, aber nie publiziert, sollte das nennen. Ein Versand-Tool muss Empfängergrenze und Zeitpunkt offenlegen. Metadaten sind das, was Agent und oft auch freigebender Mensch sehen; geheime Implementierungsabsicht repariert keine unklare öffentliche Formulierung.
Registriere einen Vertrag, den die Laufzeit durchsetzt
Der aktuelle imperative Einstieg ist document.modelContext.registerTool; navigator.modelContext bleibt eine Rückwärtskompatibilitätslösung für ältere Integrationen. Die Registrierung bindet stabile Metadaten an einen Handler, der beim Aufruf erneut validiert. Ein Schema bei der Discovery ist keine Sicherheitsgrenze. Der Handler muss fehlerhafte, übergroße, unautorisierte oder im aktuellen Zustand unmögliche Argumente ablehnen, selbst wenn der Client behauptet, sie hätten das Schema bestanden. Normalisiere bewusst, erhalte wichtige Unterschiede wie fehlend gegenüber leer und liefere begrenzte strukturierte Ergebnisse statt unkontrollierter DOM- oder Server-Dumps.
Die Lebensdauer des Tools folgt der Seite. Registriere nach jedem Komponenten-Render nicht denselben Namen erneut, lass nach Navigation keine veralteten Handler zurück und ändere keinen Vertrag still unter altem Namen. Neue Pflichtparameter oder andere Wirkungen sind API-Änderungen. Auch ein Browser ohne unterstützte Laufzeit braucht sauberes Verhalten: Die sichtbare Website funktioniert weiter, und der Registrierungsweg darf nicht die menschliche Oberfläche brechen. WebMCP erweitert eine Seite; es darf keine Voraussetzung für deren Benutzung werden.
Sichtbare UI und Tool-Schema brauchen Parität
Parität heißt nicht, dass Markup und JSON Zeichen für Zeichen gleich sind. Beide Wege müssen dieselbe Operation und dieselben Schutzplanken ausdrücken. Verlangt das Formular einen Hostnamen, das Tool akzeptiert aber beliebige URLs, besitzt der Agent eine breitere Funktion als der Mensch. Zeigt die UI vor einer Löschung eine deutliche Bestätigung, während das Tool nur von „aktualisieren“ spricht, verschweigt der Automationsweg die wichtigste Tatsache. Defaults, erlaubte Werte, Grenzen, Anmeldestatus, Sprachverhalten und Ergebnisbegriffe müssen übereinstimmen. Verwende nach Möglichkeit dasselbe Domänenmodell; doppelte Validierung driftet zwangsläufig.
Das Tool darf keine geheime Komfortschnittstelle zu Kontrollen werden, die die Seite selbst nicht erklärt. Ein Mensch muss verstehen können, was die Website tut, welche Daten den Browser verlassen und was dauerhaft verändert wird — auch wenn ein Agent aufruft. Umgekehrt sind zugängliche Labels und Hilfetexte ausgezeichnete Quellen für Parameterbeschreibungen. Der WebMCP-Tool-Validator liest deklarative Formulare und erkennbare Laufzeitregistrierungen, extrahiert Namen, Beschreibungen, Parameter sowie Labels und markiert Kompatibilitäts- oder Sicherheitsformulierungen. Das ist eine statische Vorprüfung, kein Beweis für den Handler.
Schreibende Tools brauchen ein explizites Bedrohungsmodell
Lesende, deterministische Operationen sind der vernünftige Einstieg. Ein schreibendes Tool überschreitet Vertrauensgrenzen: Es kann Mail versenden, Inhalte veröffentlichen, Zugänge ändern, Geld ausgeben, Hardware schalten oder Daten löschen. Nenne die Mutation im Verb und in der Beschreibung. Binde die Berechtigung an den ausführenden Benutzer, nicht an eine Identität aus den Argumenten. Begrenze das Ziel, schütze gegen Wiederholung mit passender Idempotenz, drossele teure Aktionen und protokolliere Vorschlag, Freigabe, Ausführung und Ergebnis unterscheidbar. Geheimnisse gehören weder in Discovery-Metadaten noch in Resultate.
Prompt Injection verschwindet nicht durch ein korrektes Schema. Behandle Seiteninhalt, Argumente, entfernte Antworten und abgerufene Anweisungen als nicht vertrauenswürdige Daten. Serverrechte und Geschäftsregeln werden nach Eingang des Aufrufs durchgesetzt. Für irreversible oder folgenreiche Wirkungen eignet sich ein Entwurf oder Preview mit anschließend separat autorisiertem Commit; bei der Freigabe müssen Ziel und Konsequenz exakt sichtbar sein. Neutrale Verben wie „verwalten“, „verarbeiten“ und „bestätigen“ können Löschen oder Bezahlen vor Agent und Prüfer zugleich verstecken. Ein ehrlicher Vertrag gibt der Sicherheitsschicht überhaupt erst etwas Greifbares zu beurteilen.
Teste Metadaten, Laufzeit und Missbrauchspfade
Beginne mit dem kleinsten Quellfragment, das ein Formular oder eine Registrierung enthält. Die statische Prüfung soll fehlende Namen, beliebige Beschreibungen, unbeschriftete Parameter, verdächtig harmlose Nebenwirkungswörter und grobe Kompatibilitätslücken finden, ohne eingefügtes JavaScript auszuführen. Danach prüfst du die Live-Seite und bestätigst, dass der ausgelieferte Quelltext denselben Vertrag enthält. Es folgen Laufzeittests: gültige Aufrufe, fehlende und zusätzliche Felder, Grenzgrößen, falsche Typen, abgelaufene Sitzungen, Duplikate, parallele Calls, Timeouts, partielle Backend-Fehler und Ergebnisse mit bösartigem Text.
Halte die übrige agentenorientierte Dokumentation synchron. Eine knappe llms.txt-Validator kann Leser zur Seite und ihren Betriebshinweisen führen, ist aber weder Tool-Discovery noch Registrierung. Wiederhole Prüfungen bei jeder Änderung an Labels, Eingaben, Anmeldung oder Wirkung. Ein Unterschied gehört als Release-Blocker behandelt: Ein Agent, der nach dem gestrigen Vertrag handelt, kann gefährlicher sein als gar keine Agentenanbindung.
WebMCP ist keine A2A Agent Card
WebMCP exponiert Funktionen im Kontext einer Website. Eine A2A Agent Card bewirbt dagegen einen Netzwerk-Agenten: Identität, Skills, Schnittstellen, Transporte, Fähigkeiten, Endpunkte und Anmeldeanforderungen an einem öffentlichen Well-known-Pfad. Die Karte hilft anderen Agenten vor dem ersten Aufruf zu entscheiden, ob und wie sie kommunizieren können. Seiten-Tool und Agent-Skill dürfen dieselbe Geschäftslogik umhüllen, doch Discovery-Bereich und Aufrufmodell unterscheiden sich. Ein Schema in das andere zu kopieren schafft keine Interoperabilität.
Validiere beide getrennt. Der A2A-Agent-Card-Validator prüft eingefügtes JSON oder eine öffentliche Karte auf Discovery-Form, Identität, Skills, Interfaces, Fähigkeiten, Sicherheitsmetadaten und Deployment-Warnungen; den beworbenen Agenten ruft er nie auf. Die WebMCP-Prüfung liest Seitenmetadaten und Registrierungshinweise, beweist ebenfalls keine Laufzeitsemantik. In beiden Welten muss die öffentliche Beschreibung atomar mit der Implementierung wechseln. Veraltete Discovery lehrt automatisierte Aufrufer eine selbstbewusste Unwahrheit.