MCP для Jira и GitLab: почему агенту нужна процедура, а не только API-доступ

MCP отвечает за подключение AI-агента к внешним системам: Jira, GitLab, Confluence, репозиториям, поиску, файлам и внутренним API. Skill отвечает за повторяемую рабочую процедуру: что агент должен понять, как классифицировать вход, что показать человеку, когда остановиться и какое действие можно выполнять только после подтверждения.

Для Jira и GitLab это различие критично. Недостаточно дать агенту инструмент create_issue или доступ к merge request. Нужно заранее описать, когда задачу действительно надо создавать, как не сделать дубль, какие acceptance criteria достаточны, какие комментарии нельзя публиковать автоматически и где нужен human review.

Практическая формула: сначала проектируется skill как dry-run процедура, затем проверяется на реальных кейсах, и только после этого под него подключается MCP или API-слой. MCP даёт агенту руки и глаза. Skill задаёт способ работы.

У этих слоёв разные задачи. Если смешать их в одном prompt или одном инструменте, агент может сделать технически корректное действие, но управленчески вредный результат: создать мутную задачу, продублировать issue, оставить шумный MR-комментарий или записать в backlog то, что ещё должно остаться черновиком.

Поэтому вопрос не “MCP или skill”. Правильнее спрашивать: какая повторяемая операция нужна команде и какие подключения нужны этой операции.

У Jira и GitLab уже есть API. Сама возможность прочитать issue, найти merge request или оставить комментарий обычно не является главным ограничением. Сложность начинается там, где агент должен принять рабочее решение: создать новую задачу или дополнить существующую, написать комментарий сейчас или подготовить черновик, связать MR с задачей или отметить, что связи не хватает.

Без процедуры агент может хорошо выполнить локальную команду и плохо сработать в процессе команды. Например, он создаст задачу без границ и критериев приёмки, выберет не тот тип issue, опубликует summary как факт вместо гипотезы или продублирует замечание, которое уже есть в ревью.

Для управляемой автоматизации важны не только права доступа, но и рабочие состояния: draft, needs clarification, duplicate candidate, ready for approval, publish allowed. Эти состояния живут в skill-процедуре, а не в самом MCP-сервере.

Хороший skill для Jira начинается не с записи в backlog, а с разбора сырого входа. Агент должен понять, есть ли actionable item, какой у него результат, где граница задачи, что не входит в scope и как проверить готовность.

Безопасный порядок выглядит так:

1. Принять сырой текст: переписку, заметку встречи, фрагмент ТЗ, комментарий из MR или сообщение от заказчика.
2. Выделить потенциальные actionable items и разделить их на Epic, Story, Task, Bug, Spike или “не задача”.
3. Проверить риск дубля: похожие задачи, тот же компонент, тот же результат, связанные обсуждения.
4. Подготовить preview: title, description, acceptance criteria, out of scope, labels, priority, assignee candidate и вопросы.
5. Показать, какие поля уверенные, а какие являются гипотезой.
6. Ждать подтверждения перед созданием или обновлением issue.

MCP или API здесь нужны на последних шагах: найти похожие задачи, прочитать контекст, создать или обновить issue. Но правило “создавать или не создавать” должно быть описано в skill.

Если команде сначала нужна не интеграция, а качество постановки задач, полезно связать этот процесс со страницей как ставить задачи разработчикам: там уже описаны результат, границы, out of scope и критерии приёмки.

Для GitLab похожая логика работает вокруг merge request. Агент может читать diff, обсуждения, pipeline, linked issues и reviewer comments, но публикация комментариев должна быть отдельным решением.

Skill для MR review summary должен:

• отделять summary от line-level findings;
• связывать изменения с задачей, Confluence-страницей или release note только если связь реально найдена;
• показывать риски и вопросы отдельно от подтверждённых фактов;
• проверять, что комментарий не дублирует уже опубликованное замечание;
• по умолчанию работать в dry-run;
• публиковать комментарии только после явного подтверждения.

Такой подход снижает шум в ревью. Агент помогает собрать контекст и формулировки, но не превращает MR в поток автоматических сообщений, которые команда вынуждена разбирать вручную.

Skill-first подход удобен тем, что его можно проверить до подключения write-доступов. Сначала команда видит качество preview, спорные места и границы ответственности, а уже потом решает, какие операции стоит автоматизировать.

1. Описать одну повторяемую операцию: например, “подготовить Jira issue из сырого текста” или “собрать MR review summary”.
2. Задать входы, выходы, состояния, критерии качества и запреты.
3. Проверить skill на 10-20 реальных кейсах без записи во внешние системы.
4. Уточнить guardrails: дубли, секреты, неполный контекст, спорная классификация, обязательный preview.
5. Определить минимальный набор read-действий через MCP/API.
6. Подключить write-действия только там, где preview стабильно проходит review.

Этот порядок хорошо сочетается с пилотом AI coding agents: сначала ограниченный сценарий, понятные права, метрики и условия остановки, затем расширение доступа. Для такой проверки можно использовать чек-лист пилота AI coding agents.

Чаще всего проблема возникает не из-за самого MCP, а из-за слишком раннего подключения write-действий.

• Начинать с create_issue. Если у агента нет процедуры, он будет создавать задачи по форме, но не обязательно по смыслу.
• Писать в Jira или GitLab без preview. Для backlog и MR-комментариев preview должен быть нормой, а не исключением.
• Смешивать классификацию, формулировку и запись. Сначала агент должен объяснить, что он понял и что предлагает, затем человек подтверждает действие.
• Считать MCP заменой операционной логики. MCP стандартизирует подключение, но не описывает policy команды, definition of ready, acceptance criteria и правила публикации.
• Хранить правила доступа только в тексте инструкции. Запреты должны поддерживаться правами, sandbox, approval gates и аудитом, а не только просьбой к агенту.

Перед тем как давать агенту write-доступы к Jira или GitLab, полезно пройти короткий аудит.

• Есть ли одна понятная операция, а не общий запрос “работай с Jira”?
• Понятно ли, какой вход принимает агент и какой preview он обязан показать?
• Разделены ли read-действия, draft-действия и write-действия?
• Есть ли проверка дублей и неполного контекста?
• Определены ли поля, которые агент может предлагать только как гипотезу?
• Есть ли явный approval перед созданием issue, обновлением задачи или публикацией MR-комментария?
• Понятно ли, где хранится процедура: SKILL.md, runbook, workflow spec или другой управляемый слой?

Если на эти вопросы нет ответов, начинать стоит не с MCP-сервера, а с описания skill. Когда процедура станет повторяемой, MCP будет обслуживать её как слой подключения. Подробнее о разделении Markdown-инструкций, skill-файлов и MCP-доступов см. в материале AGENTS.md и SKILL.md для AI coding agents, а про подключаемые источники и approval gates — в статье MCP-интеграции для coding agents.

Если команда хочет подключить AI-агента к Jira или GitLab, безопасный первый шаг — выбрать один повторяемый сценарий и запустить его без write-доступа. Например: подготовка Jira issue из сырого текста, поиск дублей перед созданием задачи или dry-run summary для merge request.

Результатом первого этапа должен быть не “агент получил доступ”, а проверенный workflow: какие данные он читает, какой preview показывает, какие вопросы задаёт, где останавливается и какое действие требует подтверждения. После этого можно подключать MCP/API к конкретным read/write шагам, а не открывать агенту весь процесс сразу.