Cookie consent from Cursor,
with a diff you review

Cursor can write the app, but it cannot make it compliant without tools, and a cosmetic banner it invents on its own does not block anything.

The rule is the same everywhere in the EU and the UK: nothing beyond what is strictly necessary may be stored on or read from a visitor’s device before they have agreed. That is Article 5(3) of the ePrivacy Directive, and the agreement has to meet the GDPR’s definition of consent: freely given, specific, informed and unambiguous, with a refusal that is as easy as the acceptance. The UK keeps the same rule in PECR, with narrow exemptions for low-risk statistics since 5 February 2026. California and the other US state laws work the other way round: no opt-in, but an opt-out link and support for the Global Privacy Control signal.

Three things follow for a website. Analytics, advertising and social scripts have to wait for a choice. The choice has to be recorded in a way you can show later, because Article 7(1) puts the burden of proof on you. And withdrawing has to be as easy as agreeing, which means a control that reopens the banner on every page. A banner that shows two buttons and loads Google Analytics anyway fails the first test, and that is the failure regulators have been fining, from the CNIL’s decisions against Google and SHEIN to the Dutch and Belgian authorities’ sweeps.

Cursor speaks MCP, and the CookieCrumbs server speaks it back. Once the server is in .cursor/mcp.json, the agent sees a tool list that mirrors the dashboard: list and create sites, start and read scans, explain why a tracker was classified the way it was, update the banner config, push it, publish, read the consent summary, export logs. It sees only the tools your token allows; a read-only token never shows a write tool.

The interesting part is how writes work. Every tool that changes something takes a confirm flag. The first call answers with a unified diff of the config plus the legal lint (equal prominence, contrast, the two legal links) and changes nothing. Only a second call with confirm: true writes, and it lands in the audit trail as “via MCP” with the token’s name. That is what makes it safe to say “set up cookie consent for this project” and read the result instead of babysitting it.

What the agent cannot do is put the tag into your page from the outside. It hands you the snippet for your framework and, if you are in the repo, edits the file with your review like any other change. The install check in the dashboard then proves the runtime runs before any tracker, and Cursor can read that result too.

Ask the agent to enable advanced Consent Mode and it sets the flag in the config; the runtime does the rest before any Google tag loads.

Google Consent Mode v2 is the signalling layer between the banner and Google’s tags. Before any tag runs, seven signals (ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage, security_storage) are set to denied for visitors in the EEA, the UK and Switzerland. The moment someone chooses, the runtime updates them and Google’s tags adjust. Since 15 June 2026, Google uses ad_storage as the controlling signal for Ads data, so getting the default right matters more than it used to.

CookieCrumbs sets the defaults synchronously, ahead of any tag manager, updates them on every decision, and ships a Google Tag Manager template so the consent triggers exist without hand-written listeners. In advanced mode, Google’s cookieless pings keep modelled conversions working for the visitors who said no. What it does not do is pretend to be a Google-certified CMP: for AdSense, Ad Manager or AdMob in the EEA you still need one with IAB TCF, and CookieCrumbs is not that today.