Límites WIP en Kanban: no es magia,...
El Redmine MCP estándar cubre la REST API. El Redmine real de empresa vive en los plugins.
Un servidor MCP listo para usar para Redmine normalmente expone la REST API estándar: proyectos, peticiones, comentarios y entradas de tiempo.
Eso basta hasta que alguien pide una checklist de una petición, una columna de un Agile board o datos de un plugin interno. Entonces el modelo se topa con un muro: solo ve el Redmine base.
Conectar Redmine con IA es fácil. Conectar el Redmine que tu empresa realmente usa es la parte difícil.
Una instalación madura de Redmine acumula plugins de Agile, Helpdesk, CRM, checklists, reporting y desarrollos propios. Gran parte del flujo real de trabajo y de los datos del negocio está ahí, no en el núcleo de Redmine.
La mayoría de las integraciones MCP solo conocen la Redmine REST API. Las capacidades de los plugins no forman parte de ese contrato a menos que las añadas.
Por qué la Redmine REST API por sí sola no basta
Qué cambiamos: un Redmine MCP extensible
Primero mapeamos a mano la API de cada plugin y convertimos sus métodos en herramientas MCP. Funciona para un plugin. Se rompe cuando tienes muchos.
Redmine MCP se ejecuta dentro de Redmine y expone un Registry compartido. Otros plugins registran allí sus propias herramientas, recursos, prompts y capacidades. El servidor MCP no necesita conocer su lógica de negocio.
En lugar de tener servidores MCP separados para Redmine, Agile, Checklists y cada módulo interno, el camino es uno: cliente de IA → Redmine MCP → Redmine → el plugin objetivo.
Un plugin se convierte en una extensión MCP, no en un fork del servidor MCP. Si puedes editar el plugin, coloca la integración en `lib/.../mcp.rb`, extiende `RedmineMcp::ExtensionApi` y registra herramientas. Los nombres siguen el patrón `redmine_<plugin>_<action>`.
Si un plugin de terceros no puede modificarse, deja el adapter en `redmine_mcp/lib/redmine_mcp/extensions/`. No necesitas hacer un fork del plugin de otra persona solo por MCP. Ambos caminos usan la misma Extension API y el mismo Registry.
Parte de este trabajo de integración puede hacerlo un agente de IA. Redmine MCP incluye la skill `redmine-mcp-plugin-integration`: cómo leer APIs, serializers y services de plugins; dividir funciones en herramientas; definir esquemas de entrada y salida; aplicar permisos; y probar el resultado.
Workflow: dale al agente el código fuente del plugin, activa la skill y pídele que añada soporte MCP. Para un plugin de checklist podrías obtener `redmine_checklists_get_checklist`, `redmine_checklists_add_checklist_item`, `redmine_checklists_update_checklist_item` y `redmine_checklists_delete_checklist_item`.
Después de eso, un usuario puede pedir: «Inspecciona la petición #1234 y enumera los elementos incompletos de la checklist». El modelo elige una herramienta con nombre en lugar de adivinar la API privada del plugin.
El código generado por un agente no está listo para producción por defecto. Valídalo contra la API real del plugin: permisos, esquemas y rutas de éxito y error. Las pruebas deben cubrir toda la ruta del Registry: validación → permiso → handler → respuesta.
A veces el agente acierta en la primera pasada; otras necesita una pista específica del plugin. En ambos casos, sigue siendo más barato que diseñar cada integración desde cero.
Los permisos siguen siendo los de Redmine. MCP se autentica con la API key del usuario. El acceso también requiere el permiso `Use MCP`. Los proyectos y las peticiones usan la visibilidad estándar (`Project.visible`, `Issue.visible`). Hay un modo global de solo lectura cuando es necesario bloquear escrituras.
Las extensiones deben llamar a las comprobaciones de permisos de Redmine o reutilizar un endpoint REST existente del plugin como usuario actual. No existe un superusuario de IA que salte la ACL de Redmine.
Consulta la guía de extensiones para los detalles de implementación y el README del proyecto para la instalación y la configuración del cliente.
Idea clave
No construimos un MCP que descubra automáticamente todos los plugins de Redmine. Ese no es el objetivo correcto.
Construimos un Registry donde los plugins registran sus propias herramientas, más una skill lo bastante detallada para que un agente de IA pueda redactar gran parte de la integración.
Cuando el siguiente plugin necesita soporte MCP, primero entregamos su código a un agente. Solo intervenimos manualmente si el agente falla.
Consulta otros artículos nuestros
5 señales de que tu equipo necesita listas de verificación en las tareas del tablero Kanban
Cómo el tablero Kanban acelera proyectos en Redmine: Del caos de tareas al flujo transparente
