Eingaben
Beispiel
Füge WebMCP-Markup oder Registrierungscode ein oder prüfe eine öffentliche Seite auf deklarative und imperative WebMCP-Muster.
Prüft deklarativen und imperativen WebMCP-Quelltext ohne JavaScript-Ausführung; Runtime-Tools benötigen echte Browser-Beobachtung.
Nutze es, um statischen WebMCP-Quelltext getrennt von tatsächlich beobachteten Runtime-Tools zu prüfen.
Füge WebMCP-Markup oder Registrierungscode ein oder prüfe eine öffentliche Seite auf deklarative und imperative WebMCP-Muster.
WebMCP lässt eine Seite ihre Fähigkeiten als benannte Tools anbieten, und die Metadaten sind die gesamte Schnittstelle: Ein Agent sieht Name, Beschreibung und Parameterdefinitionen — nicht deinen Quellcode und nicht deine Absichten. Vage Beschreibungen, unbenannte Parameter oder Formulierungen, die eine Mutation hinter einem harmlosen Verb verstecken, sind nicht bloß unordentlich; sie führen dazu, dass ein Agent das falsche Tool mit den falschen Argumenten im falschen Moment aufruft — während ein Mensch den Aufruf auf Basis derselben irreführenden Worte freigibt.
Dieser Validator inspiziert deklarative Formularmetadaten und statisch zuordenbare Aufrufe von document.modelContext.registerTool, ohne JavaScript oder DOM auszuwerten. Statische Quelltext-Evidenz bleibt von echter Runtime-Beobachtung getrennt: Aktive Tools werden nur gemeldet, wenn ein vom Aufrufer bereitgestellter Browser-Hook sie tatsächlich beobachtet.
Füge das kleinste Fragment ein, das die Frage reproduziert: ein Formular, ein Registrierungsblock, das Markup einer Komponente. Statische Analyse hat ohnehin keinen Ausführungskontext; umgebender Boilerplate erzeugt Rauschen statt Signal. Behebe zuerst die groben Probleme — fehlende Tool-Namen, Beschreibungen, die auf alles passen, Parameter ohne Label — denn daran scheitern Agents, bevor irgendein subtiles Problem relevant wird.
Trenne danach Fehler von Beobachtbarkeitsgrenzen. Fehlende Pflichtnamen, Beschreibungen oder Execute-Handler sind Strukturfehler; indirekte Schemas, Aliase, Object-Spreads, dynamische Registrierung und Removal-Lebenszyklen können statisch unbeweisbar sein und werden genau so ausgewiesen. Verschachtelte JSON-Schema-Konstrukte wie $ref, oneOf, anyOf, Arrays und Enums werden nicht wegen ihrer Komplexität verworfen.
Eingefügtes HTML und JavaScript bleiben im Browser und werden nie ausgeführt; auch abgerufener Quelltext wird statisch inspiziert. Kommentare und String-Literale werden maskiert, um False Positives zu vermeiden, und fremde registerTool-Methoden gelten nicht als WebMCP. Statische Inspektion beweist weder aktive Registrierung noch Aufrufverhalten. Runtime-Tools erscheinen nur nach echter Beobachtung durch einen expliziten Browser-Hook.
Nein. Eingefügter Code wird rein als Text nach Registrierungsmustern und Metadaten durchsucht. Nichts wird evaluiert, und durch das Einfügen entsteht keine Netzwerkanfrage.
Nein. Eine fehlende oder leere Pflichtbeschreibung ist strukturell relevant; Keyword-Länge oder Stil sind kein Konformitäts-Gate. Ein Hinweis auf mögliche Seiteneffekte bleibt informativ und beweist kein Runtime-Verhalten.
Labels sind der Weg, wie Menschen und Agents ein Feld ohne Raten einer Absicht zuordnen. Ein Parameter ohne Label zwingt jeden Aufrufer, die Bedeutung aus dem Variablennamen zu erschließen — und genau dieses Raten sollen Tool-Metadaten beseitigen.
Beschreibungen, die Mutationen hinter neutralen Verben verstecken — ein Löschen als Verwalten, eine Zahlung als Bestätigen. Markiert wird Wortlaut, bei dem die vorhersehbare Aktion von der tatsächlich implizierten abweicht.
Der aktuelle Vorschlag nutzt document.modelContext.registerTool. navigator.modelContext wird nur als Kompatibilitätsmuster behandelt; von beiden modelContext-Objekten abgeleitete Aliase können erkannt werden, ohne den Quelltext auszuführen.
Nein. Es ist ein statischer Preflight für Markup und erkennbare Registrierungshinweise. Laufzeitverhalten, Permission-Prompts und echte Aufrufsemantik brauchen einen Live-Agent-Test — idealerweise erst, wenn die statischen Befunde bereits sauber sind.