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

1. Тут легко переборщити

Коли ви вперше дізнаєтеся про MCP, він легко здається ідеальним розв’язанням майже будь-якої проблеми. Копіювати issue вручну? MCP. Відкрити документацію? MCP. Є лог помилки? Теж MCP. Тут дуже легко почати ставитися до нього як до універсальної викрутки, якою заодно можна варити каву. А далі — зайві налаштування, зайві токени, зайві ризики й нуль користі.

Проблема тут не в самому MCP. Проблема в тому, що у розробника швидко з’являється хибне відчуття зрілості процесу: ніби сам факт підключення зовнішнього сервера робить 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 з джерелом

Зверніть увагу: тут немає жодного слова про «автоматично оновлювати робочий процес усієї компанії». Це дуже локальне й тверезе рішення: так, 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 вручну.

Це хороший інженерний стиль із трьох причин. Рішення прозоре для будь-кого, хто відкриє задачу пізніше. Є резервний варіант: MCP не працює — процес не зупиняється намертво. Відразу видно межу інтеграції.

Можна фіксувати це і поруч зі skillʼом Workflow Kit. В описі issue-analysis зазначити: при read-only MCP skill бере звідти поля issue, але не змінює зовнішній стан. Це вже не мовчазне знання автора, а частина підтримуваного процесу.

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

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

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

Надходження issue з трекера — так, через read-only MCP.
Разовий локальний лог — ні, вручну.
Зміна статусу issue — ні, окреме узгодження.

І ось у цей момент закривається головна думка лекції. Рішення «підключати MCP чи ні» — це не про моду і не про те, як з боку виглядає workflow. Це три чесні питання підряд: чи усуваю я реальну проблему, чи повторюється вона, чи можу я обмежити й перевірити інтеграцію. Пройшли всі три — вручну ви вже натренувалися, час автоматизувати. Провалився хоч один — залишайтеся на копіюванні-вставленні без почуття провини. Так Workflow Kit для Commerce OS набирає не модні інтеграції, а лише ті, що заслужили місце.