Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cookie Consent Audit MCP Server audit example.de from Germany and tell me what tracks before consent"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Mamba Labs Cookie Consent Audit actor on Apify. Send a domain or a list of domains. Each one is loaded from an EU address in fresh browser sessions, and you get back one row of consent signals per domain: the consent platform, reject on the first layer, trackers and tracking cookies before consent and after a reject, and the Global Privacy Control response.
Related MCP server: @guardbee/mcp-compliance-checker
Audit one or more websites for cookie consent behavior from an EU address. Each domain is loaded in fresh browser sessions: once before any consent click, once after clicking the reject control on the first layer of the banner, and once with Global Privacy Control on. Returns one row per domain: the consent management platform found (TCF __tcfapi, OneTrust, Cookiebot, Usercentrics, Didomi, and others), whether accept and reject controls sit on the first layer, tracking cookies and requests to known tracker hosts before consent and after the reject, Google Consent Mode denied pings, the GPC comparison and /.well-known/gpc.json, a list of signals, and the version of the fixed tracker list used. Signals for review, not legal findings. Cookie values are never returned. A run that does not succeed is returned as an error with its run ID. Read-only on the audited sites; requires an APIFY_TOKEN and consumes Apify credits per audited domain.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-cookie-consent-audit": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-cookie-consent-audit"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The audit_cookie_consent tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"Audit example.de for cookie consent from Germany and tell me what fires before consent."
"Check these five client sites from France: is there a reject button on the first layer, and does anything still track after a reject?"
audit_cookie_consent. One tool. Example arguments:
{
"domains": ["example.de", "example.fr"],
"proxy_country": "DE"
}Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| string | no | The website to audit, for example example.de or https://www.example.de/. The homepage is audited. Give domain or domains. |
| array | no | More domains or URLs to audit in the same run. Duplicates are skipped. Up to 500 per run. |
| string | no | The EU country the browser connects from: DE, FR, NL, IE, IT, ES, SE, PL, AT, BE, DK, FI, or none. Default DE. none is not an EU vantage point. |
| string | no | Also run the Global Privacy Control session and read /.well-known/gpc.json. Default true. |
| string | no | Optional. Stop the run before the audit charges would pass this amount. |
| string | no | A domain audited in the last 24 hours with the same settings comes back from cache at no charge. true audits it again. Default false. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.05 | $0.0475 | $0.045 | $0.0425 |
| $0.001 | $0.001 | $0.001 | $0.001 |
Blocked, timed out, partial, cached, and invalid rows are never charged.
The actor needs no provider key. It loads public pages through the Apify proxy and holds no key of its own.
apify.com/mambalabs/cookie-consent-audit
MIT. See LICENSE.
Audit one or more websites for cookie consent behavior from an EU address. Each domain is loaded in fresh browser sessions: once before any consent click, once after clicking the reject control on the first layer of the banner, and once with Global Privacy Control on. Returns one row per domain: the consent management platform found (TCF __tcfapi, OneTrust, Cookiebot, Usercentrics, Didomi, and others), whether accept and reject controls sit on the first layer, tracking cookies and requests to known tracker hosts before consent and after the reject, Google Consent Mode denied pings, the GPC comparison and /.well-known/gpc.json, a list of signals, and the version of the fixed tracker list used. Signals for review, not legal findings. Cookie values are never returned. A run that does not succeed is returned as an error with its run ID. Read-only on the audited sites; requires an APIFY_TOKEN and consumes Apify credits per audited domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | The website to audit, for example example.de or https://www.example.de/. The homepage is audited. Give domain or domains. | |
| domains | No | More domains or URLs to audit in the same run. Duplicates are skipped. Up to 500 per run. | |
| check_gpc | No | Load the site once more with the Global Privacy Control signal on and compare trackers with the plain visit; also reads /.well-known/gpc.json. Default true. | |
| skip_cache | No | A domain audited in the last 24 hours with the same settings is returned from cache at no charge. true audits it again. Default false. | |
| proxy_country | No | The EU country the browser connects from. Consent banners change by visitor region. none connects without a proxy, which is not an EU vantage point. Default DE. | |
| max_charge_usd | No | Optional. Stop the run before the audit charges would pass this amount. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint=false), disclosing fresh browser sessions, the three-load methodology, APIFY_TOKEN requirement, per-domain Apify credit consumption, 24-hour caching behavior, privacy guarantee that cookie values are never returned, and that failed runs surface as errors with a run ID. This is rich behavioral context an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the what and how lead, and the operational caveats (cost, token, privacy, error handling) come after. It is longer than typical, but nearly every clause carries information; a small trimming of the output enumeration would tighten it without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so thoroughly: one row per domain and a detailed field list (CMP platform, first-layer controls, pre/post-reject trackers, Consent Mode pings, GPC comparison, tracker-list version). Nothing needed to call or interpret the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters including defaults and enums; the baseline is 3. The description reinforces the GPC and reject-load behavior that underlies check_gpc, but adds no syntax, format, or meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (audit) and resource (cookie consent behavior) with precise scope: EU vantage point, three fresh-session loads per domain. An agent can tell exactly what the tool does without opening the schema, and the enumerated outputs (CMP detected, tracker requests, GPC comparison) sharpen the purpose further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong context for use (EU-address auditing, per-domain runs, cost model) and adds the important caveat 'Signals for review, not legal findings.' With no sibling tools there is nothing to route against, but it also doesn't state explicit when-not-to-use conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0audit_cookie_consentScored across 1 tool
With only a single tool in the set, there is no possibility of confusing it with another. Its purpose—auditing cookie consent behavior across domains—is stated unambiguously and covers a clear, distinct scope.
The lone tool follows a clean verb_noun snake_case convention (audit_cookie_consent). With one tool there is no opportunity for inconsistent conventions to arise.
A single tool is on the thin side for a server purpose; 3-15 is typically well-scoped. However, the tool is heavily parameterized and performs multi-domain, multi-session batch auditing, so it earns its place rather than being trivial.
The audit itself is thorough, but the surface has a notable gap: the description mentions failed runs are returned 'with its run ID', implying a way to look up or re-fetch run results, yet no such retrieval/list/status tool exists. Agents cannot query past runs or monitor async audits, creating a dead end.
Cookie consent scanner: GDPR, CCPA, GCMv2. PASS/FAIL compliance checklists with fix recommendations.
Set up GDPR and CCPA cookie consent: create a site, publish a banner, scan and categorize trackers.
Cookie consent for GDPR/CCPA: scan sites for trackers, configure consent banners, get install code.
Automated website compliance infrastructure and GDPR/CCPA auditing.
