docs · pour les développeurs

Serveur MCP

Laissez un agent de codage lire votre configuration de consentement et, quand vous l’autorisez, la modifier : chaque écriture est en deux étapes, gardée par portée et atterrit dans la piste d’audit comme « via MCP ».

Mise en place

# 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 uniquement, Node 22+. Le jeton vient de COOKIECRUMBS_TOKEN ; créez-en un sous Paramètres de l’espace de travail → Développeurs avec seulement les portées que vous voulez donner à l’agent. La liste d’outils elle-même est filtrée par les portées du jeton, si bien qu’un jeton en lecture seule produit un serveur en lecture seule.

Lecture

Les outils de lecture couvrent toute la surface : list_sites, get_site, get_banner, get_compliance_status, list_scans, get_scan, get_scan_diff, list_findings, explain_classification (pourquoi un traceur a été classé là, à partir de quel scan), check_first_layer, rules_reference (la bibliothèque de citations juridiques), 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 et logs_summary. Trois ressources exposent des documents vivants : cookiecrumbs://sites/{siteId}/config, …/declaration et …/issues.

Écrire, en deux étapes

Chaque outil d’écriture est par défaut à confirm: false : l’appel rend un diff unifié (plus le lint légal quand une config de bannière est concernée) et ne change rien. Seul un nouvel appel du même outil avec confirm: true l’applique. La publication passe toujours par les mêmes barrières côté serveur que le tableau de bord, les limites d’offre répondent avec la fonctionnalité nécessaire, et chaque écriture appliquée est attribuée dans le journal d’activité comme « via MCP ». Les outils qui suppriment quelque chose le disent dans leurs annotations, pour qu’un hôte d’agent puisse demander avant de les appeler.

Tout le site, depuis un agent

Tout ce que le tableau de bord peut changer, un agent peut le changer aussi, et rien de plus :

• La bannière : update_banner (un JSON merge patch sur le brouillon), push_config (remplacer et publier), rollback_version, promote_version (prévisualisation → production, avec le diff entre les deux montré d’abord), apply_template, save_template, delete_template.
• Le site : create_site, update_site (nom, conservation des preuves de consentement, paramètres), verify_domain (affiche l’enregistrement DNS TXT ou la balise meta à publier).
• Scan : scan_site, set_scan_schedule (cadence, plafond de pages, états de consentement, URL de départ, motifs de chemin, robots, pause ; les plafonds d’offre sont signalés, jamais cachés), check_install (cc.js est-il sur la page ?).
• Traceurs et problèmes : add_service, update_service, delete_service, classify_tracker, suppress_issue (une raison est obligatoire et devient l’enregistrement), unsuppress_issue.
• Notifications et preuve : acknowledge_alert, resolve_alert, create_alert_channel / update_alert_channel / delete_alert_channel, create_webhook / update_webhook / delete_webhook (le secret de signature est renvoyé une fois), create_export_schedule / update_export_schedule / delete_export_schedule, logs_export.

Chaque outil n’est annoncé que lorsque le jeton porte sa portée (sites:write, banner:write, banner:publish, scans:run, logs:export), si bien que le jeton que vous confiez à un agent est tout le modèle de permissions. L’équipe, la facturation et la gestion des jetons restent dans le tableau de bord, à dessein.