MCP как внешний слой Claude Code

1. Одного репозитория уже недостаточно

В реальной работе задача редко выглядит как «открой один файл и поправь строчку». Обычно всё начинается снаружи: кто-то завёл тикет в трекере, monitoring прислал алерт, менеджер приложил дизайн, аналитик попросил свериться с отчётом, а поддержка прислала номер заказа. Код — важная часть истории, но всё-таки не вся.

Без внешнего доступа Claude Code похож на очень сильного коллегу, которого позвали расследовать баг, но забыли выдать доступ к трекеру, monitoring и документации: гениальный — и работающий в режиме «пришлите ещё скриншот, ещё лог, ещё кусок текста». Для разовой задачи терпимо, для повторяющегося 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, график ошибки из monitoring, схема таблицы из read-only базы. Это не действие «поменять мир», а действие «понять мир»; и на старте нужен именно он.

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