Limiti WIP nel Kanban: non magia, ma...
Il Redmine MCP standard copre la REST API. Il vero Redmine aziendale vive nei plugin.
Un server MCP pronto all’uso per Redmine di solito espone la REST API standard: progetti, segnalazioni, commenti e time entries.
Questo basta finché qualcuno non chiede una checklist di una segnalazione, una colonna di una board Agile o dati da un plugin interno. A quel punto il modello si schianta contro un muro: vede solo Redmine core.
Collegare Redmine all'IA è facile. Collegare il Redmine che la tua azienda usa davvero è la parte difficile.
Un’installazione Redmine matura accumula plugin Agile, Helpdesk, CRM, checklist, reporting e personalizzati. Gran parte del workflow reale e dei dati di business vive lì, non nel core di Redmine.
La maggior parte delle integrazioni MCP conosce solo la Redmine REST API. Le funzionalità dei plugin non fanno parte di quel contratto finché non le aggiungi.
Perché la sola Redmine REST API non basta
Cosa abbiamo cambiato: un Redmine MCP estensibile
All’inizio abbiamo mappato a mano ogni API di plugin e trasformato i metodi in strumenti MCP. Funziona per un plugin. Si rompe quando i plugin diventano molti.
Redmine MCP gira dentro Redmine ed espone un Registry condiviso. Altri plugin registrano lì i propri strumenti, risorse, prompt e capability. Il server MCP non ha bisogno di conoscere la loro logica di business.
Invece di avere server MCP separati per Redmine, Agile, Checklists e ogni modulo interno, il percorso è uno solo: client IA → Redmine MCP → Redmine → il plugin di destinazione.
Un plugin diventa un'estensione MCP, non un fork del server MCP. Se puoi modificare il plugin, metti l'integrazione in `lib/.../mcp.rb`, estendi `RedmineMcp::ExtensionApi` e registra gli strumenti. I nomi seguono il pattern `redmine_<plugin>_<action>`.
Se un plugin di terze parti non può essere patchato, mantieni l'adapter in `redmine_mcp/lib/redmine_mcp/extensions/`. Non devi fare il fork del plugin di qualcun altro solo per MCP. Entrambi i percorsi usano la stessa Extension API e lo stesso Registry.
Una parte di questo lavoro di integrazione può essere svolta da un agente IA. Redmine MCP include la skill `redmine-mcp-plugin-integration`: come leggere API, serializer e service dei plugin; suddividere le funzionalità in strumenti; definire schemi di input e output; applicare i permessi; e testare il risultato.
Workflow: dai all'agente il codice sorgente del plugin, abilita la skill e chiedigli di aggiungere il supporto MCP. Per un plugin checklist potresti ottenere `redmine_checklists_get_checklist`, `redmine_checklists_add_checklist_item`, `redmine_checklists_update_checklist_item` e `redmine_checklists_delete_checklist_item`.
Dopo di che, un utente può chiedere: «Ispeziona la segnalazione #1234 ed elenca gli elementi incompleti della checklist». Il modello sceglie uno strumento con nome invece di indovinare la API privata del plugin.
Il codice generato da un agente non è pronto per la produzione per impostazione predefinita. Va validato contro la vera API del plugin: permessi, schemi e percorsi di successo e di errore. I test dovrebbero coprire l’intero percorso del Registry: validazione → permesso → handler → risposta.
A volte l’agente ci prende al primo tentativo; altre volte ha bisogno di un suggerimento specifico del plugin. In entrambi i casi costa meno che progettare ogni integrazione da zero.
I permessi restano quelli di Redmine. MCP si autentica con la API key dell'utente. L'accesso richiede anche il permesso `Use MCP`. Progetti e segnalazioni usano la visibilità standard (`Project.visible`, `Issue.visible`). È disponibile una modalità globale read-only quando bisogna bloccare le scritture.
Le estensioni dovrebbero chiamare i controlli dei permessi di Redmine oppure riutilizzare un endpoint REST esistente del plugin come utente corrente. Non esiste un superutente IA che aggira la ACL di Redmine.
Per i dettagli implementativi consulta la guida alle estensioni e per installazione e configurazione del client il README del progetto.
Punto chiave
Non abbiamo costruito un MCP che scopre automaticamente ogni plugin di Redmine. Non è questo l’obiettivo giusto.
Abbiamo costruito un Registry in cui i plugin registrano i propri strumenti, più una skill sufficientemente dettagliata perché un agente IA possa redigere gran parte dell’integrazione.
Quando il prossimo plugin ha bisogno del supporto MCP, diamo prima il suo codice a un agente. Interveniamo manualmente solo se l’agente fallisce.
Scopri gli altri nostri articoli
5 segnali che il tuo team ha bisogno di checklist nei task Kanban
Come la board Kanban accelera i progetti in Redmine: Dal caos dei task al flusso trasparente
