titulo: MCP para Drupal: deja de alucinar módulos que no existen meta_description: Un MCP con casos de uso y metadatos guía a los agentes IA hacia los módulos Drupal correctos, reduce alucinaciones y ahorra tokens: cómo montarlo paso a paso. keywords: MCP Drupal, agentes IA para desarrollo, selección de módulos Drupal con IA, evitar alucinaciones de agentes IA, Model Context Protocol Drupal, IA aplicada a desarrollo web tags: inteligencia artificial, Drupal, Drupal 11, modulos de drupal, automatización, programación categoria: Inteligencia Artificial slug: mcp-evitar-alucinaciones-agentes-drupal ---
Un servidor MCP conectado a drupal.org entrega al agente los módulos reales antes de que invente código: esa es la forma de frenar las alucinaciones.
El patrón es este: en lugar de un prompt más estricto, se conecta el agente (Claude Code, Cursor, Codex) a un servidor MCP (Model Context Protocol) que consulta un dataset real de proyectos de drupal.org —nombre, casos de uso, dependencias, versión— y le devuelve los módulos candidatos antes de que escriba una sola línea. El agente deja de adivinar nombres y deja de reimplementar login, OAuth o formularios que un módulo contributed resuelve en minutos.
Qué falla hoy cuando el agente desarrolla en Drupal
Cuando los agentes de código no tienen contexto sobre el ecosistema Drupal, el patrón es siempre el mismo:
- El agente no encuentra un módulo con el nombre exacto que tiene en la cabeza y concluye que no existe.
- Escribe código propio para autenticación, autorización, colas o formularios condicionales.
- En el siguiente turno "recuerda" un módulo que tampoco existe (
oauth2_login,webform_rulesy similares), genera uncomposer requireinválido y entra en un bucle de correcciones que consume tokens sin avanzar.
Cada ciclo de prueba y error cuesta tokens y, sobre todo, credibilidad en la recomendación. El problema no es el modelo: es que no tiene forma de hacer una pregunta simple —"¿qué módulos resuelven X en Drupal 11?"— contra una fuente confiable.
Cómo funciona un MCP de conocimiento de módulos
Un servidor MCP expone herramientas que el cliente invoca en cada turno; aquí, una búsqueda de módulos. En la sesión del Drupal AI Learners Club del 8 de octubre de 2026 se presentó una implementación con estas piezas, documentada en drupal.org:
- Dataset de proyectos de drupal.org con licencia MIT, con metadatos y descripciones de los módulos.
- Embeddings con Model2Vec: un modelo pequeño que corre localmente, sin llamadas a APIs externas por cada consulta.
- SQLite con BM25 para búsqueda por palabras clave exactas.
- Fusión RRF (Reciprocal Rank Fusion) para combinar el ranking semántico y el ranking léxico en un solo resultado.
El dato relevante de esa sesión: las evaluaciones mostraron la mayor mejora justamente en módulos poco documentados, que es donde el agente con contexto cero falla más.
Por qué híbrido y no solo embeddings
La búsqueda puramente vectorial se equivoca con los nombres propios de Drupal, que son la mitad de las consultas reales: search_api, pathauto, entity_reference_revisions. Un ranking BM25 sobre el nombre del proyecto lo resuelve de forma exacta.
Las consultas, además, llegan como frases de caso de uso ("quiero que un usuario con rol X vea solo sus pedidos"), y ahí el embedding captura la intención que ninguna coincidencia literal encuentra. RRF fusiona ambos rankings sin tener que calibrar pesos a mano, y es la razón por la que una instalación local es suficiente: no hay que reentrenar nada para mantenerlo al día.
Cómo montarlo en tu flujo de trabajo
Paso 1 — Revisa las fuentes antes que nada. La sesión del club dejó el diseño y los resultados publicados en drupal.org (enlace arriba) y existe además el proyecto Agent Access, que integra MCP/Tool API en Drupal desde el 16 de octubre de 2026. Son puntos de partida reales, no un esquema genérico.
Paso 2 — Registra el servidor MCP en tu cliente. En Claude Code:
# Claude Code — registra el servidor y lo levanta bajo demanda
claude mcp add drupal-modules -- <comando-de-arranque-del-servidor>
En Cursor el registro va en .mcp.json en la raíz del proyecto, con la misma estructura name + command. El comando exacto depende de la distribución que elijas (script local, contenedor o paquete publicado); verifícalo en el README del repositorio que uses.
Paso 3 — Obliga al agente a consultar antes de escribir. La regla va en el prompt del proyecto o en CLAUDE.md:
- Antes de escribir código que resuelva autenticación, formularios,
colas, caché, búsqueda o permisos, consulta la herramienta de
búsqueda de módulos Drupal.
- Si la herramienta devuelve un módulo candidato, verifica en
https://www.drupal.org/project/<nombre> que exista y sea compatible
con Drupal 11 antes de recomendarlo.
- Nunca inventes nombres de módulos ni rutas de composer.
Paso 4 — Prueba con consultas que hoy fallan. Pide "implementa login con proveedor OAuth en Drupal 11" y "formularios con lógica condicional" y revisa si el agente propone módulos reales antes de proponer clases PHP.
Paso 5 — Deja que el dataset se actualice. Los proyectos de drupal.org cambian de estado y de versión; planifica una reconstrucción periódica del índice (la misma frecuencia con la que sincronizas tu composer.lock sirve).
Dónde sí y dónde no ayuda
Ayuda en la capa de selección: qué módulo contributed cubre el requisito, qué nombre tiene realmente, qué dependencias arrastra. Ahí baja de forma medible el número de iteraciones fallidas y de composer require inválidos.
No ayuda en la capa de juicio. El MCP te dice que el módulo existe, no si su mantenimiento es activo, si su modelo de datos encaja con tu caso, ni si la combinación con tus módulos custom produce conflictos. Tampoco reemplaza leer el issue queue del proyecto antes de comprometer una arquitectura.
Tampoco sustituye tus propias evaluaciones: si el equipo no mide cuántas recomendaciones de módulos eran correctas antes y después de conectar el servidor, no sabrás si el cambio sirvió. Un conteo simple de "módulos sugeridos que existen en drupal.org" en diez tareas reales ya te da una línea base.
El siguiente paso es concreto: toma tres tareas pendientes en las que el agente ya haya fallado pidiendo código a medida, conecta el MCP de módulos y compara cuántas de esas tres terminan hoy con un composer require correcto. Con ese número decides si vale la pena dejarlo fijo en el prompt del equipo.
Preguntas frecuentes
¿Qué es un MCP en el contexto de agentes de código?
MCP (Model Context Protocol) es un estándar que conecta modelos con fuentes de datos y herramientas externas mediante servidores independientes. En la práctica, permite que tu agente consulte un índice de módulos Drupal como si fuera una herramienta más, en lugar de depender de lo que el modelo memorizó.
¿Sustituye al conocimiento que el modelo ya tiene de Drupal?
No, lo complementa. El modelo sigue sabiendo patrones de Drupal y de PHP; el MCP aporta los nombres reales de los proyectos, sus dependencias y su estado en drupal.org, que es la parte que el modelo no puede verificar por sí mismo.
¿Necesito conexión a internet para usarlo?
Depende de la implementación. La presentada en el Drupal AI Learners Club usa un dataset local con Model2Vec y SQLite, así que las consultas se resuelven en tu máquina; solo necesitas conexión para actualizar el índice y para abrir la ficha del módulo en drupal.org.
¿Sirve también para WordPress u otros ecosistemas?
El patrón es el mismo: un dataset del repositorio de plugins, búsqueda híbrida y un servidor MCP. La parte específica de Drupal es el dataset de proyectos y los criterios de compatibilidad con versiones de core, que es donde está el valor para quien trabaja en Drupal.
¿Cuánto tarda en verse el resultado?
Lo suficientemente pronto como para notarlo en la primera semana: las tareas en las que el agente proponía clases a medida empiezan a abrirse con un módulo candidato y un enlace a drupal.org. Si después de varias tareas sigues viendo nombres de módulos inventados, revisa que la regla de "consultar antes de escribir" esté en el prompt y que el servidor MCP esté realmente registrado en tu cliente.
