Cookie Consent Audit MCP Server

Audit cookie consent

audit_cookie_consent

Read-only

Audits websites from an EU address for cookie consent behavior: consent platforms, first-layer reject controls, pre-consent and post-reject trackers, and GPC response. Returns per-domain signals.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 19, 2026

TDQS

A4.4/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools

audit_cookie_consentA