WIP Limits in Kanban: Not Magic, but...
Standard Redmine MCP covers the REST API. Real company Redmine lives in plugins.
A ready-made MCP server for Redmine usually exposes the standard REST API: projects, issues, comments and time entries.
That is enough until someone asks for an issue checklist, an Agile board column or data from an internal plugin. Then the model hits a wall: it only sees core Redmine.
Connecting Redmine to AI is easy. Connecting the Redmine your company actually runs is the hard part.
A mature Redmine install accumulates Agile, Helpdesk, CRM, checklist, reporting and custom plugins. Much of the real workflow and business data sits there, not in core Redmine.
Most MCP integrations only know the Redmine REST API. Plugin capabilities are not part of that contract unless you add them.
Why the Redmine REST API alone is not enough
What we changed: an extensible Redmine MCP
We first mapped each plugin API by hand and turned methods into MCP tools. It works for one plugin. It breaks down when you have many.
Redmine MCP runs inside Redmine and exposes a shared Registry. Other plugins register their own tools, resources, prompts and capabilities there. The MCP server does not need to know their business logic.
Instead of separate MCP servers for Redmine, Agile, Checklists and every internal module, the path is one: AI client → Redmine MCP → Redmine → the target plugin.
A plugin becomes an MCP extension, not a fork of the MCP server. If you can edit the plugin, put the integration in `lib/.../mcp.rb`, extend `RedmineMcp::ExtensionApi` and register tools. Names follow `redmine_<plugin>_<action>`.
If a third-party plugin cannot be patched, keep the adapter under `redmine_mcp/lib/redmine_mcp/extensions/`. You do not need to fork someone else's plugin only for MCP. Both paths use the same Extension API and Registry.
Part of that integration work can be done by an AI agent. Redmine MCP ships the `redmine-mcp-plugin-integration` skill: how to read plugin APIs, serializers and services; split features into tools; define input/output schemas; enforce permissions; and test the result.
Workflow: give the agent the plugin source, enable the skill, ask it to add MCP support. For a checklist plugin you may get `redmine_checklists_get_checklist`, `redmine_checklists_add_checklist_item`, `redmine_checklists_update_checklist_item` and `redmine_checklists_delete_checklist_item`.
After that, a user can ask: “Inspect issue #1234 and list incomplete checklist items.” The model picks a named tool instead of guessing the plugin's private API.
Agent-generated code is not production-ready by default. Validate against the real plugin API: permissions, schemas, success and failure paths. Tests should cover the full Registry path: validation → permission → handler → response.
Sometimes the agent is right on the first pass; sometimes it needs a plugin-specific hint. Either way is cheaper than designing every integration from scratch.
Permissions stay Redmine's. MCP authenticates with the user's API key. Access also requires the `Use MCP` permission. Projects and issues use standard visibility (`Project.visible`, `Issue.visible`). A global read-only mode is available when writes must be blocked.
Extensions should call Redmine permission checks or reuse an existing plugin REST endpoint as the current user. There is no AI superuser that bypasses Redmine ACL.
See the extension guide for implementation details and the project README for install and client setup.
Takeaway
We did not build an MCP that auto-discovers every Redmine plugin. That is the wrong target.
We built a Registry where plugins register their own tools, plus a skill detailed enough for an AI agent to draft much of the integration.
When the next plugin needs MCP support, we hand its code to an agent first. We only dig in manually if the agent fails.
Check out our other articles
5 Signs Your Team Needs Checklists in Kanban Tasks
How a Kanban Board Accelerates Projects in Redmine: From Task Chaos to Transparent Flow
