Правило «сначала вручную» для MCP

1. Здесь легко переборщить

Когда вы впервые узнаёте про MCP, он легко выглядит идеальным решением почти любой боли. Копировать issue руками? MCP. Открыть документацию? MCP. Есть лог ошибки? Тоже MCP. Тут очень легко начать относиться к нему как к универсальной отвёртке, которой заодно можно варить кофе. А дальше — лишние настройки, лишние токены, лишние риски и ноль пользы.

Проблема тут не в самом MCP. Проблема в том, что у разработчика быстро появляется ложное ощущение зрелости процесса: будто сам факт подключения внешнего сервера делает workflow «профессиональным». Наоборот. Профессиональный workflow начинается с вопроса: какую конкретную боль я убираю?

Возьмём наш сквозной контекст. Команда работает над Commerce OS, в Workflow Kit есть skill issue-analysis — он превращает входящую задачу в task spec. Пока разработчик руками открывает issue в трекере, копирует заголовок, описание, иногда комментарии, вставляет в Claude и просит собрать черновик TASK_SPEC.md. Раз в месяц — не проблема. Десять раз в день — повторяющаяся точка трения.

Вот именно в таких местах и стоит думать про MCP. Не «куда бы ещё прикрутить технологию», а «где повторяется ручной шаг, что съедает время и плодит ошибки».

2. Формула «сначала вручную»

Это правило звучит слишком просто, поэтому новички часто недооценивают его силу. Кажется, что «сначала вручную» — это шаг назад, капитуляция перед автоматизацией. На деле это нормальная инженерная дисциплина: пока вы не сделали действие руками несколько раз, вы не понимаете, что автоматизируете, где настоящая боль и где её границы.

Формула курса простая:

Слово «управляемым» здесь важнее, чем кажется. Иногда разработчики видят повторяемую задачу и сразу бегут строить интеграцию. Но если у интеграции нет понятного scope, нет доверия к серверу, нет безопасной работы с credentials и нет способа проверить, что данные пришли корректно, вы не автоматизировали работу — вы автоматизировали риск.

Сравните два сценария. В первом у вас один короткий stack trace, который вы просто вставили в Claude и за две минуты получили гипотезы. Во втором — постоянная работа с живыми issue из трекера, где важны статус, метки, комментарии и актуальное описание задачи. В первом случае MCP избыточен. Во втором он вполне может оказаться разумным.

Эту мысль удобно держать в совсем короткой схеме:

flowchart TD
    A[Нужны внешние данные?] -->|Нет| B[Работаем без MCP]
    A -->|Да| C[Это повторяется регулярно?]
    C -->|Нет| B
    C -->|Да| D[Можно ограничить scope и проверить результат?]
    D -->|Нет| B
    D -->|Да| E[Рассматриваем read-only MCP]

Обратите внимание: схема заканчивается не на «срочно подключаем всё», а куда скромнее: рассматриваем read-only MCP. То есть даже положительный ответ — не карт-бланш, а обоснованный следующий шаг.

3. Три вопроса, которые решают почти всё

Чтобы решение было не интуитивным, а инженерным, полезно прогонять любую ситуацию через три измерения: ценность, повторяемость, управляемость. Если хотя бы одно из них проваливается, с MCP лучше не спешить.

Теперь разберём их по-человечески. Ценность — это не «было бы прикольно», а всегда конкретная боль. «Каждый день руками копируем пять полей из issue tracker, забываем комментарии, теряем контекст» — хорошее описание. «Хотим современную архитектуру» — плохое: архитектура не самоцель, иначе вы начнёте строить спутник, чтобы открыть консервную банку.

Повторяемость отвечает на неприятный, но полезный вопрос: а вы точно будете делать это ещё много раз? Заглянуть в одну ошибку дешевле руками. MCP окупается, когда действие стало частью цикла.

Управляемость — это ваш фильтр от неприятностей: доступ только на чтение, ограниченный список tools, понятный источник для сверки. Нет ясного ответа — интеграция сырая.

4. Кейс Workflow Kit: MCP для issue tracker

Вот здесь теория наконец становится полезной, потому что её можно прогнать через реальную ситуацию. В Workflow Kit есть skill issue-analysis. Команда думает: добавить ли mcp/issue-tracker.json, чтобы не копировать вручную данные из задач Commerce OS?

Смотрим по трём вопросам. Ценность зелёная. Поля живые: заголовок, описание, статус, метки, иногда комментарии. Ручное копирование хрупкое — забыл комментарий, вставил старую формулировку, утащил не тот номер задачи. Повторяемость зелёная: не разовый сценарий, а рабочий ритм команды. Управляемость — тоже, если начать с чтения. Менять статус, писать комментарии, закрывать задачи сейчас не нужно. Минимум: list_issues, get_issue, search_issues.

