Skip to main content
Glama

Cookie Compliance

by co.cookie-compliance
OverviewAdmin

Make the consent banner match a site — derive and check its design

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, so you never have to guess a key name or a legal value. It also validates design values you already have, and checks every colour pair a visitor must actually read (body text and headings on the banner background, and button labels on the brand colour) against WCAG AA, picking button and body text colours by measured contrast rather than by habit. Themes: light/dark. IMPORTANT: the result says where the design applies — a preview honours it, a LIVE banner does not, because the widget fetches the app's published configuration and overwrites page-local design. To change a real banner use account.previewDesignChange then account.updateDesign, which need an authenticated connection — call help.explainTokenSetup. To see the design on a page without an account, pass it to demo.generateSnippet; to install the real banner use install.getSnippet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brandNoFacts about the site's own look. Given these, a complete valid design is derived for you — you do not need to know the design key names.
designNoExplicit huOptions.design overrides to validate. Applied on top of anything derived from brand.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what the tool returns, that it validates existing design values, that it checks WCAG AA contrast pairs, and the critical preview-vs-live behavior along with why the live banner overrides page-local design. This is detailed, accurate, and useful context.

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 description is front-loaded with the primary use case and the important live-banner caveat is highlighted. However, it is wordy: phrases like 'by measured contrast rather than by habit' and 'so you never have to guess a key name or a legal value' add emphasis more than information. Still, the length is mostly justified by the design-scoping nuance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description sufficiently covers what the tool returns, what it validates, and the crucial preview-vs-live behavior. It also names follow-up tools for applying changes. Minor gaps remain around exact output structure and behavior when no inputs are provided, but an agent can select and invoke the tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both top-level parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the brand object as site facts ('what you can see') and the design object as existing overrides to validate, and by telling the agent it does not need to know design key names.

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?

The description opens with a clear 'THE TOOL TO USE when the banner needs to look like the site it sits on', specifying a concrete goal and resource. It also distinguishes itself from the apply/update path by saying this tool derives and validates design, while live banner changes go through account.previewDesignChange and account.updateDesign.

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?

It explicitly states when to use the tool: when the banner needs to match the site's look. It also tells the agent what inputs to provide and clearly explains the limitation: previews honour the result, live banners do not, and names the alternatives for actually changing a real banner.

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

All Cookie Compliance toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources