CookieYes lleva la gestión de consentimiento de cookies a MCP

CookieYes ha publicado un MCP server para gestionar el consentimiento de cookies desde dentro de Claude y de ChatGPT, según el comunicado distribuido por PR Newswire el 17 de septiembre. El anuncio es una nota de prensa corporativa y no una pieza de análisis independiente, así que conviene leerlo por lo que es. Aun así, el dato del titular importa: una plataforma de consent management, la capa más auditada y menos vistosa de cualquier web europea, se distribuye ya como herramienta para asistentes conversacionales.

Durante el último año hemos visto MCP servers de bases de datos, repositorios de código, CRMs y sistemas de tickets. Un servidor de consentimiento juega en otra liga: toca datos personales, guarda registros que sirven como prueba ante una autoridad de control y sostiene decisiones que alguien tiene que poder defender por escrito.

Qué se anuncia y qué queda en el aire

MCP es el protocolo de Anthropic para que un modelo llame a herramientas externas con un contrato explícito de entradas y salidas. Un MCP server no es un plugin propietario ni una integración cerrada a un cliente concreto: es un proceso que declara sus herramientas y las sirve a cualquier aplicación compatible. Por eso el mismo servidor puede aparecer en Claude Desktop, en Claude Code o en ChatGPT sin reescribir la integración tres veces. Ese es, en la práctica, todo el argumento del protocolo.

El comunicado no detalla el catálogo de herramientas expuestas, ni los permisos de escritura, ni si el servidor se ejecuta en local o como servicio remoto autenticado. Son las tres preguntas que deciden si esto es una comodidad o un agujero, y ninguna aparece en la nota. Hasta que haya documentación técnica pública, lo razonable es tratarlo como un anuncio de intención con producto detrás, no como algo instalable con criterio.

Por qué importa fuera del nicho de las cookies

La señal de mercado es la parte interesante. MCP está saliendo del territorio de las herramientas de desarrollo, donde nació, y llegando a categorías de SaaS que nada tienen que ver con escribir código. Un proveedor de cumplimiento normativo no publica un servidor de protocolo por moda: lo publica porque sus clientes ya quieren hacer ese trabajo desde el sitio donde hacen el resto.

La señal operativa afecta a quien mantiene webs ajenas. Revisar por qué el banner bloquea un script, comprobar qué categorías tiene declaradas un dominio o comparar la configuración de quince sitios de una misma cadena son tareas de lectura, repetitivas y con respuesta estructurada. Es exactamente el perfil de trabajo para el que MCP tiene sentido: consultas frecuentes, resultados verificables y cero margen para la improvisación del modelo.

Qué revisaríamos antes de enchufarlo a producción

1. Permisos de escritura. Leer la configuración de un dominio es una cosa. Modificar el banner de un sitio vivo es otra, y debería exigir confirmación explícita en cada llamada.
2. Trazabilidad. Si el asistente cambia algo, el registro de auditoría tiene que identificar a la persona responsable y no a un token genérico de integración.
3. Datos que salen del perímetro. Los registros de consentimiento son datos personales bajo el RGPD. Hay que saber qué se envía al modelo, con qué base legal y durante cuánto tiempo se retiene.
4. Alojamiento. Un servidor local y uno remoto multiinquilino tienen perfiles de riesgo distintos, y la nota no aclara cuál de los dos es este.
5. El límite del consejo. Un modelo puede explicar una configuración y detectar una incoherencia. No emite dictámenes jurídicos, por bien redactados que suenen.

Nuestra lectura

Que el cumplimiento normativo se integre por protocolo abierto en lugar de por integración a medida nos parece la dirección correcta, sobre todo para equipos que gestionan decenas de dominios con la misma política. Dicho esto, un anuncio sin documentación pública todavía no es algo que pondríamos en el entorno de un cliente: cuando aparezca el detalle técnico, volveremos sobre ello.