MCP як зовнішній шар для Claude Code

1. Одного репозиторію вже недостатньо

У реальній роботі задача рідко виглядає як «відкрий один файл і підправ рядок». Зазвичай усе починається ззовні: хтось завів тікет у трекері, моніторинг надіслав алерт, менеджер додав дизайн, аналітик попросив звіритися зі звітом, а служба підтримки надіслала номер замовлення. Код — важлива частина історії, але все-таки не вся.

Без зовнішнього доступу Claude Code схожий на дуже сильного колегу, якого покликали розслідувати баг, але забули видати доступ до трекера, моніторингу й документації: геніальний — і працює в режимі «надішліть ще один скриншот, ще один лог, ще один шматок тексту». Для разової задачі терпимо, для повторюваного workflow — уже ні. Починається те саме офісне кардіо: браузер, скопіювати issue, вставити в Claude, знову браузер за коментарями, знову вставити. Втомлює і породжує помилки.

Різницю між внутрішнім і зовнішнім контекстом зручно побачити в таблиці:

І тут важливо не переплутати дві речі. Коли ми говоримо про внутрішні артефакти на кшталт CODEBASE_INVENTORY.md, ми описуємо сам проєкт. Коли говоримо про MCP — ми описуємо міст у зовнішній світ команди: не новий спосіб читати код, а контрольований доступ до того, що раніше ви тягнули в сесію вручну.

2. MCP простими словами

Слово protocol у назві Model Context Protocol звучить так, ніби зараз почнеться сувора лекція про мережеві пакети та страждання системних програмістів із 2003 року. На щастя, у нас спокійніше: протокол тут — домовленість про те, як Claude Code дізнається, які зовнішні інструменти доступні, як їх викликати і в якому вигляді отримувати відповідь.

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

Корисно тримати в голові три ролі. Клієнт — хто хоче запитати або викликати; у нас це Claude Code. Сервер — хто дає доступ до можливостей зовнішньої системи. Інструмент — окрема дія з назвою: list_issues, get_issue, search_docs.

Задача користувача
      ↓
Claude Code
      ↓
MCP-клієнт усередині Claude Code
      ↓
MCP-сервер
      ↓
Зовнішня система: трекер задач / моніторинг / база / docs

Якщо хочеться зовсім приземленої аналогії: Claude Code — інженер, MCP-сервер — стійка доступу в будівлі, інструменти — перепустки. Один дає подивитися задачу, інший — знайти документацію, третій — прочитати схему бази. Але стійка не зобов’язана видавати майстер-ключ від усієї будівлі. І це добре: ми якраз не хочемо перетворювати зовнішній доступ на неконтрольований атракціон.

Для навчального Workflow Kit це поки можна записати як дуже просту схему — не як канонічний формат майбутнього mcp/...json, а саме як модель ролей і доступу:

{
  "server": "issue-tracker",
  "tools": [
    "list_issues",
    "get_issue",
    "search_issues"
  ],
  "access": "read-only"
}

Це ще не канонічний формат файлу і не бойовий конфіг, а просто розумова модель: зовнішній сервер issue-tracker дає три інструменти в безпечному режимі, лише читання.

3. Від якої робочої болі MCP нас рятує

Щоб MCP не виглядав модною технологією заради самої технології, корисно чесно назвати проблему. Вона не в тому, що Claude Code «недостатньо розумний», а в тому, що частина інженерного контексту живе поза репозиторієм, а носити його вручну — довго й ненадійно.

Уявіть ситуацію в Commerce OS. У трекері зʼявилася картка COM-481: повернення замовлень у певному статусі відображаються в неправильному порядку. Без MCP ви вручну переносите її в Claude Code і просите знайти файли, яких це стосується. За десять хвилин у картці новий коментар — а в Claude його немає. Знову копіпаст.

З MCP той самий сценарій змінюється не косметично, а по суті: Claude Code не чекає копіювання — через get_issue читає актуальну задачу і зіставляє її з CODEBASE_INVENTORY.md та кодовою базою Commerce OS. Репозиторій залишається внутрішнім джерелом істини про код, трекер — зовнішнім джерелом істини про постановку задачі.

Різницю добре видно в таблиці:

Зверніть увагу: у всіх цих рядках MCP не замінює вашу голову — він прибирає рутину перенесення даних у сесію.

4. Можливості MCP для Claude Code

Коли про MCP чують уперше, легко подумати, що це щось одне — ну, наприклад, «доступ до Jira». Насправді корисніше мислити не конкретними продуктами, а класами можливостей — їх три.

Перший клас — доступ до зовнішніх даних. Issue з трекера, список PR, графік помилки з моніторингу, схема таблиці з бази даних лише для читання. Це не дія «змінити світ», а дія «зрозуміти світ»; і на старті потрібна саме вона.

