Inteligencia Artificial

Drupal 11 ya se conecta con agentes de IA: instala MCP Server, crea un usuario de servicio con permisos mínimos y registra el cliente con OAuth 2.1.

Un servidor MCP es, en la práctica, una API de escritura con un agente al otro lado. La diferencia entre una integración bien hecha y un problema de seguridad está casi siempre en los permisos, no en el módulo.

Requisitos e instalación

Antes de tocar el código, verifica cuatro puntos:

  • Drupal 10 o 11 con dependencias gestionadas por Composer. El módulo no es un parche manual ni un tema.
  • HTTPS obligatorio. OAuth 2.1 y los clientes MCP actuales rechazan tokens en texto plano. En local, un túnel con TLS (ddev launch con dominio, o un proxy con certificado) es parte del flujo, no un extra.
  • Un cliente MCP real: Claude Desktop, Cursor, un copiloto interno o cualquier cliente compatible con transporte HTTP. No todos hablan el mismo transporte, y eso define cómo conectas.
  • Un usuario de servicio propio, nunca el usuario 1. Ese usuario es el que carga los permisos que heredarán las herramientas.

Instalación del módulo

composer require drupal/mcp_server
drush en mcp_server
drush cr

Si tu composer.json declara "minimum-stability": "stable", Composer rechaza la beta. Se resuelve declarando estabilidad en el proyecto, no en el módulo:

{
"minimum-stability": "dev",
"prefer-stable": true
}

Con DDEV los mismos comandos llevan prefijo:

ddev composer require drupal/mcp_server
ddev drush en mcp_server
ddev drush cr

El complemento natural es MCP Server Tool Bridge, que publica como herramientas MCP lo que ya expones con la Tool API de Drupal, sin duplicar la definición:

composer require drupal/mcp_server_tool_bridge
drush en mcp_server_tool_bridge

Cuidado con el módulo MCP clásico (1.2.3, noviembre de 2025): está siendo absorbido por MCP Server y su namespace se repurpondrá como recipe. No lo tomes como base para una implementación nueva; revisa el estado en drupal.org/project/mcp antes de decidir.

OAuth 2.1 sin identity provider aparte

El módulo trae el servidor de autorización, así que no necesitas montar un proveedor de identidad externo. El flujo es: registrar el cliente MCP (nombre, redirect URI y scopes), generar las URLs de autorización y de token, y pedir el access token para almacenarlo en el cliente.

Las URLs exactas y los scopes disponibles aparecen en la página de configuración del módulo y cambian entre versiones beta. Cópialas de ahí; no las asumas ni las fixes en tu documentación interna. Lo que importa es que el token es de alcance limitado y expirable, no una sesión de navegador reutilizada.

Definir las herramientas

Las herramientas se crean como entidades de configuración: viven en código, se versionan y se despliegan con el resto de tu configuración. Eso es lo que separa esta integración de un script suelto en un cron.

Un orden sensato para una pyme que quiere un agente copiloto:

  • Lectura acotada: listar y ver contenido de un bundle concreto, no de todo el sitio.
  • Crear borrador: crear el nodo con status: unpublished y unos pocos campos.
  • Actualizar controlada: modificar title, body y field_* puntuales, nunca campos de autor ni referencias sensibles.
  • Clasificar y resumir: operar sobre taxonomía, nunca sobre el esquema de usuarios.

Empieza con las dos primeras. Agregar herramientas de escritura es fácil; retirarlas después es un problema operativo.

Conectar el agente y depurar

El endpoint de transporte lo publica el módulo y es lo que el cliente debe apuntar. Copia la ruta exacta desde la configuración en lugar de asumirla. Para clientes de escritorio que solo lanzan procesos locales, el puente mcp-remote resuelve el caso:

{
"mcpServers": {
"drupal-saibher": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://TU-SITIO.example.com/TU-RUTA-MCP",
"--header",
"Authorization: Bearer TU_ACCESS_TOKEN"
]
}
}
}

Para ver qué anuncia realmente tu servidor, el inspector oficial es la herramienta correcta:

npx @modelcontextprotocol/inspector

Ahí ves la lista real de herramientas con el texto exacto de cada descripción. Y esa salida es tu primer punto de revisión de seguridad, porque en MCP la descripción de una herramienta es código: el modelo la lee y la obedece.

La revisión 2026-07-28 y sus efectos

La revisión 2026-07-28 es el cambio más grande desde el lanzamiento del protocolo y afecta directo lo que escribas hoy:

  • Desaparece el handshake initialize / initialized.
  • Desaparece el encabezado Mcp-Session-Id, y con él la idea de sesión de transporte.
  • El transporte HTTP+SSE queda deprecado, con una ventana mínima de 12 meses.
  • Se reemplaza por RPC server/discover.
  • Elicitation, sampling y tasks salen del núcleo del protocolo.

