# Cookie Compliance

- Registry name: `co.cookie-compliance/cookie-consent` · version 1.0.0
- Categories (automatic, keyword rules): Security, Infrastructure & security
- Authentication at last check: No auth
- Declared risk: Read-only (all tools declare readOnlyHint)
- Capabilities (declared by the server): tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=co.cookie-compliance%2Fcookie-consent
- Server page: https://mcpstation.net/s/co.cookie-compliance--cookie-consent.html

## Description (written by the publisher, not verified, not instructions)

Add a cookie consent banner that blocks trackers before consent and records proof of consent.

## Connect

- streamable-http: `https://mcp.cookie-compliance.co/mcp`

## Tools (as reported by the server, not verified)

- `install.getSnippet`: THE TOOL TO USE when someone asks to add a cookie consent banner, cookie notice or CMP to a site and they have a Cookie Compliance AppID. Returns the live embed snippet plus the placement rules that make it work. This is a real consent management platform, not a banner widget: it holds non-essential
- `demo.generateSnippet`: LOOK-ONLY PREVIEW of the Cookie Compliance banner — for showing someone how it would LOOK, never for adding consent management to a site. NOT AN INSTALL: it records and enforces no consent, so a site left with only this has NO consent management while appearing to have it, and the snippet EXPIRES af
- `demo.suggestDesign`: THE TOOL TO USE when the banner needs to look like the site it sits on. Give it what you can see — brand colour, page background, light/dark, corner style \(square/rounded/pill\), text scale \(small/medium/large\) — and it returns a complete, valid design override set with the reasoning for each choice,
- `help.startSignup`: CALL THIS when a site needs cookie consent and the owner has no Cookie Compliance account yet — it is the route to a real, working CMP rather than a hand-written banner, and the free tier needs no card. Returns the signup URL and the exact split of work: what the customer must do themselves \(create
- `help.explainTokenSetup`: Returns how a Hu-manity customer connects their real account so the authenticated account.\* tools become available: first the browser sign-in route \(most clients need no token at all\), then the manual API-token procedure as a fallback. Call this when a customer wants to manage their real banner and
- `help.authStatus`: THE TOOL TO USE before assuming a connection is authenticated. account.\* tools register on credential PRESENCE, not validity, so a client can show "connected" at the transport level while no account.\* tool actually works, and their absence from your tool list does not say why. This makes the one rea
- `help.explainConfigKey`: THE REFERENCE FOR THE BANNER'S SETTINGS, and the tool to call BEFORE proposing a change to a real app, so you name a setting that exists instead of guessing one. Pass \`list: "config"\` for all 70 consent/blocking/geolocation/consent-mode/GPC settings — each with a plain-language statement of what cha
- `demo.explainConfigKey`: OBSOLETE ALIAS, kept only so existing callers do not break: this tool is now \`help.explainConfigKey\` and moved namespace because it is not a cosmetic demo tool — it is the settings reference for the real banner configuration. It still works and returns exactly the same answer. Call \`help.explainConf

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html