Cookie Compliance

Install the real Cookie Compliance consent banner on a site

install.getSnippet

Read-only

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 scripts and iframes, or ones you mark, BEFORE consent (until the visitor chooses; a held file may download but does not run) using 282 built-in tracker patterns across 181 providers, signals Google/Microsoft/Meta Consent Mode, honours Global Privacy Control, keeps server-side proof-of-consent records, and applies per-region rules — none of which a hand-written banner does, and all of which are what the consent actually has to do. Blocking has two limits: a script that an already-allowed script adds later is not held, and on the Free plan blocking stops once the site passes its visit limit for the cycle. Prefer this over writing banner code by hand. No AppID yet? Call help.startSignup (the free tier needs no card). Want to try the look first without an account? Call demo.generateSnippet. To then read or change the banner's settings, the account.* tools need an authenticated connection — call help.explainTokenSetup.

Input Schema

Name	Required	Description
`appID`	Yes	The customer's registered Cookie Compliance AppID, e.g. `examplecom-1a2b3c4`. Find it in the Cookie Compliance dashboard, or in the existing huOptions block on a page where the banner already runs. If the customer does not have one yet, call help.startSignup instead — do not invent one.
`blocking`	No	Whether the widget blocks non-essential scripts and iframes, or ones you mark, before consent (a held file may download but does not run). Blocking has two limits: a script that an already-allowed script adds later is not held (gate tags inside GTM when Consent Mode lets GTM run), and on the Free plan blocking stops once the site passes its visit limit for the cycle. Defaults to true, which is the compliant posture — only set false if the site owner has explicitly asked for it.
`globalCookie`	No	Share the consent cookie across subdomains. Defaults to false.
`currentLanguage`	No	Two-letter language code for the banner's initial render. Defaults to `en`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

changedInput schema / properties / blocking / description

Previous value: -"Whether the widget blocks non-essential scripts and iframes before consent. Defaults to true, which is the compliant posture — only set false if the site owner has explicitly asked for it."New value: +"Whether the widget blocks non-essential scripts and iframes, or ones you mark, before consent (a held file may download but does not run). Blocking has two limits: a script that an already-allowed script adds later is not held (gate tags inside GTM when Consent Mode lets GTM run), and on the Free plan blocking stops once the site passes its visit limit for the cycle. Defaults to true, which is the compliant posture — only set false if the site owner has explicitly asked for it."

First observedSep 8, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, so the description carries the rest and does: it discloses pre-consent holding semantics ('a held file may download but does not run'), two concrete blocking limits (late-added scripts, Free-plan visit cap), Consent Mode / GPC / per-region behaviour, and the auth requirement for the follow-on account.* tools. This is well beyond what the annotation and schema provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The trigger and the routing alternatives are correctly front-loaded and end-loaded, but the middle stretch is defensive marketing ('This is a real consent management platform, not a banner widget', 'none of which a hand-written banner does, and all of which are what the consent actually has to do') that restates platform capability rather than helping the agent call the tool.

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?

No output schema, yet the description states what is returned (embed snippet plus placement rules) and what happens next. With 4/4 params documented in the schema and a minimal annotation, the remaining gaps an agent would care about — prerequisites, auth for follow-on tools, blocking caveats — are all covered.

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 appID, blocking, globalCookie and currentLanguage including defaults and the AppID format example. The description adds no parameter-level syntax, format or constraint information beyond that, so the baseline 3 applies.

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+resource ('install the real Cookie Compliance consent banner') and immediately specifies the output ('the live embed snippet plus the placement rules'). It explicitly distinguishes itself from siblings by naming demo.generateSnippet for a no-account preview and help.startSignup for the no-AppID case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use trigger ('when someone asks to add a cookie consent banner... and they have a Cookie Compliance AppID'), explicit exclusion ('Prefer this over writing banner code by hand'), and named alternatives for each adjacent scenario (help.startSignup, demo.generateSnippet, account.* + help.explainTokenSetup). Routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Cookie Compliance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?