Notas del trabajo

Un servidor MCP para un sitio Drupal: primero leer, y cada escritura con aprobación

Pregúntele al concierge Contacto

En corto: un servidor MCP le permite a un asistente de IA, como Claude o ChatGPT, trabajar con su sitio Drupal por medio de herramientas con nombre propio, en vez de adivinar desde afuera. Constrúyalo para que el asistente pueda leer antes de poder escribir: primero herramientas que consultan, luego herramientas de escritura que una persona aprueba una por una, y la publicación detrás de un permiso aparte. Las credenciales se quedan en el servidor, cada token sirve solo para ese servidor, y nada de lo que escriba un agente sale al público sin una persona. Drupal ya tiene módulos contribuidos para esto. Al 28 de octubre de 2026, todos están en versión alpha o beta.

¿Qué es un servidor MCP, en palabras sencillas?

El Model Context Protocol (MCP) es, según su propia documentación, un estándar abierto para conectar aplicaciones de IA con sistemas externos. Un servidor MCP publica una lista corta de herramientas. Cada una tiene un nombre, una descripción y un esquema de lo que recibe. El asistente lee la lista, escoge una herramienta y la llama; el servidor hace el trabajo y responde. En un sitio Drupal, una herramienta puede ser "listar los tipos de contenido", "cargar esta página" o "guardar este borrador".

La especificación (versión 2026-07-28) deja claro quién manda: dice que siempre debería haber una persona con la capacidad de negar cada llamada a una herramienta. También exige que el servidor valide cada dato que recibe, controle el acceso, limite la cantidad de llamadas y limpie lo que devuelve.

Por qué le sirve: lo que el asistente puede hacer es exactamente lo que permiten las herramientas. La lista de herramientas es el diseño de seguridad.

¿Quién puede cambiar mi sitio, y en qué orden?

La mayor parte del valor está en leer, y casi todo el riesgo está en escribir. Un asistente que puede listar sus tipos de contenido, leer una página y decir qué cambió desde el último despliegue ya responde casi todo lo que preguntan los editores y los desarrolladores. Nada de eso puede dañar el sitio.

Por eso lo construimos en este orden:

  1. Herramientas de lectura. Describen la estructura del sitio, cargan contenido y reportan el estado de la configuración. Corren con una cuenta de Drupal dedicada, con un rol que solo puede ver.
  2. Herramientas de escritura, con aprobación. Crean o editan contenido. Una persona aprueba cada llamada en el asistente antes de que corra, y de todos modos el sitio guarda el resultado como borrador sin publicar o como una revisión nueva. Las páginas publicadas no se tocan.
  3. La publicación, con su propio permiso. Un permiso aparte, o una persona que oprime Publicar en la pantalla editorial de Drupal.

Un agente no cambia la configuración (tipos de contenido, campos, vistas) en producción. En los sitios que construimos, la configuración vive en git y llega a producción con pruebas y un despliegue, así que un cambio del agente es un cambio en el repositorio que una persona revisa primero.

Por qué le sirve: un token que solo lee puede exponer datos, pero no puede dañarle el sitio. Y como cada paso tiene su propio permiso, usted decide hasta dónde llega el asistente.

¿Cómo se ve "cada escritura con aprobación"?

El protocolo le deja la pantalla de confirmación a la aplicación del asistente, así que el servidor también pone sus propios límites:

  • Una persona aprueba cada escritura. El asistente muestra la llamada y sus datos, y nada corre hasta que alguien dice sí.
  • Borradores por defecto. Aun aprobada, una escritura queda sin publicar: un error es un borrador que alguien borra, no una página que vio el público.
  • Permisos estrechos. La guía de seguridad de MCP recomienda empezar con un permiso mínimo de lectura y pedir más solo cuando se intenta por primera vez una operación delicada. Leer, escribir y publicar son permisos distintos.
  • El token nunca es más grande que la persona. Cada llamada corre con los permisos de la cuenta de Drupal que la respalda, y es Drupal quien los verifica.
  • Lo que envía o gasta, espera. Correos, pagos, llamadas a servicios que cobran: cada uno espera un sí explícito.
  • Cada llamada queda registrada por el nombre de la herramienta, sin guardar el contenido de cada solicitud a menos que usted lo decida.
  • Pruebas y un README. Cada herramienta tiene su prueba, y el servidor trae instrucciones para configurar el asistente de su equipo.

¿Dónde quedan las llaves?

