MCP (Model Context Protocol) — открытый протокол, стандартизующий способ подключения инструментов и источников данных к языковым моделям. Он решает не техническую, а организационную задачу: описать интеграцию один раз и переиспользовать её в разных приложениях и с разными моделями, вместо того чтобы переписывать под каждое решение. Для одного агента с парой инструментов это лишний слой; окупается он при нескольких потребителях.
Какую проблему решает
Без общего протокола каждая связка «приложение — инструмент» пишется отдельно. Три приложения и четыре инструмента дают двенадцать интеграций, и каждая живёт своей жизнью.
MCP разрывает эту зависимость: инструмент оформляется как MCP-сервер, приложение выступает MCP-клиентом. Любой клиент работает с любым сервером по одинаковым правилам — двенадцать интеграций превращаются в семь независимых компонентов.
Аналогия по смыслу — драйверы устройств: программа не пишет код под каждую модель принтера, она обращается к общему интерфейсу.
Что сервер может предоставлять
- Инструменты — действия, которые модель может вызвать: создать запись, выполнить поиск, отправить запрос.
- Ресурсы — данные для чтения: документы, справочники, содержимое базы.
- Промпты — заготовленные шаблоны запросов под типовые задачи.
Первое — то же самое, что function calling, только описанное стандартно и вынесенное за пределы приложения.
Чем отличается от function calling
Это не альтернативы, а разные уровни.
| Function calling | MCP | |
|---|---|---|
| Что это | механизм вызова функции моделью | протокол подключения инструментов |
| Где описан инструмент | в коде приложения | в отдельном сервере |
| Переиспользование | внутри одного приложения | между приложениями и моделями |
| Накладные расходы | нет | отдельный процесс, транспорт, обслуживание |
| Когда оправдан | всегда, это базовый механизм | когда потребителей несколько |
Внутри MCP всё равно работает function calling: клиент получает от сервера список инструментов и передаёт их модели обычным способом. MCP — это про то, откуда берётся список, а не про то, как происходит вызов.
Когда MCP оправдан
Оправдан:
- инструментами пользуется несколько приложений или команд;
- планируется менять модель или поставщика — интеграции переживут замену;
- нужен доступ к готовым серверам (файлы, базы, внешние сервисы), которые уже написаны;
- интеграции хочется развивать отдельно от приложения.
Не оправдан:
- один агент с несколькими инструментами — проще описать их в коде;
- жёсткие требования к задержке: дополнительный слой добавляет время;
- нет ресурса сопровождать ещё один компонент.
Практическое правило: начинать с function calling в коде и переходить на MCP, когда появляется второй потребитель тех же инструментов. Обратный порядок — сначала протокол, потом задачи — приводит к инфраструктуре, которая обслуживает сама себя.
Риски, о которых стоит знать
MCP-сервер — это компонент с доступом к вашим данным, и относиться к нему нужно соответственно.
Чужие серверы — это чужой код с вашими правами. Готовый MCP-сервер из открытого репозитория получает те полномочия, которые вы ему выдали. Проверять источник обязательно, особенно если сервер работает с учётной системой или файлами.
Описания инструментов влияют на поведение модели. Модель читает описания и следует им. Сервер, чьё описание содержит скрытые инструкции, способен изменить поведение агента — это разновидность инъекции в промпт. Для собственных серверов риск отсутствует, для чужих требует внимания.
Права выдаются серверу, а не отдельным вызовам. Если сервер имеет доступ к базе на запись, он может писать в неё независимо от того, что решила модель. Ограничения строятся на стороне сервера, а не в промпте.
Ещё один компонент в эксплуатации. Сервер нужно разворачивать, обновлять, мониторить и чинить. Для одного агента это лишняя работа.
Как выглядит внедрение
- Выбираются инструменты, которые нужны более чем одному потребителю.
- Они оформляются как MCP-сервер с проверками и лимитами внутри сервера, а не в приложении.
- Заводится отдельная учётная запись с минимальными правами — как при подключении к CRM.
- Приложение подключается как клиент и получает список инструментов.
- Настраивается журналирование: что вызвано, кем, с какими параметрами.
Пункт 2 — принципиальный. Если проверки оставить в приложении, второй клиент подключится к серверу мимо них.
Разбор: когда число интеграций начинает мешать
Проследим, как растёт объём работы без протокола и с ним.
Год первый. Один агент обрабатывает заявки, ему нужны CRM и почта. Две интеграции, написаны прямо в коде агента. MCP тут не нужен и был бы лишним слоем — это правильное решение.
Год второй. Появляется второй агент — для работы с документами. Ему нужны та же CRM, хранилище файлов и почта. Проблема: код обращения к CRM написан внутри первого агента и переиспользовать его нельзя, не вынося наружу.
Обычно на этом этапе код копируют. Теперь есть две реализации одной интеграции, и при смене версии API править надо обе. Уже неудобно, но терпимо.
Год третий. Появляется третий потребитель — внутренний ассистент для сотрудников. Ему нужны CRM, хранилище, почта и справочник. Копий кода становится три, а поведение начинает расходиться: в одном агенте проверка суммы есть, в другом её забыли добавить.
Вот здесь и наступает момент для MCP:
| Копирование кода | MCP-серверы | |
|---|---|---|
| Интеграций поддерживать | 3 агента × 4 системы = 9 реализаций | 4 сервера + 3 клиента |
| Смена версии API CRM | править в трёх местах | в одном |
| Проверки и лимиты | дублируются, расходятся | один раз внутри сервера |
| Новый потребитель | ещё копия кода | подключение к готовым серверам |
Второй сценарий, где MCP окупается, — смена модели. Если инструменты описаны внутри приложения, переход на другую модель или другого поставщика затрагивает и логику агента, и интеграции. При вынесенных серверах меняется только клиентская часть, а вся работа с внешними системами остаётся нетронутой.
Практический признак момента перехода: когда вы второй раз копируете код интеграции в новое приложение. Не раньше — иначе получится инфраструктура, обслуживающая сама себя, и лишний компонент в эксплуатации при единственном потребителе.
Частые вопросы
Что такое MCP простыми словами?
Общий язык, на котором ИИ-приложения договариваются с инструментами и источниками данных. Вместо того чтобы писать отдельную интеграцию под каждую пару «приложение — инструмент», инструмент описывается один раз как MCP-сервер, и с ним может работать любое приложение, поддерживающее протокол.
Заменяет ли MCP function calling?
Нет, он на нём построен. Клиент получает от MCP-сервера список инструментов и передаёт их модели обычным механизмом вызова функций. MCP отвечает за то, откуда берутся инструменты и как они переиспользуются, а не за сам вызов.
Нужен ли MCP для одного агента?
Обычно нет. Для одного приложения с несколькими инструментами проще описать их прямо в коде: меньше движущихся частей, меньше задержка, нечего сопровождать. MCP окупается, когда одни и те же инструменты нужны нескольким решениям или планируется смена модели.
Безопасно ли подключать готовые MCP-серверы?
Требует проверки, как любой сторонний код с доступом к вашим данным. Сервер получает выданные ему права и может ими пользоваться независимо от решений модели, а его описания инструментов влияют на поведение агента. Для внутренних инструментов лучше писать свои серверы; чужие — только из доверенных источников и с минимальными правами.
Что даёт MCP при смене модели?
Интеграции не переписываются. Инструменты живут в серверах отдельно от приложения, поэтому переход на другую модель или другого поставщика затрагивает только клиентскую часть. Это один из главных практических аргументов за протокол при долгосрочном планировании.
Что дальше
Базовый механизм вызова — «Function calling». Что агенту разрешать и как ограничивать права — «Ограничение действий ИИ-агента». Практика подключения к учётной системе — «Подключение ИИ-агента к CRM». Когда инструментов становится много и появляются несколько агентов — «Мультиагентные системы».
Проектирование инструментов и выбор между кодом и протоколом — часть работ по разработке и внедрению ИИ-агента.