Другий клас — зовнішні дії. Залишити коментар у PR, створити тікет, змінити статус задачі, запустити операцію. Навіть якщо така можливість технічно існує, наявність дії не означає, що її треба одразу дозволяти — але як клас MCP це вміє.

Третій клас — вузькоспеціалізований контекст від зовнішнього інструмента. Хороший приклад — документація: без MCP ви самі шукаєте актуальний розділ, а з інструментом Claude Code отримує саме той фрагмент довідки, який потрібен під поточне питання.

MCP додає Claude Code:
1. зовнішні дані
2. зовнішні дії
3. контекст від зовнішніх інструментів

І тут корисно розрізняти ще три речі. Дані відповідають на «що відбувається зовні?». Дії — «що я можу змінити зовні?». Контекст — «що мені потрібно знати зовні, щоб зрозуміти задачу?». Розкладіть так — і MCP перестає бути абстрактною платформною магією.

5. MCP вбудовується в уже знайомий workflow

Хороша новина: поява MCP не ламає workflow, який ви вже вибудували в попередніх модулях. Він не скасовує task spec, не замінює plan mode, не прибирає diff, не робить тести необов’язковими. Він лише додає джерело вхідних даних до планування.

Якщо розкласти це на простий сценарій, вийде така ланка. Ви формулюєте задачу. Якщо частина фактів живе ззовні, Claude Code читає їх через MCP, зіставляє з внутрішнім контекстом — кодом, інвентарем, тестами, конфігами — і повертає список затронутих областей.

Задача: розібратися з COM-481
Зовнішнє джерело: issue tracker
Внутрішні артефакти: CODEBASE_INVENTORY.md, API_MAP.md
Результат: список затронутих модулів і план перевірки
Код не змінювати

Зверніть увагу: тут нічого не ламає вже знайому інженерну дисципліну. Рішення все одно ухвалюється за знайомою схемою: задача → контекст → план → перевірка. Саме тому корисно думати про MCP не як про новий режим, а як про шар під уже знайомим процесом: усе з модулів про task specification, context hygiene та evidence-based discovery залишається в силі.

6. MCP не замінює інші артефакти

Коли зʼявляється новий сильний механізм, рука сама тягнеться використати його як заміну всьому підряд. Це нормально. Але саме в такі моменти корисно різко загальмувати й розвести ролі: MCP дуже корисний, але не замінює решту артефактів і механізмів розширення з курсу.

Нижче корисна таблиця, яку варто тримати як ментальну шпаргалку:

Цю таблицю особливо корисно перечитати, якщо в голові все починає зливатися в один великий AI-комбайн. Skill — рецепт. Subagent — роль. CLAUDE.md — правила. CODEBASE_INVENTORY.md — карта внутрішньої місцевості. MCP — перепустка до зовнішньої системи. Щойно ви розкладаєте це по поличках, архітектурні рішення стають спокійнішими.

Інколи студенти кажуть: раз Claude прочитає задачу з трекера, значить TASK_SPEC.md не потрібен. Ні, не значить. Issue в трекері — сирий зовнішній сигнал, task spec — інженерне формулювання роботи саме у вашому контексті. MCP приносить сигнал, але не оформлює задачу замість вас.

7. Наскрізний приклад: Workflow Kit та Commerce OS

Щоб усе це не залишилося на рівні абстрактної методології, давайте приземлимо картину на наш курс. Основний проєкт рівня — Claude Workflow Kit for Team, другий наскрізний контекст — Commerce OS. Пара вдала: Workflow Kit відповідає за те, як команда працює з Claude Code, а Commerce OS — реальна кодова база з багами, фічами та інтеграційними питаннями.

Уявіть, що команда Commerce OS регулярно бере задачі із зовнішнього трекера, і поки MCP немає, кожен приносить їх вручну — вхід у всіх різної якості. Workflow Kit має не «згенерувати більше коду», а стабілізувати сам вхід:

# Зовнішнє джерело для issue-analysis

Система: issue tracker Commerce OS
Режим: лише читання
Інструменти: list_issues, get_issue, search_issues
Призначення: забирати актуальні задачі без ручного копіювання

Зверніть увагу, як скромно це виглядає. Ніякого «ми побудували розподілену AI-платформу нового покоління» — команда побачила повторювану біль і оформила зовнішній доступ як інженерний артефакт.

І тут відбувається найважливіший зсув усієї лекції. Раніше репозиторій був єдиним, що Claude Code бачив напряму, а все інше ви приносили руками. Тепер у картини два джерела: внутрішня карта проєкту (CODEBASE_INVENTORY.md, код, тести) і зовнішнє джерело задач через MCP-міст. Claude Code працює з обома, а COM-481 перестає жити в браузері окремо від коду. Далі на цьому рівні ми розберемо, коли цей міст варто будувати, з яких категорій він складається і де в нього межі.