Ni en el contexto del modelo ni en un archivo de su repositorio:

  • Secretos por referencia. La configuración dice dónde vive cada credencial (una variable de entorno del servidor o un archivo protegido) y el servidor la lee al correr. Nunca aparece en la configuración exportada, en un prompt ni en un registro. En nuestro propio sitio, los secretos del agente de voz salen del entorno del servidor, y la configuración que está en git los tiene vacíos.
  • Un token por servidor. La guía de seguridad de MCP prohíbe pasar tokens de largo: un servidor no debe aceptar tokens que no se emitieron para él.
  • El consentimiento, en el navegador de la persona. Cuando un servicio usa OAuth, la persona inicia sesión y aprueba una vez, y puede revocar ese permiso cuando quiera.

¿Qué módulos de Drupal existen hoy?

Revisamos los registros de versiones y los repositorios de código de drupal.org el 28 de octubre de 2026. Es un reporte de estado, no una recomendación:

  • MCP Server (mcp_server): última versión 2.0.0-beta6, del 14 de octubre de 2026, para Drupal 10 y 11. Está hecho sobre el SDK oficial de MCP para PHP y funciona por línea de comandos y por HTTP. Su punto de acceso exige un permiso propio. El núcleo del módulo no trae autenticación: OAuth viene de un proyecto aparte, MCP Server OAuth, en 1.0.0-alpha1.
  • Model Context Protocol (mcp): la última versión publicada es 1.2.3, del 14 de noviembre de 2025. Una rama de desarrollo 2.0 lo reconstruye sobre MCP Server, con tres permisos OAuth (leer, escribir, publicar) y el contenido nuevo guardado sin publicar. Todavía no hay versión 2.0 publicada.
  • MCP Tools (mcp_tools): 1.0.0-beta18, del 24 de julio de 2026, una biblioteca grande de herramientas. Su propio README dice que está pensado sobre todo para desarrollo local y aconseja el modo de solo lectura en producción.
  • MCP Client (mcp_client): 1.0.0-alpha3, del 22 de agosto de 2026. Funciona al revés: deja que el módulo de IA de Drupal llame a servidores MCP de afuera.

Ninguno tiene versión estable. Nombres que a veces se sugieren, como ai_mcp o drupal_mcp, no existen como proyecto en drupal.org.

Por qué le sirve: las piezas existen y cambian rápido. Cuál le sirve depende de su sitio, y un módulo alpha o beta necesita a alguien que lea sus cambios antes de cada actualización.

¿Qué ha construido nuestro fundador con estas reglas?

Nuestro fundador hace su trabajo diario a través de MCP, y sus herramientas siguen las mismas reglas:

  • dangler, público en GitHub, es una sola puerta de entrada a un grupo de servidores MCP. El asistente ve cinco herramientas pequeñas y carga la lista completa de un servidor solo cuando la necesita. Cada servidor declara a nombre de qué cuenta actúa, guarda sus secretos por referencia y tiene un modo de solo lectura donde el servicio de atrás puede escribir.
  • gws-mcp, su servidor para Google Docs, Sheets, Drive y borradores de Gmail, pide solo los permisos que su trabajo necesita. No puede escribir en Drive, y envía un correo solo si es un borrador ya revisado, nunca uno escrito en la misma llamada.

Tiene la certificación de Anthropic en MCP (mayo de 2026). Estas herramientas no son módulos de Drupal, y nuestro sitio no corre hoy un servidor MCP. Son el lugar donde estas reglas se probaron en el uso diario.

Por qué le sirve: el método no es una presentación. Es como ya trabaja la persona que construiría el suyo.

¿Qué no prometemos?

Hoy el ingeniero es nuestro fundador. Construimos un servidor MCP por sistema y fijamos su alcance después de conocer el suyo, porque un servidor MCP es tan seguro como los permisos que tiene detrás: cada trabajo empieza por revisar quién puede hacer qué en su sitio. El soporte va en horario hábil de Colombia (UTC-5). El único precio fijo es una hora con el fundador: 75 dólares.

Para ver el resto, lea un agente de IA en Drupal que guarda sus llaves en el servidor y cómo usamos la IA, y dónde no la dejamos actuar. Si quiere conectar su asistente a su sitio Drupal, mire nuestra oferta o escríbanos.

Fuentes

Consultadas el 28 de octubre de 2026.

Redactado con Claude a partir de nuestros propios registros; revisado y aprobado por Carlos Santana. Cómo usamos la IA

¿Hablamos sobre este proyecto?

Pregúntele al concierge sobre este proyecto: qué es, cómo se construyó, o póngase en contacto con nosotros.