MCP: протокол, который дал AI-агентам контекст проекта

Ограничение AI-ассистентов долгое время было не в качестве модели, а в её изоляции. Модель отлично рассуждает о коде, который ей показали, и ничего не знает о том, который не показали: о схеме базы, о задаче в трекере, о том, как проект собирается и разворачивается.

Что такое MCP и зачем он появился

Model Context Protocol — открытый протокол, описывающий, как приложение с моделью получает доступ к внешним источникам данных и инструментам. По смыслу это то же, чем стал LSP для редакторов кода: вместо N интеграций для M инструментов появляется один общий контракт.

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

Из чего состоит протокол

Архитектура намеренно простая — клиент, сервер и три вида того, что сервер предоставляет:

• Ресурсы — данные, которые агент может прочитать: содержимое файла, запись в базе, страница документации.
• Инструменты — действия, которые агент может выполнить: запустить запрос, создать задачу, вызвать сборку.
• Промпты — заготовленные шаблоны запросов под типовые сценарии сервера.

Транспорт бывает локальный, через стандартные потоки ввода-вывода, и сетевой, через HTTP. Локальный удобен для инструментов на машине разработчика, сетевой — для общих сервисов команды.

Ключевая деталь: сервер сам описывает свои возможности. Агент запрашивает список инструментов и получает их схемы — не нужно ничего зашивать в клиент.

Что меняется в реальной работе

Разница ощущается на конкретных задачах, а не в абстракции.

Без подключённого доступа к базе вопрос «почему у этих заказов пустое поле суммы» превращается в диалог: агент просит показать схему, вы копируете, он просит показать данные, вы копируете снова. С подключённым сервером он сам смотрит структуру таблиц и выполняет проверочный запрос.

То же с трекером. «Сделай по задаче номер такой-то» работает, только если агент может эту задачу прочитать — вместе с комментариями, где обычно и лежит половина требований.

Что подключать в первую очередь

Соблазн подключить всё сразу стоит побороть: каждый сервер добавляет инструментов, а слишком длинный их список ухудшает выбор. Разумный минимум:

• Файловая система проекта — база, без которой остальное малополезно.
• Git — история, диффы, ветки. Вопрос «когда и зачем это изменили» закрывается сам.
• База данных, только на чтение — схема и проверочные запросы.
• Трекер задач — требования из первоисточника.
• Документация платформы — особенно ценно для Bitrix, Drupal и других систем, где детали API меняются между версиями и модель склонна их додумывать.

Полезное правило: добавлять сервер тогда, когда вы уже дважды вручную копировали данные из этого источника.

Безопасность: решать до, а не после

MCP-сервер — это исполняемый код, которому вы даёте доступ к своим данным и от имени которого агент выполняет действия. Отсюда несколько правил, которые дешевле принять сразу:

• Отдельные учётные данные с минимальными правами. Для базы — пользователь только на чтение и только к нужным схемам.
• Никакого продакшена по умолчанию. Тестовый контур закрывает большинство сценариев отладки.
• Разделение чтения и записи. Действия, меняющие состояние, должны требовать явного подтверждения, а не выполняться в фоне.
• Понимание, откуда сервер. Сторонний сервер из репозитория — это зависимость с доступом к данным; относиться к ней стоит как к любой другой зависимости.
• Данные в запросах. Всё, что сервер вернул агенту, уходит в модель. Персональные данные и коммерческая тайна требуют отдельного решения, а не молчаливого согласия.

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

Когда MCP не нужен

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

Куда это движется

Практический смысл MCP в том, что он превращает набор разрозненных интеграций в предсказуемую инфраструктуру. Написанный однажды сервер для внутренней системы компании работает со всеми совместимыми клиентами и переживает смену инструмента. Для команд, у которых знание о проекте распределено между репозиторием, базой, трекером и вики, это оказывается важнее, чем очередное улучшение самой модели.