Qué significa en Drupal: no construyas arquitecturas que dependan de sesiones persistentes ni de SSE. Diseña como si cada invocación fuera independiente; tu usuario de servicio, tus permisos y tu estado deben sobrevivir sin memoria del transporte. Lee el resumen en WorkOS y el análisis de cambios en VentureBeat.

Tool poisoning: los permisos son la defensa

El vector dominante en MCP se llama tool poisoning: una instrucción oculta dentro de la descripción de una herramienta o de los datos que el agente lee, que el modelo ejecuta y el usuario nunca ve. OWASP lo incluye en su Top 10 de riesgos para aplicaciones con LLM, y un estudio publicado en MDPI en 2026, con 57 amenazas evaluadas contra 7 clientes MCP, concluyó que 5 de 7 no validan del lado del cliente los metadatos de las herramientas (referencia).

En Drupal el vector más obvio es el contenido: si tu herramienta de lectura devuelve el body de un nodo que puede editar cualquiera, tienes inyección indirecta. Revisa también la guía de OWASP sobre MCP Tool Poisoning.

Reglas mínimas de permisos

  • Menor privilegio por herramienta, no por módulo. Cada entidad de configuración puede apuntar a un usuario de servicio distinto.
  • Nunca concedas administer permissions, administer users, administer site configuration ni herramientas de actualización de módulos.
  • Limita por bundle y por campo. Que el agente escriba en title y body, no en el mail de un usuario ni en referencias a entidades sensibles.
  • Filtra los listados. Un listado de usuarios con correo expuesto es una fuga esperando a que el agente la use.
  • Publicar es decisión humana. Que el agente deje el contenido en unpublished y alguien lo apruebe.
  • Revisa los logs. El log de Drupal y el del servidor web te dicen qué herramienta se invocó y desde dónde.

La ventaja real de Drupal frente a un WordPress genérico está aquí: permisos granulares, control de acceso por campo y revisión de contenido de entrada. Es modelado de permisos serio, no un checkbox.

Trazabilidad para cumplimiento

Mientras la regulación colombiana de inteligencia artificial sigue en etapa de proyecto de ley en el Congreso, aplica criterio de trazabilidad: registra quién pidió qué, qué herramienta se ejecutó, qué devolvió y quién aprobó. Un agente que escribe contenido sin rastro de aprobación es primero un problema de gobierno y después un problema técnico.

Preguntas frecuentes

¿El módulo MCP Server es estable o conviene esperar?

Está en beta, así que úsalo con prudencia. Sirve en producción si tu Drupal está actualizado, pruebas en staging y empiezas sin herramientas de escritura. El módulo MCP clásico se está fusionando con MCP Server y su namespace pasa a ser recipe, así que hoy no es el camino recomendado.

¿Puedo usarlo con Claude Desktop o necesito otro cliente?

Puedes, mediante un puente como mcp-remote si tu cliente solo lanza procesos locales. Si el cliente habla transporte HTTP nativo, apunta directo al endpoint del módulo. Antes de escribir código, verifica con @modelcontextprotocol/inspector qué transporte anuncia tu instalación.

¿Cuánto cambia con la revisión 2026-07-28?

El impacto es de diseño, no de sintaxis: sin handshake, sin Mcp-Session-Id y sin SSE, cada invocación debe ser independiente. Si tu implementación no dependía de sesiones persistentes, la migración es painless; si sí dependía, hay que rehacer el manejo del estado.

¿Cómo evito que el agente exponga datos sensibles?

Con permisos de Drupal, no con prompts. Un usuario de servicio por herramienta, campos limitados, listados filtrados y ninguna herramienta de administración. Y recuerda que el contenido es entrada no confiable: cualquier texto editable que devuelvas al agente es un vector de tool poisoning.

¿Necesito montar OAuth por fuera?

No. El módulo trae servidor de autorización con OAuth 2.1 y registras el cliente desde su configuración. Sí necesitas HTTPS, y conviene revisar los logs de invocación desde el primer día.

Siguiente paso

Si tienes Drupal 11 en producción, agenda una sesión corta: instala el módulo en staging, crea un único usuario de servicio con permisos de solo lectura y conéctalo con el inspector. Con eso verificas la compatibilidad real de tu versión de Drupal y de tu cliente antes de comprometer arquitectura.

Cuando el agente además de contenido debe escribir datos de negocio, ese punto de integración deja de ser un detalle de Drupal y se vuelve modelado de permisos de verdad. En Saibher lo trabajamos junto con el ERP o el sistema de gestión del cliente. Cuéntanos cómo es tu caso.