Prueban cinco componentes MCP para MODX ante fallos: el agente informa de éxito cuando solo se guardó la mitad de los cambios

Una tarea habitual: elegir un componente MCP para delegar en un agente de IA el trabajo rutinario en sitios web. Pero un desarrollador de un estudio web que trabaja con MODX 2 y 3 miró el código y vio un bucle que actualiza los campos adicionales de una página y no comprueba el resultado de setTVValue(). El primer campo se escribió, el segundo no, y el controlador informó de éxito. El agente se creerá esa respuesta y le dirá al usuario que todo está listo.

De ahí surgió una pequeña investigación. El autor seleccionó cinco proyectos: karamble/modxmcp, dampilov94/mcp-component, rumata-estor/modx3-mcp, modxcms/modAI y ShevArtV/mxBoard. Fijó el código fuente el 26 de octubre de 2026 y realizó 25 pruebas con PHP 8.3.6. Se usaron las clases reales de los componentes, pero en lugar de un MODX y una base de datos reales se emplearon objetos de prueba. Algunas pruebas reproducían errores a propósito, por lo que PASS no siempre significa que el componente se comporte correctamente.

Con qué permisos actúa el agente

Imagine a un gestor de contenidos al que solo se le permiten las noticias. Si se le da un asistente de IA, ¿qué permisos recibe el propio asistente? En el código se encontraron dos esquemas. En karamble se comprueban tanto el permiso para la operación como el acceso al recurso concreto. En el issue n.º 11 hubo incluso un error real: un usuario con restricciones obtenía mediante MCP datos que no veía en el panel de administración. Se corrigió en la versión 1.2.0.

En dampilov94 y rumata-estor se pueden restringir grupos de comandos, pero se ejecutan mediante un usuario de servicio con permisos de administrador. Para tareas de administrador es aceptable. Para asistentes personales de empleados con sus propias restricciones, ya no.

Datos obsoletos y respuestas perdidas

El precio en la página es de 1000 rublos, el agente lo lee y, mientras tanto, un empleado pone 1100. El agente escribe 1200 y la edición de la persona desaparece. En el código de dampilov94 no se compara el valor antiguo. En rumata-estor hay una comprobación del valor esperado con el estado STALE_STATE, y en la prueba conservó la edición humana. Pero la comprobación es opcional: si el cliente no envía la precondición, la escritura se realiza. Además, la comprobación y la escritura se hacen por separado, sin comparación atómica a nivel de base de datos.

Con los reintentos la historia es distinta. Si el servidor creó una página pero la respuesta se perdió, el agente puede repetir el comando y generar un duplicado. El RequestStore de dampilov94 guarda el estado según el identificador de la solicitud. Un duplicado paralelo recibe un 409, una solicitud completada devuelve la respuesta guardada y, si cambian los argumentos con el mismo identificador, la solicitud se rechaza. Pero con un identificador nuevo el comando se ejecutará de nuevo.

El bloqueo de archivo en rumata-estor hizo que un segundo proceso esperara 350 ms. Sin embargo, un tercer proceso que no lo conocía modificó el archivo sin problema. Lo mismo haría el panel de administración habitual de MODX. El identificador de solicitud, el bloqueo y la comprobación del valor esperado resuelven problemas distintos y no se sustituyen entre sí.

Escritura parcial y aceptación

rumata-estor envuelve la escritura de TV en una transacción: si setTVValue() devolvió false, se llama a rollback. En la prueba los valores volvieron a los originales. En modAI no se comprueba el resultado de la actualización de la caché, y en la prueba la herramienta informó de éxito con false. En karamble, tras el cambio se vuelve a leer el recurso. mxBoard separa la ejecución de la tarea de su aceptación: el ejecutor no pudo cerrar una tarea ajena.

Qué hacer al respecto

Las limitaciones son honestas: el autor aún no ha ejecutado un MODX real con MySQL y un modelo de lenguaje, y el rollback se verificó solo con un sustituto de prueba. Aun así, la conclusión es aplicable a cualquier CMS y a cualquier aplicación en la que se permita a un agente modificar datos de producción. Antes del lanzamiento, decida en nombre de quién trabaja. Exija al cliente que envíe un identificador de solicitud y el valor esperado. Compruebe el resultado de cada escritura, y no solo de la última llamada. Y no tome el «éxito» de un agente como confirmación de que todo se guardó en el sitio.