Applies to: Anyone connecting an AI coding assistant to Cookie Compliance

Procedure, not a feature announcement. The tools listed here are the ones the live server returns with no account.

If you build or maintain a site with an AI assistant that supports MCP (Model Context Protocol) — Claude Code, Cursor, and others — you can point it at Cookie Compliance instead of asking it to write a cookie banner by hand.

Try it with no account

Point the client at https://mcp.cookie-compliance.co/mcp.

Claude Code:

claude mcp add --transport http cookie-compliance https://mcp.cookie-compliance.co/mcp

Cursor: add a remote server in .cursor/mcp.json (project) or ~/.cursor/mcp.json (all projects). The url field is enough to start — no account header:

{
  "mcpServers": {
    "cookie-compliance": {
      "url": "https://mcp.cookie-compliance.co/mcp"
    }
  }
}

Cursor Settings → Tools & MCP can add the same URL. If the client supports MCP sign-in, it will prompt to connect in the browser. For a manual token later, put only the hu_ value in headers.Authorization as Bearer hu_… — never the whole login URL. See Cursor’s MCP docs for the config shape.

With no signup, no key and no card, the assistant can:

  • Install the real banner if you already have an AppID in the Cookie Compliance dashboard. It returns the snippet and the placement rule: first script in <head>, ahead of analytics, pixels and tag managers. On WordPress, install the plugin rather than pasting. Do not put the snippet inside a Google Tag Manager container.
  • Preview the look with no AppID. A preview records and enforces no consent, expires after 24 hours, and must be replaced with the real snippet before the site is “done”.
  • Derive a matching design from the site’s brand colour, page background, theme, corner style and text scale, then check every colour pair a visitor must read (body and headings on the banner, labels on the brand colour) against WCAG AA. It also validates values you already have. A preview honours that design; a live banner does not — the widget loads the published configuration and overwrites page-local design. Restyle a real banner in the dashboard (or with an authenticated connection), not by adding design to the install snippet.
  • Look up a setting — default and accepted values for design and banner text keys.
  • Hand you the free signup URL when you have no account yet. The Free plan needs no card. The assistant cannot create the account, complete the captcha, or verify your email.

On WordPress, install Cookie Compliance for WordPress rather than pasting a snippet.

Connect your account (optional)

To let the assistant work with a banner you already run, prove the connection belongs to your account. Two routes:

  • Browser sign-in (preferred). Add the server with no extra header. A client that supports MCP sign-in opens a Hu-manity page titled “Connect this application to your Hu-manity account?”. Before you click Connect, check two things: the Application named is the assistant you are using, and the Sends access to line is a place you recognise. Permissions are listed below those two fields. Then click Connect. Nothing to copy.
  • API token (fallback). If the client has no sign-in, create a token at https://app.hu-manity.co/#/api-tokens/new. The form asks for a name and an expiry — pick the latest date the screen allows. After you submit, the page shows a login URL. The Copy Link button copies that full URL to your clipboard. For MCP, use only the token= value from that URL (the part starting with hu_) in your header — not the whole login URL. Register it as a request header: Authorization: Bearer hu_… (or x-hu-api-token: hu_…). In Claude Code: claude mcp add --transport http cookie-compliance https://mcp.cookie-compliance.co/mcp --header "Authorization: Bearer hu_…". Never paste the value in a chat message, never as your password. It is shown once. There is no renewal: when it expires, create another.

The assistant cannot create this credential for you, and must never be given your dashboard password.

Before you change configuration

Consent on Update (Professional; off by default) is what asks returning visitors to choose again after a configuration change (blocking, consent categories, regional rules). Reverting the change does not undo a re-ask that already happened. Design and wording changes do not re-ask. Stored consent logs are kept either way. Read any re-ask warning before you confirm a configuration change, whether you make it in the dashboard or ask an assistant to.

If the assistant reports it cannot apply a change because you have unpublished edits waiting in the dashboard on the same setting: click Publish Now if those edits are what you want, or edit the draft to the values you want and then publish. That refusal is intentional — it avoids publishing work you have not reviewed. There is no Discard button.

If it stops working

  • Account tools never appeared. The connection is not authenticated. Use browser sign-in, or check the token header is the hu_ value (not the whole login URL). A truncated or URL-shaped credential fails silently and looks like “not signed in”.
  • It worked, then every account call returns an error. Tokens expire, and nothing warns you beforehand. Sign in again, or create a new token and re-register the hu_ value.
  • The banner shows but trackers still fire before a choice. The snippet is probably not first in <head>, or a cache/optimiser moved it, or it was loaded from Google Tag Manager. Move it above analytics, pixels and the tag-manager container. See Where to put the Cookie Compliance snippet.
  • Banner colours flashed, then reverted. A live banner loads the published configuration and overwrites design set only on the page. Change appearance in the dashboard (Design), then publish — not in the install snippet.

Still stuck? Contact support with your AppID and what the assistant reported.

Related Articles

Was this article helpful?
YesNo