WebMCP Updates

WebMCP Updates: Was diese Prüfung geändert hat

Diese Seite dokumentiert den von BTradeTech verwendeten WebMCP-Leitfaden mit Datum. Die aktuelle Prüfung priorisiert dokumentierte Browser-Oberflächen, trennt Implementierungsbelege von optionalen Discovery-Konventionen und behauptet keine universelle Stable-Browser-Unterstützung für Draft- oder Preview-Funktionen. Prüfdatum ist der 17. September 2026; vor Produktion bitte Quellen erneut prüfen.

Aktuelle imperative Anleitung

Die Implementierung konzentriert sich auf document.modelContext und registerTool(). Ein Tool braucht stabilen Namen, klare Beschreibung, strenges Input-Schema und einen Handler für bestehende Anwendungslogik. Feature Detection und menschlicher Fallback bleiben nötig. navigator.modelContext gilt nur als Legacy-Kompatibilitätssignal.

Deklarative Formulare separat behandeln

Der dokumentierte deklarative Weg nutzt Formularattribute wie toolname, tooldescription und Parameterbeschreibungen. Labels, Pflichtfelder, Consent, Nonces, Autorisierung und serverseitige Validierung bleiben bestehen. Testen Sie den aktiven Framework-, Theme-, Plugin- und Caching-Stack.

Sicherheit und Bestätigung

Read-only-Suche, Produkt-Lookup, Support-Wissen und Rechnungsanzeige sind mögliche erste Kandidaten, sofern Autorisierung stimmt. Angebot, Warenkorb, Buchung, MFA-Reset, Checkout, Zahlung und Bestellung brauchen klare Grenzen. Vor dem Commit werden Konsequenz und Werte gezeigt und ein Mensch bestätigt. Annotationen ersetzen keine serverseitigen Kontrollen.

Was die BTradeTech-Werkzeuge melden

Der Checker meldet statische Belege aus HTML und gleich-origin Scripts. Autopilot entdeckt und priorisiert Aktionen. Der Simulator ordnet Aufgaben erkannten oder vorgeschlagenen Aktionen zu. Der Generator erzeugt ein Skelett und der Validator erklärt Fehler. llms.txt, Manifeste und schema.org sind keine offiziellen Anforderungen.

Browser-Verifizierungsstatus

Statischer Quelltext beweist keine Registrierung nach Hydration, erfolgreiche Ausführung, Berechtigung oder sichere Bestätigung. Deshalb steht Runtime in dieser Bereitstellung auf NICHT AUSGEFÜHRT, solange kein kontrollierter Browser konfiguriert ist. Die Browser-Support-Seite trennt Dokumentation, Framework-Hinweise und Vermutungen.

Künftige Änderungen sauber behandeln

Dokumentieren Sie Quellen, Prüfdatum, API, Browser-Kanal, Testseite, Tool-Namen und Bestätigung im Ticket. Nach Dependency- oder Theme-Änderungen statisch erneut prüfen und kontrollierte Browser-Tests für Read-only, Fehler, Navigation-Cleanup und Folgen-Aktionen durchführen. Der Implementierungsservice unterstützt den Rollout.

FAQ

Macht ein neuer Browser-Hinweis eine Website automatisch bereit? Nein. Implementiert llms.txt WebMCP? Nein. Beweist ein Score eine erfolgreiche Aufgabe? Nein. Verwenden Sie die Statusbegriffe vorhanden/erkannt, vorgeschlagen, Runtime verifiziert und nicht ausgeführt.

Release-Checkliste bei API-Änderungen

Wenn sich Browser-Preview, Dokumentation oder ein Framework-Adapter ändert, vergleichen Sie das Verhalten mit einem kleinen schriftlichen Vertrag. Prüfen Sie Registrierung, doppelte Namen, ungültige Eingaben, Navigation-Cleanup, Ergebnisdarstellung und den normalen menschlichen Fallback. Notieren Sie Prüfdatum und Browser-Kanal neben der Quelle. So erklärt ein Update, was geändert und getestet wurde und was weiterhin nicht behauptet werden darf. Neue Syntax wird zuerst mit harmlosen Read-only-Daten auf einer Nicht-Produktivseite getestet; Zugangsdaten gehören nicht in Client-Code.

Den Cluster aktuell halten

Nutzen Sie nach Code- oder Dependency-Änderungen den Validator, prüfen Sie die Browser-Support-Referenz erneut und holen Sie bei folgenreichen Workflows eine Umsetzungsprüfung ein. Bewahren Sie alte Ergebnisse als historische Notiz auf, aber kennzeichnen Sie sie klar, damit ein früherer Stand nicht als aktuelle Browser-Unterstützung missverstanden wird.