1. Назви серверів запам’ятовувати марно
Якщо починати знайомство з MCP зі списку конкретних серверів, дуже швидко виникає хибне відчуття, що вам треба запам’ятати чийсь зоопарк інтеграцій. Один ходить в issue tracker, інший читає pull request, третій знає документацію. За десять хвилин усе це злипається в затишну хмару під назвою «щось там про зовнішні інструменти». Запам’ятовувати чужий зоопарк інтеграцій — глухий кут.
Проблема в тому, що такий спосіб мислення погано допомагає в реальній роботі. Припала задача в Commerce OS — ви думаєте не «як називається модний MCP-сервер цього тижня», а «прочитати issue», «побачити diff PR», «зрозуміти, що палає в моніторингу». Тобто не брендом інструмента, а типом робочого болю.
Тому корисніше запам’ятовувати не назви, а три запитання до будь-якої категорії:
1. Який зовнішній сигнал або дані вона дає?
2. Claude через неї лише читає — чи вже може щось змінювати?
3. Як цей сигнал вбудовується в наш процес — task spec, план, diff, tests, review?
Якщо на ці три запитання є відповідь, категорія вам зрозуміла. Якщо відповіді немає — значить ви поки дивитеся на MCP як на вітрину, а не як на робочий інструмент.
Гарна новина в тому, що в більшості команд набір категорій досить стабільний. У проєкті на кшталт Commerce OS майже завжди є задачі, PR, логи, документація, іноді база, браузерна перевірка, комунікації. Саме цю карту давайте і зберемо.
2. Головні категорії MCP-можливостей
Якщо дивитися на MCP очима розробника, швидко з’ясовується, що більшість сценаріїв укладається в кілька повторюваних кошиків — це зручніше, ніж пам’ятати продукти. Таблицю нижче тримайте в голові: вона не про бренди, а про типи задач.
| Категорія | Що Claude зазвичай читає | Що іноді може робити | Гарний безпечний старт |
|---|---|---|---|
| Трекер задач | issue, статуси, labels, коментарі | змінювати статус, створювати issue, коментувати | читати і шукати issue |
| Система PR / source control | diff, коментарі рев’ю, статуси перевірок | коментувати, закривати, merge | читати diff і коментарі |
| Моніторинг / incidents | alert, stack trace, метрики, логи | acknowledge, silence, змінювати статус інциденту | читати сигнали й логи |
| Docs lookup | офіційні docs, changelog, приклади API | зазвичай лише читання | шукати й читати документацію |
| Read-only DB | схему, таблиці, safe select-запити | update/delete/insert, запуск міграцій | читати схему та безпечні вибірки |
| Browser / design | сторінку, скриншоти, стан інтерфейсу, дизайн-артефакти | клікати, заповнювати форми, робити кроки сценарію | огляд сторінки й візуального контексту |
| Комунікації команди | треди, повідомлення, обговорення | надсилати повідомлення, створювати треди | краще починати дуже обережно |
| Platform / deployment | список релізів, статуси середовищ, збірки | деплой, рестарт, rollback | лише читання статусів |
У цій таблиці найважливіше не лівий стовпець, а два центральні. Вони показують, що в категорії майже завжди є два режими життя. Трекер задач буває джерелом даних для TASK_SPEC.md — а буває місцем, де Claude змінює статус. PR-система буває вікном у diff — а буває робить merge. База буває schema і safe select — а буває виконує зміни. Категорія нічого не обіцяє: розумійте, підключаєте ви читання чи дію.
Для курсу і для здорової командної гігієни стартова позиція майже завжди одна: спочатку ліва, нудна, акуратна половина. Read-only не виглядає героїчно. Зате потім ніхто не прокидається вранці з думкою: «Цікаво, хто вчора дав ШІ право закривати production-інциденти?»
3. Трекер задач і PR: старт для Commerce OS
На кейсі з read-only issue-tracker наступний логічний крок — подивитися на сусідню поверхню, без якої повсякденна робота все одно не складається: PR і diff. Саме тому issue tracker і PR / source control дають максимум користі за мінімуму ризику: один відповідає за постановку задачі, другий — за те, що змінюється в коді.
Із задачею COM-481 це видно одразу: прочитати опис issue і подивитися пов’язаний PR. Без MCP ви тягнете це руками через браузер і чат. З read-only Claude отримує живий текст issue і коментарі рев’ю.
У Workflow Kit це особливо зручно стикується з уже знайомими артефактами. skills/issue-analysis/SKILL.md спирається на живі дані з issue tracker, а не на вставлений вручну текст. agents/reviewer.md читає не лише локальний diff, а й коментарі до PR. Зверніть увагу: поки йдеться саме про читання, а не про дію.
Невеликий фрагмент робочої схеми може виглядати так:
COM-481 # ідентифікатор задачі в Commerce OS
↓
get_issue # читаємо живий опис і кроки відтворення
↓
TASK_SPEC.md # перетворюємо ticket на інженерну постановку
↓
diff і review notes # порівнюємо план із реальними змінами
Ця пара категорій добре працює разом, бо відповідає на два дуже приземлені запитання. Трекер: що хотіли змінити? Diff: що насправді змінили? Коли у вас є обидві відповіді, Claude працює не у вакуумі, а всередині реального циклу розробки.
4. Моніторинг і docs lookup: біль і норма
Після задач і PR логічно перейти до іншої пари категорій, які в роботі часто йдуть поруч. Моніторинг дає сигнал, що щось пішло не так. Docs lookup — орієнтир, як система має себе поводити. Одне — фактичний біль, інше — очікувана поведінка.
Моніторинг хороший тим, що приносить не думку, а симптом. Alert, stack trace, сплеск помилок, просідання метрики чесніші, ніж «здається, сервіс пригальмовує». Для debugging Claude бачить не лише код, а й зовнішній слід проблеми. Спочатку evidence, потім гіпотеза.
Docs lookup працює інакше — він про те, як влаштований зовнішній API, як бібліотека радить мігрувати налаштування, який параметр застарів. Docs дають нормативний контекст, monitoring — фактичний сигнал. Документація буває красивою і впевненою, а код усе одно працює інакше. Лог, навпаки, жорсткий і неусміхнений — зате правдивий.
| Категорія | На яке запитання відповідає | Що дає в роботу Claude |
|---|---|---|
| Моніторинг | Де і як саме болить? | alert, лог, stack trace, метрику |
| Docs lookup | Як це має працювати за офіційною версією? | changelog, reference, приклад API |
Для Commerce OS це означає просту річ. Задача починається з помилки — monitoring збирає факти. Упирається у зовнішній фреймворк або SDK — docs lookup не дає гадати з пам’яті. Пара не замінює кодову базу, але робить розмову точнішою.
Щоб категорія docs lookup не лишилася абстракцією, корисно побачити, як вона виглядає на конкретному MCP-сервері. Гарний приклад із реальної екосистеми — Context7 від Upstash. Він уміє одну дуже корисну річ: підтягувати актуальну, version-specific документацію популярних бібліотек просто в контекст Claude. LLM за замовчуванням спирається на документацію з навчальних даних, а вона майже завжди застаріла: трохи вигадані API, трохи застарілі сигнатури. Context7 іде за свіжими docs у зовнішнє джерело і приносить у розмову.
Capability surface тут приємно вузький: два інструменти — один перетворює назву бібліотеки на внутрішній ідентифікатор, другий витягує за ним фрагмент документації. Жодних write-операцій, деплою, доступу до коду. Ідеальна ілюстрація принципу «спочатку read-only»: живий нормативний контекст, blast radius майже нульовий. Підключається як звичайний MCP-сервер — через віддалений URL або локальний запуск пакета; конкретні команди залежать від версії та описані в його документації. Важлива не рядок встановлення, а тип болю: «як має працювати бібліотека за своєю актуальною версією, а не за тим, як її пам’ятає модель із навчання».
5. Read-only DB, browser, design і комунікації
Є категорії MCP, які трохи далі від звичного «issue → code → PR», але все одно відповідають на інші типи запитань. Read-only база: що реально зберігається і як пов’язано? Браузер і дизайн: що бачить користувач і що задумав дизайнер? Комунікації: що команда вже обговорювала?
Read-only база особливо хороша не для «магічних SQL-пригод», а для акуратної перевірки схеми та даних: Claude бачить поле в таблиці, розуміє зв’язки, перевіряє результат безпечного select. Для новачка це важлива розвилка: база через MCP — не запрошення виконувати update і delete. Спочатку це спосіб краще зрозуміти дані, а не швидше їх зіпсувати.
Браузерні та дизайн-категорії розв’язують інший біль. Код буває формально правильним, а UI поводиться дивно. Браузерний контекст показує сторінку, стан форми, результат дії. Дизайн-контекст дає звіритися з тим, що має вийти.
Із комунікаційними інструментами треба бути особливо тверезим. Прочитати тред корисно. Але щойно інструмент уміє писати повідомлення від вашого імені, відповідальність різко змінюється. На старті — джерело контексту, а не рупор для авто-відповідей.
Те саме стосується платформи та деплою. Зчитати статус релізу — одне. Дати ШІ право натиснути deploy — зовсім інше. Саме тому мислити категоріями корисно: ви бачите не «підключили MCP», а зміст конкретного зовнішнього каналу.
6. Один сервер буває і безпечним, і небезпечним
Це, мабуть, найважливіша думка всієї лекції. Небезпека MCP майже ніколи не визначається лише однією категорією. Її визначають конкретні tools всередині. Один і той самий сервер буває нудним і безпечним у read-only — і дуже жвавим джерелом проблем, якщо дати йому право змінювати зовнішній світ.
Подивіться на це прямо:
| Категорія | Read-only приклад | Приклад із зовнішньою дією |
|---|---|---|
| Issue tracker | get_issue, search_issues | update_issue, transition_issue |
| PR / source control | get_diff, list_comments | post_comment, merge_pr |
| Моніторинг | get_alert, get_metrics | acknowledge_alert, silence_alert |
| DB | describe_schema, select_rows | update_rows, delete_rows |
| Комунікації | read_thread | post_message |
| Deployment | list_releases, get_build_status | deploy_release, rollback_release |
Якщо уважно подивитися на цю таблицю, одразу стає ясно, чому курс так уперто штовхає вас до мінімально достатніх прав. Потрібна issue? Читайте issue. Потрібен diff? Читайте diff. Потрібен alert? Читайте alert. Приріст якості контексту величезний, а blast radius малий.
Для команди Commerce OS розумний старт може бути описаний у Workflow Kit буквально кількома рядками:
### MCP-правило команди
- issue tracker — лише читання
- PR-система — лише читання
- monitoring — лише читання
- база даних — лише схема і safe select
Це не виглядає героїчно, зате дуже добре відбиває дорослий інженерний підхід. Спочатку вчимося отримувати якісний зовнішній контекст. Лише потім, якщо справді є повторюваний біль і зрозумілий контроль, обговорюємо зовнішні write-actions. Не навпаки.
7. Карта MCP-можливостей для Workflow Kit
Коли мислення категоріями вже з’явилося, наступний корисний крок дуже простий: не тримати цю карту лише в голові. У README.md Workflow Kit додайте коротку таблицю: не лише «що підключити», а й навіщо, у якому режимі і кому це потрібно.
Гарний чернетковий варіант такої таблиці може виглядати так:
## MCP-карта команди
| Категорія | Навіщо підключаємо | Перший режим | Хто використовує |
|---------------|-------------------------------------|--------------|------------------|
| issue tracker | робити TASK_SPEC.md із живих issue | read-only | issue-analysis skill |
| PR / git | читати diff і коментарі рев’ю | read-only | reviewer agent |
| docs lookup | звіряти офіційні docs і changelog | read-only | людина / дослідник |
| monitoring | бачити alerts і stack trace | read-only | debugging workflow |
Зверніть увагу: тут немає спроби перелічити весь світовий ринок MCP — і це прекрасно. Хороша карта допомагає вирішити: що реально потрібно для процесу, в якому режимі підключати, хто буде користуватися. Не заповнюється «навіщо підключаємо» — сервер поки не потрібен. Не заповнюється «перший режим» — ви перескакуєте в небезпечну частину.
Для нашого курсу це особливо важливо, бо Workflow Kit — не музей красивих конфігів. SKILL.md для аналізу issue, agents/reviewer.md для локального review, TASK_SPEC.md для постановки вже існують як осмислені артефакти. MCP має підсилювати їх, а не жити поруч як гордий, але марний екзотичний звір.
І коли ви починаєте дивитися на MCP саме так, запам’ятовуйте не зоопарк серверів, а три запитання до будь-якої категорії: який зовнішній сигнал вона дає, чи читає Claude через неї, чи вже змінює, куди це вбудовується в цикл — task spec, план, diff, tests, review. Відповіли на всі три — категорія у вас в руках, і неважливо, як назвуть завтрашній модний сервер цієї ж корзини.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