CookieYes brings cookie consent management to MCP

CookieYes has released an MCP server to manage cookie consent from inside Claude and ChatGPT, according to the statement distributed by PR Newswire on 17 September. The announcement is a corporate press release, not independent analysis, so it should be read for what it is. Even so, the headline fact matters: a consent management platform, the most audited and least glamorous layer of any European website, is now shipping as a tool for conversational assistants.

Over the past year we have seen MCP servers for databases, code repositories, CRMs and ticketing systems. A consent server plays in a different league: it touches personal data, it stores records that work as evidence before a supervisory authority, and it backs decisions that someone has to be able to defend in writing.

What is being announced and what is left open

MCP is Anthropic's protocol for letting a model call external tools under an explicit contract of inputs and outputs. An MCP server is not a proprietary plugin or an integration locked to one client: it is a process that declares its tools and serves them to any compatible application. That is why the same server can show up in Claude Desktop, in Claude Code or in ChatGPT without rewriting the integration three times. In practice, that is the whole argument for the protocol.

The statement does not detail the catalogue of exposed tools, nor the write permissions, nor whether the server runs locally or as an authenticated remote service. Those are the three questions that decide whether this is a convenience or a hole, and none of them appears in the note. Until there is public technical documentation, the sensible reading is a statement of intent with a product behind it, not something you can install with any real judgement.

Why it matters beyond the cookie niche

The market signal is the interesting part. MCP is moving out of the developer tooling territory where it was born and into SaaS categories that have nothing to do with writing code. A compliance vendor does not publish a protocol server because it is fashionable: it publishes one because its customers already want to do that work from the place where they do everything else.

The operational signal affects anyone maintaining other people's websites. Checking why the banner is blocking a script, verifying which categories a domain has declared, or comparing the setup of fifteen sites in the same chain are read-only, repetitive tasks with structured answers. That is exactly the kind of work MCP is good for: frequent queries, verifiable results and no room for the model to improvise.

What we would check before wiring it into production

1. Write permissions. Reading a domain's configuration is one thing. Modifying the banner on a live site is another, and it should require explicit confirmation on every call.
2. Traceability. If the assistant changes something, the audit log has to identify the responsible person and not a generic integration token.
3. Data leaving the perimeter. Consent records are personal data under the GDPR. You need to know what is sent to the model, under which legal basis and for how long it is retained.
4. Hosting. A local server and a multi-tenant remote one carry different risk profiles, and the note does not clarify which of the two this is.
5. The limits of the advice. A model can explain a configuration and spot an inconsistency. It does not issue legal opinions, however well written they sound.

Our take

Having compliance integrate through an open protocol rather than through bespoke integrations strikes us as the right direction, especially for teams running dozens of domains under the same policy. That said, an announcement without public documentation is not yet something we would put in a client environment: when the technical detail shows up, we will come back to it.