WIP-лимиты в Канбане: не магия, а управляемая...
Стандартный MCP закрывает REST API. Рабочий Redmine компании живёт в плагинах.
Готовый MCP-сервер для Redmine обычно отдаёт стандартный REST API: проекты, задачи, комментарии и трудозатраты.
Этого хватает, пока кто-то не попросит чек-лист задачи, колонку Agile-доски или данные внутреннего плагина. Дальше модель упирается: она видит только ядро Redmine.
Подключить Redmine к ИИ просто. Подключить тот Redmine, которым компания реально пользуется, — уже нет.
Зрелый Redmine обрастает Agile, Helpdesk, CRM, чек-листами, отчётами и самописными модулями. Большая часть реального workflow и бизнес-данных живёт там, а не в ядре.
Большинство MCP-интеграций знает только REST API Redmine. Возможности плагинов в этот контракт сами не попадают — их нужно добавлять.
Почему одного REST API Redmine недостаточно
Что изменили: расширяемый Redmine MCP
Сначала мы вручную разбирали API каждого плагина и превращали методы в MCP tools. Для одного плагина это работает. Для десятка — уже нет.
Redmine MCP работает внутри Redmine и отдаёт общий Registry. Другие плагины регистрируют там свои tools, resources, prompts и capabilities. MCP-серверу не нужно знать их бизнес-логику.
Вместо отдельных MCP-серверов для Redmine, Agile, Checklists и каждого внутреннего модуля остаётся одна цепочка: AI-клиент → Redmine MCP → Redmine → нужный плагин.
Плагин становится расширением MCP, а не форком сервера. Если плагин можно править, интеграцию кладём в `lib/.../mcp.rb`, подключаем `RedmineMcp::ExtensionApi` и регистрируем tools. Имена идут по схеме `redmine_<plugin>_<action>`.
Если сторонний плагин менять нельзя, адаптер живёт в `redmine_mcp/lib/redmine_mcp/extensions/`. Форкать чужой плагин только ради MCP не нужно. Оба пути используют один Extension API и один Registry.
Часть этой работы может сделать AI-агент. В Redmine MCP есть skill `redmine-mcp-plugin-integration`: как читать API, serializers и services плагина; дробить функции на tools; описывать input/output schemas; проверять permissions и тестировать результат.
Сценарий: отдаём агенту исходники плагина, включаем skill, просим добавить MCP-поддержку. Для плагина чек-листов можно получить `redmine_checklists_get_checklist`, `redmine_checklists_add_checklist_item`, `redmine_checklists_update_checklist_item` и `redmine_checklists_delete_checklist_item`.
Дальше пользователь пишет: «Посмотри задачу #1234 и перечисли незакрытые пункты чек-листа». Модель выбирает именованный tool, а не угадывает внутренний API плагина.
Код от агента сам по себе не production-ready. Нужна проверка на реальном API: права, схемы, успех и ошибки. Тесты должны пройти весь путь Registry: validation → permission → handler → response.
Иногда агент попадает с первого раза, иногда нужен уточняющий контекст по плагину. В обоих случаях это дешевле, чем проектировать каждую интеграцию с нуля.
Права остаются правами Redmine. MCP аутентифицируется API-ключом пользователя. Дополнительно нужно право `Use MCP`. Проекты и задачи идут через стандартную видимость (`Project.visible`, `Issue.visible`). Есть глобальный read-only режим, когда запись нужно запретить.
Расширениям стоит вызывать проверки Redmine или существующий REST endpoint плагина от имени текущего пользователя. «Суперпользователя ИИ», который обходит ACL, быть не должно.
Детали реализации — в руководстве по расширениям, установка и клиенты — в README проекта.
Итог
Мы не сделали MCP, который сам находит любой плагин Redmine. Это неверная цель.
Мы сделали Registry, куда плагин регистрирует свои tools, и skill, достаточно подробный, чтобы AI-агент черновил большую часть интеграции.
Когда нужен MCP для следующего плагина, сначала отдаём код агенту. Вручную лезем только если агент не справился.
Смотрите другие наши статьи
5 признаков, что вашей команде нужен чек-лист задач на канбан-доске
Как канбан-доска ускоряет проекты в Redmine: От хаоса задач к прозрачному потоку
