MCP-серверы и сценарии разработчика

1. Названия серверов запоминать бесполезно

Если начинать знакомство с MCP со списка конкретных серверов, очень быстро возникает ложное ощущение, что вам надо запомнить чей-то зоопарк интеграций. Один ходит в issue tracker, другой читает pull request, третий знает документацию. Через десять минут всё это слипается в уютное облако под названием «что-то там про внешние инструменты». Запоминать чужой зоопарк интеграций — тупик.

Проблема в том, что такой способ мышления плохо помогает в реальной работе. Прилетела задача в Commerce OS — вы думаете не «как называется модный MCP-сервер этой недели», а «прочитать issue», «увидеть diff PR», «понять, что горит в monitoring». То есть не брендом инструмента, а типом рабочей боли.

Поэтому полезнее запоминать не названия, а три вопроса к любой категории:

1. Какой внешний сигнал или данные она даёт?

2. Claude через неё только читает — или уже может что-то менять?

3. Как этот сигнал встраивается в наш процесс — task spec, план, diff, tests, review?

Если на эти три вопроса есть ответ, категория вам понятна. Если ответа нет — значит вы пока смотрите на MCP как на витрину, а не как на рабочий инструмент.

Хорошая новость в том, что у большинства команд набор категорий довольно стабилен. В проекте вроде Commerce OS почти всегда есть задачи, PR, логи, документация, иногда база, браузерная проверка, коммуникации. Именно эту карту давайте и соберём.

2. Главные категории MCP-возможностей

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

В этой таблице важнее всего не левая колонка, а две центральные. Они показывают, что у категории почти всегда есть два режима жизни. Трекер задач бывает источником данных для 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. Monitoring и docs lookup: боль и норма

После задач и PR логично перейти к другой паре категорий, которые в работе часто идут рядом. Monitoring даёт сигнал, что что-то пошло не так. Docs lookup — ориентир, как система должна себя вести. Одно — фактическая боль, другое — ожидаемое поведение.

Monitoring хорош тем, что приносит не мнение, а симптом. Alert, stack trace, всплеск ошибок, просадка метрики честнее, чем «кажется, сервис подтормаживает». Для debugging Claude видит не только код, но и внешний след проблемы. Сначала evidence, потом гипотеза.

Docs lookup работает иначе — он про то, как устроен внешний API, как библиотека рекомендует мигрировать настройки, какой параметр устарел. Docs дают нормативный контекст, monitoring — фактический сигнал. Документация бывает красивой и уверенной, а код всё равно работает иначе. Лог, наоборот, жёсткий и неулыбчивый — зато правдивый.

Для 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 — и очень бодрым источником проблем, если дать ему право менять внешний мир.

Посмотрите на это в лоб:

Если внимательно посмотреть на эту таблицу, сразу становится ясно, почему курс так упорно толкает вас к минимально достаточным правам. Нужна 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. Ответили на все три — категория у вас в руках, и неважно, как назовут завтрашний модный сервер этой же корзины.