docs · for developers

MCP server

Let a coding agent read your consent setup and, when you allow it, change it: every write is two-step, scope-gated and lands in the audit trail as "via MCP".

Set-up

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

stdio only, Node 22+. The token comes from COOKIECRUMBS_TOKEN; create one under Workspace settings → Developers with only the scopes you want the agent to have. The tool list itself is filtered by the token's scopes, so a read-only token produces a read-only server.

Reading

Read tools cover the whole surface: list_sites, get_site, get_banner, get_compliance_status, list_scans, get_scan, get_scan_diff, list_findings, explain_classification (why a tracker was filed where it was, from which scan), check_first_layer, rules_reference (the legal citation library), 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 and logs_summary. Three resources expose live documents: cookiecrumbs://sites/{siteId}/config, …/declaration and …/issues.

Writing, in two steps

Every write tool defaults to confirm: false: the call renders a unified diff (plus the legal lint where a banner config is involved) and changes nothing. Only calling the same tool again with confirm: true applies it. Publishing still passes the same server-side gates as the dashboard, plan limits answer with the feature they need, and every applied write is attributed in the activity log as "via MCP". Tools that delete something say so in their annotations, so an agent host can ask before calling them.

The whole site, from an agent

Everything the dashboard can change, an agent can change too, and nothing more:

• The banner: update_banner (a JSON merge patch onto the draft), push_config (replace and publish), rollback_version, promote_version (preview → production, with the diff between the two shown first), apply_template, save_template, delete_template.
• The site: create_site, update_site (name, consent-record retention, settings), verify_domain (prints the DNS TXT record or meta tag to publish).
• Scanning: scan_site, set_scan_schedule (cadence, page cap, consent states, start URLs, path patterns, robots, pause; plan caps are reported, never hidden), check_install (is cc.js on the page?).
• Trackers and issues: add_service, update_service, delete_service, classify_tracker, suppress_issue (a reason is required and becomes the record), unsuppress_issue.
• Notifications and proof: acknowledge_alert, resolve_alert, create_alert_channel / update_alert_channel / delete_alert_channel, create_webhook / update_webhook / delete_webhook (the signing secret is returned once), create_export_schedule / update_export_schedule / delete_export_schedule, logs_export.

Each tool is advertised only when the token carries its scope (sites:write, banner:write, banner:publish, scans:run, logs:export), so the token you hand an agent is the whole permission model. Team, billing and token management stay in the dashboard on purpose.