ConsentStackDocs

MCP Server

Connect Claude, Cursor, or any MCP client to ConsentStack's hosted MCP server and manage cookie consent end to end. Create a site, publish the banner, get the install snippet, run a compliance scan, and categorize trackers, all from your agent.

ConsentStack ships a hosted MCP server, so an AI agent can set up and run cookie consent for you. MCP (Model Context Protocol) is the open standard AI tools use to connect to outside services. Connect once and your agent gets 22 tools covering the whole job: create a site, configure and publish the banner, get the install snippet, run a compliance scan, and categorize the trackers it finds.

If you built your site with an AI tool like Claude, Cursor, Lovable, or Replit, this is the shortest path to a working, compliant cookie banner: the same agent that built the site can install consent on it.

Connection details

Server URLhttps://app.consentstack.io/api/mcp
TransportStreamable HTTP
AuthenticationOAuth 2.1 (sign in with your ConsentStack account)
API keysNone. There is nothing to create or paste.

On first connect, your MCP client opens a browser window where you sign in with the same account you use for the dashboard. No ConsentStack account yet? Sign up free first; the Basic tier costs nothing.

Connect from Claude

For Claude Code, run:

claude mcp add --transport http consentstack https://app.consentstack.io/api/mcp

For claude.ai or the Claude desktop app, go to Settings > Connectors > Add custom connector and paste the server URL. Complete the sign-in when the browser window opens.

Connect from Cursor or another MCP client

Add the server to your client's MCP configuration. For Cursor, that is .cursor/mcp.json:

{
  "mcpServers": {
    "consentstack": {
      "url": "https://app.consentstack.io/api/mcp"
    }
  }
}

Any client that supports remote MCP servers over streamable HTTP with OAuth works the same way: give it the URL, sign in when prompted.

What your agent can do

All 22 tools, grouped by job:

JobTools
Sites and setuplist_sites, get_site_overview, create_site, manage_domains, get_setup_guide
Banner configurationget_config, update_appearance, update_content, update_compliance, update_settings, publish_config, discard_draft
Trackers and blockinglist_detected_trackers, set_tracker_category, clear_tracker_override, set_hostname_policy
Compliance scanningstart_scan, get_scan_result
Analytics and logsget_consent_analytics, get_consent_logs
Documentationsearch_docs, get_doc

get_setup_guide returns install snippets with your site's real key filled in, so the agent can paste working tags straight into your codebase.

What does an end-to-end setup look like?

A typical run, from nothing to verified:

  1. Create. create_site adds a site on the free Basic tier; manage_domains registers where it runs.
  2. Install. get_setup_guide returns the three install tags with your real site key, and the agent adds them to your site's <head>.
  3. Configure. The agent stages banner appearance, text, and compliance settings as drafts. Drafts never touch your live site.
  4. Publish. After you approve the changes in conversation, publish_config makes them live.
  5. Verify. start_scan runs the compliance scanner against the live site: a real browser visits, declines the banner, and reports any tracker that fired anyway. The agent categorizes what the scan finds and rescans until it comes back clean.

Scan findings come back with remediation hints that name the exact tool that fixes them, so an agent can close the loop on its own: scan, categorize, publish, rescan.

Does the MCP server cost anything?

No. MCP access is included on every plan, including the free Basic tier, and create_site creates Basic sites. Features that belong to paid plans (consent analytics and logs, for example) stay plan-gated exactly as they are in the dashboard; the tools tell your agent which plan unlocks them rather than working around the limit.

Who can make changes?

The same people who can in the dashboard. Every request runs under your account with your team role. Read tools work for any team member. Config writes (update_*, publish_config, tracker overrides) require the admin or owner role. And the server's own instructions direct agents to summarize pending changes and get your explicit go-ahead before publishing anything.

How is access secured?

The server implements OAuth 2.1 with standard protected-resource discovery, so clients negotiate sign-in automatically. Tokens are issued to your account, never to a shared key, and every database query enforces the same row-level security the dashboard uses. There are no long-lived API keys to leak or rotate.

What's next