Модель — это мозг агента. Она рассуждает, планирует, пишет код. Но сама по себе она умеет ровно одно: превращать текст на входе в текст на выходе. Спросите её про содержимое вашей базы — она не знает. Попросите дёрнуть внутренний API — она напишет вам код запроса, но не выполнит его. Мозг без рук.
Продукт-инженер, который живёт в связке с агентом, рано или поздно упирается в этот предел. Агент отлично рассуждает о вашей системе — по тому, что вы ему рассказали. Но он не видит её. И тогда возникает вопрос: как дать ему руки, чтобы он не только рассуждал о системе, но и дотягивался до неё.
Ответ, который за пару лет стал индустриальным стандартом, — MCP, Model Context Protocol. Это статья про то, как оснастить агента и не отстрелить ногу. Не про то, как написать MCP-сервер (это отдельный крафт, ссылки в конце) — про то, зачем это вам как продукт-инженеру и где проходят границы.
Проблема до MCP: каждый инструмент — свой костыль
Идея «дать модели инструменты» старше MCP. Function calling, плагины, самодельные обёртки — все давали агенту какую-то способность к действию. Проблема была в том, что каждая интеграция писалась заново.
Хотите, чтобы агент читал файлы — пишете обёртку под свой агент. Хотите, чтобы ходил в Postgres — ещё одна обёртка, под тот же агент, но с нуля. Сменили агент с одного на другой — переписываете обе обёртки, потому что формат описания инструментов у них разный. Появился новый инструмент — новая интеграция под каждого агента, которым вы пользуетесь.
Получалась матрица M агентов × N инструментов, и в каждой клетке — свой код. Это ровно та комбинаторика, которую в вебе решил HTTP, а в базах — драйверы с общим интерфейсом. Пока такого общего разъёма нет, каждый обвязывает своего агента руками, и эти руки ни с кем не совместимы.
Идея MCP: один протокол, серверы как адаптеры
MCP — это стандарт (изначально от Anthropic, сейчас открытый и поддержанный многими), который убирает матрицу. Вместо «каждый агент под каждый инструмент» появляется один общий разъём между ними.
Аналогия, которая обычно всё ставит на место: MCP — это USB-C для инструментов агента. Раньше у каждого устройства был свой разъём и свой кабель. USB-C задал один физический контракт: любое устройство с этим разъёмом подключается к любому хосту с этим разъёмом. MCP делает то же для пары «агент ↔ инструмент». Написали инструмент один раз по протоколу — он работает с любым MCP-совместимым агентом. Ваш агент понимает протокол — он подключается к любому инструменту, написанному под него.
Матрица M × N схлопывается в M + N. Инструмент пишется один раз. Агент учит протокол один раз. Дальше они соединяются как разъём с разъёмом.
Сервер и клиент: кто есть кто
В протоколе две стороны.
MCP-сервер — это адаптер к одному инструменту или источнику данных. Он оборачивает файловую систему, или базу, или git, или внешний API и выставляет наружу три вещи в терминах протокола: tools (действия, которые агент может выполнить — «прочитай файл», «выполни запрос»), resources (данные, которые он может прочитать — содержимое, схемы) и prompts (заготовленные сценарии). Сервер — маленький, узкий, знает про один мир.
MCP-клиент живёт внутри агента (Claude Code, IDE, ваше приложение с моделью). Он умеет discovery: подключился к серверу, спросил «что ты умеешь», получил список инструментов с описаниями и типами аргументов. Дальше модель видит эти инструменты как часть своего арсенала и сама решает, когда какой дёрнуть.
Ключевое: модель не знает деталей сервера. Она видит инструмент query_database с описанием и параметрами — и всё. Как именно сервер ходит в базу, какие там креды, какой пул соединений — за протоколом. Ровно как код, работающий через порт, не знает, что за адаптером: HTTP, очередь или заглушка в тесте. MCP — это port/adapter, поднятый на уровень оснастки агента.
Что бывает: файлы, база, git, HTTP
Экосистема серверов уже большая, но полезнее держать в голове не список, а несколько типовых классов — по ним же вы будете оценивать риск.
- Файловая система. Агент читает и пишет файлы в оговорённой директории. Самое частое — и самое безобидное, пока директория ограничена.
- База данных. Агент выполняет запросы, читает схему, иногда пишет. Тут уже интересно: read-only-подключение и full-access — это две разные вселенные по последствиям.
- git. История, диффы, ветки, коммиты. Агент видит эволюцию кода, а не только срез.
- HTTP / внешние API. Агент дёргает платёжный шлюз, поисковый индекс, ваш собственный сервис. Здесь руки агента дотягиваются наружу вашего периметра.
- Внутренние системы. Тикеты, CI, observability, feature-флаги. Агент перестаёт быть «редактором кода» и становится участником вашего рабочего контура.
Крафт написания такого сервера — вне фокуса этой статьи. Важно, что вам как продукт-инженеру чаще нужно подключить готовый сервер и решить, какой доступ он получит, чем написать свой.
Зачем это продукт-инженеру
Продукт-инженер владеет срезом от проблемы до пользователя. Агент — его рычаг на всём этом пути. Без рук рычаг короткий: агент помогает писать код, но обрывается на границе вашего текста. Всё, чего вы ему не рассказали, для него не существует.
MCP удлиняет рычаг — увеличивает дотягиваемость агента:
- Не «объясни агенту схему БД словами», а агент сам читает схему и пишет запрос под реальные таблицы, а не под воображаемые.
- Не «скопируй сюда ответ API», а агент сам дёргает endpoint и работает с настоящим ответом.
- Не «расскажи, что в тикете», а агент сам открывает тикет и связывает его с кодом.
Это качественный сдвиг, а не количественный. Агент перестаёт быть собеседником, которому вы пересказываете систему, и становится участником, который в системе находится. Ровно то, о чём методология и AI: агент даёт максимум, когда работает не в вакууме, а в вашем контексте. MCP — это канал, по которому контекст течёт живым, а не пересказанным.
И связь с памятью прямая. Memory Bank даёт агенту устойчивое знание проекта — что мы решили и почему. MCP даёт актуальный срез — что в системе прямо сейчас. Память — это «кто мы», MCP — это «что вокруг в эту секунду». Вместе они закрывают то, чего у голой модели нет по определению.
Границы безопасности: что вы отдаёте
Дать агенту руки — значит дать ему возможность что-то сломать или утечь. Это не повод не давать, это повод давать осознанно. Подключая MCP-сервер, вы отвечаете на три вопроса.
Какой доступ вы даёте. Read-only или запись? Одна таблица или вся база? Одна директория или корень диска? Дефолт — минимум прав, который закрывает задачу. База для анализа — read-only-роль, а не суперпользователь. Агенту почти никогда не нужно столько, сколько ему по инерции выдают.
Что агент может сломать. Инструмент с записью — это агент, который может выполнить DROP, перезаписать файл, отправить боевой запрос в платёжный шлюз. Модель ошибается правдоподобно: сгенерирует уверенный запрос, который сделает не то. Разрушительные действия должны быть либо недоступны, либо за подтверждением, либо в песочнице, где цена ошибки — ноль.
Что может утечь. Всё, до чего дотянулся агент, попадает в его контекст, а оттуда — провайдеру модели, в логи, в следующие ответы. Прод с персональными данными, секреты, ключи — это то, чего в контексте агента быть не должно. Отдельная угроза — недоверенные MCP-серверы: чужой сервер в вашей оснастке — это чужой код с вашими правами. Ставьте серверы так же придирчиво, как зависимости в проде.
Здоровая позиция: относитесь к оснастке агента как к правам сервиса. Тот же принцип наименьших привилегий, что и для доступа между сервисами. Агент — это ещё один актор в вашей системе. Дайте ему ровно те права, что нужны для задачи, и ни одним больше.
Коротко
- Модель — это мозг агента; без инструментов он умеет только писать текст. MCP даёт ему руки.
- До MCP каждая пара «агент × инструмент» писалась заново — матрица костылей. MCP — один протокол, схлопывающий её в «инструмент один раз, агент один раз».
- MCP-сервер — адаптер к одному миру (файлы, БД, git, API), выставляет tools и resources. Клиент внутри агента находит инструменты и даёт модели ими пользоваться. Модель не знает деталей за протоколом — это port/adapter уровня оснастки.
- Продукт-инженеру MCP удлиняет рычаг: агент не пересказывает систему с ваших слов, а сам читает базу, дёргает API, ходит в тикеты. Память отвечает «кто мы», MCP — «что вокруг сейчас».
- Границы безопасности — три вопроса: какой доступ (минимум прав), что можно сломать (запись за подтверждением/песочницей), что может утечь (без прода, секретов, недоверенных серверов). Оснастка агента = права сервиса; принцип наименьших привилегий.
- Как написать свой MCP-сервер — отдельный крафт; продукт-инженеру чаще нужно грамотно подключить готовый и решить, какие руки ему дать.