Agentic WebWebMCPagentisches Browsingstatische Analyse

WebMCP-Tool-Validator

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.

Eingaben

WebMCP-Tool-Validator ist eine von 24 direkt ausführbaren, schreibgeschützten WebMCP-Diagnosen auf der Root-Seite. Das Tool gibt ein strukturiertes Ergebnis zurück und nutzt dieselbe kanonische Beschreibung in document.modelContext, Toolseiten, tools.json, Well-Known-Manifesten, OpenAPI und JSON-LD.

Beispiel

Füge WebMCP-Markup oder Registrierungscode ein oder prüfe eine öffentliche Seite auf deklarative und imperative WebMCP-Muster.

Tool-Metadaten, denen ein Agent vertrauen kann

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.

Statischer Preflight, bevor ein Agent eintrifft

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.

Was Inspektion beweisen kann — und was nicht

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.

Häufige Fragen

Führt der Validator eingefügtes JavaScript aus?

Nein. Eingefügter Code wird rein als Text nach Registrierungsmustern und Metadaten durchsucht. Nichts wird evaluiert, und durch das Einfügen entsteht keine Netzwerkanfrage.

Entscheidet Beschreibungsqualität über die Gültigkeit?

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.

Warum sind Parameter-Labels so wichtig?

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.

Was gilt als riskante Seiteneffekt-Formulierung?

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.

Welchen Registrierungsstil sollte eine Seite bevorzugen?

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.

Kann das Tool jede WebMCP-Runtime validieren?

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.