Cursor spricht MCP, und der CookieCrumbs-Server antwortet darin. Sobald der Server in .cursor/mcp.json steht, sieht der Agent eine Werkzeugliste, die das Dashboard spiegelt: Websites auflisten und anlegen, Scans starten und lesen, erklären, warum ein Tracker so klassifiziert wurde, die Banner-Konfiguration aktualisieren, pushen, veröffentlichen, die Einwilligungszusammenfassung lesen, Protokolle exportieren. Er sieht nur die Werkzeuge, die Ihr Token erlaubt; ein Nur-Lese-Token zeigt nie ein Schreibwerkzeug.
Interessant ist, wie Schreibvorgänge funktionieren. Jedes Werkzeug, das etwas ändert, nimmt ein confirm-Flag. Der erste Aufruf antwortet mit einem Unified Diff der Konfiguration plus Rechts-Lint (gleiche Prominenz, Kontrast, die zwei rechtlichen Links) und ändert nichts. Erst ein zweiter Aufruf mit confirm: true schreibt, und er landet als „via MCP“ mit dem Namen des Tokens im Audit-Trail. Das macht es sicher, „richte die Cookie-Einwilligung für dieses Projekt ein“ zu sagen und das Ergebnis zu lesen, statt es zu babysitten.
Was der Agent nicht kann, ist das Tag von außen in Ihre Seite zu setzen. Er reicht Ihnen das Snippet für Ihr Framework und bearbeitet, wenn Sie im Repo sind, die Datei mit Ihrer Prüfung wie jede andere Änderung. Der Installations-Check im Dashboard beweist dann, dass die Runtime vor jedem Tracker läuft, und auch dieses Ergebnis kann Cursor lesen.