如何在不与每个插件缠斗的情况下将 Redmine 连接到 AI

一开始，我们手工梳理每个插件的 API，再把方法转换成 MCP 工具。对单个插件这样做可以工作，但插件一多就撑不住了。

Redmine MCP 直接运行在 Redmine 内部，并暴露一个共享的 Registry。其他插件可以在那里注册自己的工具、资源、prompt 和 capability。MCP 服务器不需要理解它们的业务逻辑。

与其为 Redmine、Agile、Checklists 以及每个内部模块分别部署 MCP 服务器，不如只走一条链路：AI 客户端 → Redmine MCP → Redmine → 目标插件。

插件会成为 MCP 扩展，而不是 MCP 服务器的 fork。 如果你能修改插件，就把集成代码放在 `lib/.../mcp.rb` 中，扩展 `RedmineMcp::ExtensionApi` 并注册工具。命名遵循 `redmine_<plugin>_<action>`。

如果第三方插件不能打补丁，就把 adapter 放在 `redmine_mcp/lib/redmine_mcp/extensions/` 下。你不需要仅仅为了 MCP 去 fork 别人的插件。两条路径都使用同一套 Extension API 和 Registry。

其中一部分集成工作可以交给 AI 代理完成。 Redmine MCP 自带 `redmine-mcp-plugin-integration` skill，说明了如何阅读插件 API、serializer 和 service，如何把功能拆成工具，如何定义输入输出 schema，如何施加权限，以及如何测试结果。

Workflow 很简单：把插件源码交给代理，启用这项 skill，然后让它添加 MCP 支持。对于 checklist 插件，你可能会得到 `redmine_checklists_get_checklist`、`redmine_checklists_add_checklist_item`、`redmine_checklists_update_checklist_item` 和 `redmine_checklists_delete_checklist_item`。

之后，用户就可以提出：“检查问题 #1234，并列出未完成的检查清单项。” 模型会选择一个有明确名称的工具，而不是去猜插件的私有 API。

代理生成的代码默认并不等于生产可用。 你仍然需要对照真实插件 API 做验证：权限、schema，以及成功和失败路径。测试应覆盖完整的 Registry 路径：校验 → 权限 → handler → 响应。

有时代理第一次就能做对，有时它需要一点插件特定的提示。不管哪种情况，这都比每次从零设计集成便宜。

权限仍然是 Redmine 的权限。 MCP 使用用户的 API key 认证。访问还要求具备 `Use MCP` 权限。项目和问题继续使用标准可见性检查（`Project.visible`, `Issue.visible`）。当需要阻止写入时，还可以启用全局只读模式。

扩展应调用 Redmine 的权限检查，或者以当前用户身份复用现有的插件 REST endpoint。不存在一个可以绕过 Redmine ACL 的“AI 超级用户”。

实现细节请参见 extension guide，安装和客户端配置请参见 project README。

我们并没有去构建一个能自动发现所有 Redmine 插件的 MCP。那不是正确的目标。

我们构建的是一个让插件自行注册工具的 Registry，以及一项足够详细、能让 AI 代理起草大部分集成工作的 skill。

当下一个插件需要 MCP 支持时，我们会先把它的代码交给代理。只有代理失败时，才由人工深入处理。