Redmine MCP verbindet einen KI-Client mit Redmine und seinen Plugins

15.09.2026

Wie Sie Redmine mit KI verbinden, ohne mit jedem Plugin zu kämpfen

Redmine Kanban

WIP-Limits im Kanban: Keine Magie, sondern gesteuerte...

Standard-Redmine-MCP deckt die REST API ab. Das echte Unternehmens-Redmine lebt in Plugins.

Ein fertiger MCP-Server für Redmine stellt normalerweise die Standard-REST-API bereit: Projekte, Tickets, Kommentare und Zeiteinträge.

Das reicht, bis jemand nach einer Ticket-Checkliste, einer Agile-Board-Spalte oder Daten aus einem internen Plugin fragt. Dann stößt das Modell an eine Wand: Es sieht nur das Redmine im Kern.

Redmine mit KI zu verbinden ist einfach. Das Redmine zu verbinden, das Ihr Unternehmen tatsächlich betreibt, ist der schwierige Teil.

Eine gewachsene Redmine-Installation sammelt Agile-, Helpdesk-, CRM-, Checklisten-, Reporting- und kundenspezifische Plugins an. Ein großer Teil des tatsächlichen Workflows und der Geschäftsdaten steckt dort und nicht im Redmine-Kern.

Die meisten MCP-Integrationen kennen nur die Redmine REST API. Plugin-Funktionen gehören nicht zu diesem Vertrag, wenn Sie sie nicht ergänzen.

Warum die Redmine REST API allein nicht ausreicht

Jedes Plugin hat seinen eigenen API-Vertrag.

(1)

Sie müssen herausfinden, ob eine REST API existiert, welche Endpunkte und Parameter sie akzeptiert, wie Antworten aussehen und welche Berechtigungen sie durchsetzt.

Ein generisches Request-Tool verlagert die Last auf das Modell.

(2)

Mit nur `request(url, params)` muss das LLM Endpunkte, gültige Werte und Antwortformen erfinden. Fokussierte Tools wie `get_checklist` oder `add_checklist_item` geben ihm einen festen, testbaren Vertrag.

Manuelle Integration skaliert nicht über viele Plugins.

(3)

Jedes neue Plugin bedeutet eine weitere Runde aus Tool-Design, Schemas, Berechtigungen, Fehlerbehandlung und Tests. Je mehr Plugins Sie haben, desto teurer wird die Pflege dieses Katalogs.

Was wir geändert haben: ein erweiterbares Redmine MCP

Zuerst haben wir jede Plugin-API von Hand erfasst und Methoden in MCP-Tools übersetzt. Das funktioniert für ein einzelnes Plugin. Bei vielen Plugins bricht es auseinander.

Redmine MCP läuft direkt in Redmine und stellt eine gemeinsame Registry bereit. Andere Plugins registrieren dort eigene Tools, Ressourcen, Prompts und Capabilities. Der MCP-Server muss ihre Geschäftslogik nicht kennen.

Statt separater MCP-Server für Redmine, Agile, Checklists und jedes interne Modul gibt es einen Weg: KI-Client → Redmine MCP → Redmine → das Ziel-Plugin.

Ein Plugin wird zu einer MCP-Erweiterung, nicht zu einem Fork des MCP-Servers. Wenn Sie das Plugin bearbeiten können, legen Sie die Integration in `lib/.../mcp.rb` ab, erweitern `RedmineMcp::ExtensionApi` und registrieren Tools. Die Namen folgen dem Muster `redmine_<plugin>_<action>`.

Wenn ein Drittanbieter-Plugin nicht gepatcht werden kann, bleibt der Adapter unter `redmine_mcp/lib/redmine_mcp/extensions/`. Sie müssen nicht das Plugin eines anderen nur wegen MCP forken. Beide Wege verwenden dieselbe Extension API und dieselbe Registry.

Ein Teil dieser Integrationsarbeit lässt sich von einem KI-Agenten erledigen. Redmine MCP liefert den Skill `redmine-mcp-plugin-integration`: wie man Plugin-APIs, Serializer und Services analysiert, Funktionen in Tools zerlegt, Ein- und Ausgabeschemas definiert, Berechtigungen erzwingt und das Ergebnis testet.

Workflow: Geben Sie dem Agenten den Plugin-Quellcode, aktivieren Sie den Skill und bitten Sie ihn, MCP-Unterstützung hinzuzufügen. Für ein Checklisten-Plugin könnten Sie `redmine_checklists_get_checklist`, `redmine_checklists_add_checklist_item`, `redmine_checklists_update_checklist_item` und `redmine_checklists_delete_checklist_item` erhalten.

Danach kann ein Benutzer fragen: „Untersuche Ticket #1234 und liste unvollständige Checklistenpunkte auf.“ Das Modell wählt ein benanntes Tool, statt die private API des Plugins zu erraten.

Von einem Agenten erzeugter Code ist nicht automatisch produktionsreif. Validieren Sie gegen die echte Plugin-API: Berechtigungen, Schemas sowie Erfolgs- und Fehlerpfade. Tests sollten den vollständigen Registry-Pfad abdecken: Validierung → Berechtigung → Handler → Antwort.

Manchmal liegt der Agent im ersten Durchgang richtig, manchmal braucht er einen plugin-spezifischen Hinweis. Beides ist günstiger, als jede Integration von Grund auf zu entwerfen.

Berechtigungen bleiben Redmine-Berechtigungen. MCP authentifiziert sich mit dem API-Schlüssel des Benutzers. Der Zugriff erfordert außerdem die Berechtigung `Use MCP`. Für Projekte und Tickets gelten die Standard-Sichtbarkeiten (`Project.visible`, `Issue.visible`). Wenn Schreibzugriffe blockiert werden müssen, steht ein globaler Read-only-Modus zur Verfügung.

Erweiterungen sollten Redmine-Berechtigungsprüfungen aufrufen oder einen bestehenden Plugin-REST-Endpunkt als aktuellen Benutzer wiederverwenden. Es gibt keinen KI-Superuser, der die Redmine-ACL umgeht.

Implementierungsdetails finden Sie im Extension Guide, Installation und Client-Setup im Projekt-README.

Kernaussage

Wir haben kein MCP gebaut, das jedes Redmine-Plugin automatisch erkennt. Das ist das falsche Ziel.

Wir haben eine Registry gebaut, in der Plugins ihre eigenen Tools registrieren, plus einen Skill, der detailliert genug ist, damit ein KI-Agent große Teile der Integration entwerfen kann.

Wenn das nächste Plugin MCP-Unterstützung braucht, geben wir seinen Code zuerst an einen Agenten. Nur wenn der Agent scheitert, steigen wir manuell ein.