Docs · für Entwickler

MCP-Server

Lassen Sie einen Coding-Agenten Ihre Consent-Einrichtung lesen und, wenn Sie es erlauben, ändern: Jeder Schreibvorgang ist zweistufig, per Scope abgesichert und landet als „via MCP“ im Audit-Trail.

Einrichtung

# Claude Code
claude mcp add cookiecrumbs -- npx -y @cookiecrumbs-eu/mcp
// .cursor/mcp.json (Cursor, or any stdio MCP client)
{
  "mcpServers": {
    "cookiecrumbs": {
      "command": "npx",
      "args": ["-y", "@cookiecrumbs-eu/mcp"],
      "env": { "COOKIECRUMBS_TOKEN": "cc_live_…" }
    }
  }
}

Nur stdio, Node 22+. Das Token kommt aus COOKIECRUMBS_TOKEN; erstellen Sie eines unter Workspace-Einstellungen → Entwickler mit nur den Scopes, die der Agent haben soll. Die Werkzeugliste selbst wird nach den Scopes des Tokens gefiltert, sodass ein Nur-Lese-Token einen Nur-Lese-Server ergibt.

Lesen

Lesewerkzeuge decken die ganze Oberfläche ab: list_sites, get_site, get_banner, get_compliance_status, list_scans, get_scan, get_scan_diff, list_findings, explain_classification (warum ein Tracker wo einsortiert wurde, aus welchem Scan), check_first_layer, rules_reference (die Bibliothek der Rechtszitate), get_declaration, list_versions, list_services, get_scan_schedule, get_install_status, list_domains, list_alerts, list_alert_channels, list_webhooks, list_templates, get_template, get_usage, list_export_schedules, list_export_destinations und logs_summary. Drei Ressourcen stellen Live-Dokumente bereit: cookiecrumbs://sites/{siteId}/config, …/declaration und …/issues.

Schreiben, in zwei Schritten

Jedes Schreibwerkzeug hat standardmäßig confirm: false: Der Aufruf rendert ein Unified Diff (plus Rechts-Lint, wo eine Banner-Konfiguration beteiligt ist) und ändert nichts. Erst der erneute Aufruf desselben Werkzeugs mit confirm: true wendet es an. Das Veröffentlichen durchläuft weiterhin dieselben serverseitigen Schranken wie das Dashboard, Tarifgrenzen antworten mit dem benötigten Feature, und jeder angewandte Schreibvorgang wird im Aktivitätsprotokoll als „via MCP“ zugeordnet. Werkzeuge, die etwas löschen, sagen das in ihren Annotationen, damit ein Agenten-Host vor dem Aufruf nachfragen kann.

Die ganze Website, aus einem Agenten

Alles, was das Dashboard ändern kann, kann auch ein Agent ändern, und nichts mehr:

  • Das Banner: update_banner (ein JSON Merge Patch auf den Entwurf), push_config (ersetzen und veröffentlichen), rollback_version, promote_version (Preview → Produktion, mit vorher gezeigtem Diff zwischen beiden), apply_template, save_template, delete_template.
  • Die Website: create_site, update_site (Name, Aufbewahrung der Einwilligungsdatensätze, Einstellungen), verify_domain (gibt den DNS-TXT-Eintrag oder das Meta-Tag zum Veröffentlichen aus).
  • Scannen: scan_site, set_scan_schedule (Rhythmus, Seitenlimit, Einwilligungszustände, Start-URLs, Pfadmuster, robots, Pause; Tarifgrenzen werden gemeldet, nie versteckt), check_install (ist cc.js auf der Seite?).
  • Tracker und Probleme: add_service, update_service, delete_service, classify_tracker, suppress_issue (eine Begründung ist Pflicht und wird zum Eintrag), unsuppress_issue.
  • Benachrichtigungen und Nachweis: acknowledge_alert, resolve_alert, create_alert_channel / update_alert_channel / delete_alert_channel, create_webhook / update_webhook / delete_webhook (das Signiergeheimnis wird einmal zurückgegeben), create_export_schedule / update_export_schedule / delete_export_schedule, logs_export.

Jedes Werkzeug wird nur angeboten, wenn das Token seinen Scope trägt (sites:write, banner:write, banner:publish, scans:run, logs:export), sodass das Token, das Sie einem Agenten geben, das gesamte Berechtigungsmodell ist. Team, Abrechnung und Token-Verwaltung bleiben absichtlich im Dashboard.