Так появляется вполне зрелое решение:

## Решение по MCP

Источник: issue tracker Commerce OS
Нужен ли MCP: да
Режим: read-only
Причина: задачи приходят регулярно, данные живые, ручной copy-paste повторяется
Проверка: сверять id и заголовок issue с источником

Заметьте: здесь нет ни слова про «автоматически обновлять workflow всей компании». Это очень локальное и трезвое решение: да, read-only issue tracker MCP полезен.

5. Иногда лучше остаться без MCP

Вот здесь как раз начинается взрослая часть темы. Важно уметь сказать не только «да», но и спокойно, без чувства вины, «нет». Это очень профессиональный навык: он экономит время, деньги и нервные клетки.

Представьте, что у вас один лог ошибки из локального запуска. Вы в терминале, проект открыт, ошибка перед глазами. Поднимать ради этого MCP к monitoring-системе — как вызывать грузовой кран, чтобы переставить табуретку: технически возможно, но соседи начнут задавать вопросы. То же с разовым обращением к документации: нужен фрагмент из changelog — проще вставить кусок в сессию, чем поднимать внешний слой. Правило «сначала вручную» именно поэтому и работает.

Есть ещё более жёсткие случаи. Сервер сомнительный, credentials не ограничить, output огромный и засоряет контекст, результат не проверить быстро. Тут MCP не лишний — вредный: красивая схема и непрозрачное поведение.

Полезно смотреть на такие случаи в таблице решений:

Паттерн простой: MCP хорош там, где есть регулярность и границы. Где разовость и неопределённость — мешает.

6. Read-only почти всегда первый шаг

Очень часто разработчик рассуждает так: «Раз подключаем issue tracker, давайте сразу и статусы менять, и комментарии писать». Звучит естественным продолжением — а на деле это уже совершенно другой класс риска, и именно здесь многие команды случайно делают слишком большой шаг.

Даже один и тот же сервис живёт в двух принципиально разных режимах. Аналитический: прочитать список задач, открыть карточку, найти issue по фильтру. Меняющий внешний мир: закрыть задачу, перевести статус, оставить комментарий, назначить исполнителя. Формально «тот же трекер», по риску — две разные планеты.

Поэтому курс и предлагает почти всегда начинать с read-only. Сначала докажите, что интеграция полезна и результат проверяем, а write-операции решайте позже.

В контексте Commerce OS это выглядит так: get_issue нужен, search_issues тоже. А «перевести COM-481 в Done после merge» — уже совсем другая история: появляется side effect, и учебный вопрос превращается в организационную политику. Не продолжение того же шага, а отдельное инженерное решение.

7. Фиксируем решение в артефактах проекта

Одна из самых частых слабостей у начинающих — хорошие решения принимаются «в голове» и через два дня исчезают. Вчера вы твёрдо понимали, зачем нужен MCP и где границы, а сегодня открыли проект — и не помните, почему трекер подключать можно, а комментарии писать нельзя. Поэтому такие решения стоит фиксировать письменно — в task spec или в заметки рядом со skill’ом. Есть задача на разбор нового issue — добавьте в TASK_SPEC.md блок про внешний контекст.

## Внешний контекст

Нужен доступ к issue COM-481 из трекера.
Использовать только read-only MCP issue-tracker.
Не менять статус issue и не писать комментарии.
Если MCP недоступен, взять текст issue вручную.

Это хороший инженерный стиль по трём причинам. Решение прозрачно для любого, кто откроет задачу позже. Есть fallback: MCP не работает — процесс не встаёт намертво. Сразу видна граница интеграции.

Можно фиксировать это и рядом со skill’ом Workflow Kit. В описании issue-analysis указать: при read-only MCP skill берёт оттуда поля issue, но не меняет внешнее состояние. Это уже не молчаливое знание автора, а часть поддерживаемого процесса.

8. Решение на трёх ситуациях из Commerce OS

Чтобы правило действительно закрепилось, полезно прогнать его не на абстракции, а на нескольких очень земных сценариях Commerce OS. Тогда в голове останется рабочая привычка, а не лозунг. Три ситуации, три решения:

## Решения команды

Issue intake из трекера — да, через read-only MCP.
Разовый локальный лог — нет, вручную.
Изменение статуса issue — нет, отдельный approval.

И вот в этот момент закрывается главная мысль лекции. Решение «подключать MCP или нет» — это не про моду и не про то, как выглядит workflow со стороны. Это три честных вопроса подряд: убираю ли я реальную боль, повторяется ли она, могу ли я ограничить и проверить интеграцию. Прошли все три — вручную вы уже наигрались, пора автоматизировать. Провалился хоть один — оставайтесь на копипасте без чувства вины. Так Workflow Kit для Commerce OS набирает не модные интеграции, а только те, что заслужили место.