dokumentacja · dla deweloperów

Serwer MCP

Pozwól agentowi kodującemu czytać Twoją konfigurację zgód i, gdy na to pozwolisz, ją zmieniać: każdy zapis jest dwuetapowy, ograniczony zakresem i trafia do ścieżki audytu jako „przez MCP”.

Konfiguracja

# 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_…" }
    }
  }
}

Tylko stdio, Node 22+. Token pochodzi z COOKIECRUMBS_TOKEN; utwórz go w Ustawienia workspace’u → Deweloperzy tylko z zakresami, które ma mieć agent. Sama lista narzędzi jest filtrowana zakresami tokenu, więc token tylko do odczytu daje serwer tylko do odczytu.

Odczyt

Narzędzia odczytu pokrywają całą powierzchnię: list_sites, get_site, get_banner, get_compliance_status, list_scans, get_scan, get_scan_diff, list_findings, explain_classification (dlaczego tracker został przypisany tam, gdzie został, z którego skanu), check_first_layer, rules_reference (biblioteka cytatów prawnych), 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 i logs_summary. Trzy zasoby udostępniają żywe dokumenty: cookiecrumbs://sites/{siteId}/config, …/declaration i …/issues.

Zapis w dwóch krokach

Każde narzędzie zapisu domyślnie ma confirm: false: wywołanie renderuje ujednolicony diff (plus lint prawny, gdy w grę wchodzi konfiguracja banera) i nic nie zmienia. Dopiero ponowne wywołanie tego samego narzędzia z confirm: true je stosuje. Publikacja nadal przechodzi przez te same bramki serwerowe co panel, limity planu odpowiadają funkcją, której potrzebują, a każdy zastosowany zapis jest przypisywany w dzienniku aktywności jako „przez MCP”. Narzędzia, które coś usuwają, mówią o tym w adnotacjach, żeby host agenta mógł zapytać przed ich wywołaniem.

Cała strona z poziomu agenta

Wszystko, co może zmienić panel, może zmienić też agent, i nic więcej:

  • Baner: update_banner (JSON merge patch na szkic), push_config (zastąp i opublikuj), rollback_version, promote_version (podgląd → produkcja, z diffem między nimi pokazanym najpierw), apply_template, save_template, delete_template.
  • Strona: create_site, update_site (nazwa, retencja rekordów zgód, ustawienia), verify_domain (wypisuje rekord DNS TXT lub tag meta do opublikowania).
  • Skanowanie: scan_site, set_scan_schedule (częstotliwość, limit stron, stany zgody, adresy startowe, wzorce ścieżek, robots, pauza; limity planu są raportowane, nigdy ukrywane), check_install (czy cc.js jest na stronie?).
  • Trackery i problemy: add_service, update_service, delete_service, classify_tracker, suppress_issue (powód jest wymagany i staje się wpisem), unsuppress_issue.
  • Powiadomienia i dowód: acknowledge_alert, resolve_alert, create_alert_channel / update_alert_channel / delete_alert_channel, create_webhook / update_webhook / delete_webhook (sekret podpisu jest zwracany raz), create_export_schedule / update_export_schedule / delete_export_schedule, logs_export.

Każde narzędzie jest ogłaszane tylko wtedy, gdy token ma jego zakres (sites:write, banner:write, banner:publish, scans:run, logs:export), więc token, który dajesz agentowi, jest całym modelem uprawnień. Zespół, rozliczenia i zarządzanie tokenami celowo zostają w panelu.