Model Context Protocol (MCP) — открытый протокол, представленный Anthropic 25 ноября 2024 года, который стандартизирует подключение LLM-приложений к внешним инструментам и данным. Он отвечает не на вопрос «как агент решает, что вызвать», а на вопрос «как любое приложение и любой источник договариваются друг с другом по единому контракту».
Без стандарта каждое из M приложений интегрируется с каждым из N источников по-своему — в худшем случае это M×N отдельных коннекторов. MCP превращает M×N в M+N: приложение один раз становится клиентом, источник один раз становится сервером, и дальше они совместимы. Эту идею часто называют «USB-C для AI-приложений» и «LSP для контекста».
В основе — архитектура host ↔ MCP-клиент ↔ MCP-сервер поверх JSON-RPC 2.0 с транспортами stdio и Streamable HTTP. Сервер выставляет три примитива: tools, resources, prompts. Главная цена стандарта — доверие к серверам: подключённый MCP-сервер это исполняемая зависимость с доступом к контексту модели и каналом для prompt injection.
Практическая польза главы
Проблема M×N и зачем стандарт
При M приложениях и N источниках без стандарта нужно M×N коннекторов. MCP делает приложение клиентом, а источник сервером один раз — аналогия с USB-C и Language Server Protocol («LSP для контекста»).
Три примитива сервера
tools (tools/list, tools/call) выбирает модель; resources (resources/list, resources/read) подмешивает приложение; prompts (prompts/list, prompts/get) вызывает пользователь. Различие — кто контролирует примитив.
Транспорт и рукопожатие
JSON-RPC 2.0 поверх stdio или Streamable HTTP (HTTP POST + SSE). Сессия начинается с initialize и согласования возможностей, затем обнаружение и работа; сессия остаётся stateful.
Безопасность и эксплуатация
MCP-сервер — исполняемая зависимость с доступом к контексту: риск prompt injection через описания инструментов и ресурсы. Нужны allow-list, песочница, OAuth для удалённых серверов и логирование каждого вызова.
Связанная глава
Агентные процессы и вызов инструментов
MCP стандартизирует не сам цикл «думать-действовать», а способ подключать к нему инструменты и данные.
Соседняя глава об агентных процессах и вызове инструментов разбирает, как -агент планирует действия и обращается к инструментам, а обзорная AI Engineering задаёт рамку всей дисциплины. Эта глава — про другое: про Model Context Protocol (MCP) как открытый протокол, который стандартизирует подключение модели к инструментам и данным. Не «как агент решает, что вызвать», а «как любое приложение и любой источник договариваются друг с другом по единому контракту».
Проблема M×N: почему понадобился стандарт
Без стандарта каждое AI-приложение интегрируется с каждым инструментом по-своему. Если есть M приложений и N источников данных, в худшем случае нужно написать и сопровождать M×N отдельных интеграций: свой коннектор к GitHub, свой к Postgres, свой к Slack — и так в каждом приложении заново. Каждый новый источник требует собственной реализации, и связные системы плохо масштабируются.
Идея стандарта — превратить M×N в M+N: приложение один раз учится быть MCP-клиентом, источник один раз становится MCP-сервером, и дальше они совместимы без отдельной интеграции. Это та же логика, что у USB-C (один разъём для множества устройств) и у Language Server Protocol (один протокол вместо отдельной поддержки каждого языка в каждом редакторе). MCP часто и называют «USB-C для AI-приложений» или «LSP для контекста».
Что такое MCP: host ↔ клиент ↔ сервер
MCP — открытый протокол, представленный Anthropic 25 ноября 2024 года. В его основе архитектура client-host-server: один host-процесс управляет несколькими изолированными клиентами, каждый из которых держит выделенное соединение со своим сервером.
Host управляет клиентами и применяет политику безопасности; каждый клиент держит соединение «один к одному» со своим сервером. Серверы независимы и изолированы: каждый видит только нужный срез контекста, а вся история диалога остаётся в host.
Примитивы сервера: tools, resources, prompts
Сервер выставляет три типа примитивов. Главное различие — не назначение, а кто держит управление, и именно от этого зависит, где проходит граница доверия: инструменты выбирает модель, ресурсы подмешивает приложение, шаблоны вызывает пользователь.
Tools (инструменты)
Управляются моделью
tools/list · tools/call
Вызываемые функции с побочными эффектами: запрос к API, изменение записи, запуск задачи. Модель сама выбирает инструмент по его описанию и JSON-схеме входа, но спецификация требует держать человека в контуре с возможностью отклонить вызов.
Resources (ресурсы)
Управляются приложением
resources/list · resources/read
Доступные только для чтения данные — файлы, схемы баз данных, документы — адресуемые по URI. Это контекст для модели; как именно его подмешать (пикер, поиск, авто-вложение), решает host-приложение.
Prompts (шаблоны)
Управляются пользователем
prompts/list · prompts/get
Переиспользуемые шаблоны взаимодействия с параметрами, которые пользователь обычно вызывает явно (например, slash-командой). Сервер возвращает развёрнутую последовательность сообщений с ролями и вложениями.
Транспорт и протокол
Формат сообщений один и тот же поверх любого транспорта — меняется только граница, которую он пересекает. Спецификация определяет два стандартных транспорта (stdio и Streamable HTTP, возможны и кастомные), а клиент и сервер согласуют используемый.
stdio
Сервер запускается как локальный процесс и обменивается сообщениями через stdin/stdout строками JSON-RPC — формата на базе . Минимальная задержка и простая модель доверия — подходит для локальных интеграций (файлы, git, локальные утилиты).
Streamable HTTP
Удалённый сервер принимает POST и может стримить ответы через (SSE). Это путь для сетевых, многопользовательских и облачных серверов, где появляются аутентификация и сетевые границы.
JSON-RPC 2.0
Единый формат сообщений: запрос (с id и ответом), ответ и нотификация (fire-and-forget, без id). Тот же проводной формат, что у Language Server Protocol — отсюда и аналогия «LSP для контекста».
Жизненный цикл сессии: инициализация и согласование возможностей
- initialize. Клиент открывает сессию, сообщает версию протокола и свои возможности, получает в ответ возможности сервера. До завершения рукопожатия рабочие вызовы не выполняются.
- Согласование возможностей. Стороны явно объявляют, что поддерживают: умеет ли сервер отдавать tools/resources/prompts, подписки на изменения, а клиент — сэмплинг. Это позволяет расширять протокол без поломки совместимости.
- Обнаружение. Клиент запрашивает
tools/list,resources/list,prompts/listи передаёт их описания и схемы в контекст модели. - Работа. Модель выбирает инструмент, клиент шлёт
tools/call, ресурсы читаются по URI, шаблоны разворачиваются. Сессия остаётся , пока её не закроют.
Что меняет MCP по сравнению с разовыми, вшитыми в код вызовами инструментов
Без MCP интеграции инструментов «вшиты» в приложение: вы описываете функции прямо в коде агента и сопровождаете их вместе с ним. Это работает, но не переносимо — другой агент не сможет переиспользовать ваш коннектор, а вы не сможете подключить чужой без переписывания.
MCP отделяет интеграции от приложения. Сервер становится самостоятельным переиспользуемым артефактом: написанный однажды, он работает с любым MCP-совместимым host. Появляется экосистема готовых серверов, а превращается из частной детали приложения в общий контракт. При этом сам механизм выбора инструмента моделью остаётся прежним — MCP стандартизирует подключение и обнаружение, а не сам процесс рассуждения агента.
Безопасность: доверие, разрешения, инъекции, изоляция
Доверие к серверу
MCP-сервер видит запросы и может вернуть в контекст модели любой текст. Сторонний сервер из публичного реестра — это исполняемая зависимость с доступом к данным, а не просто конфиг.
Согласие и разрешения
Спецификация настаивает на явном согласии пользователя: host обязан раскрывать, какие данные и инструменты задействованы, и держать человека в контуре для подтверждения вызовов с побочными эффектами.
Внедрение инструкций в запрос (prompt injection) через инструменты
Описание инструмента, имена параметров и содержимое ресурса попадают в контекст модели и могут нести скрытую . Скомпрометированный или вредоносный сервер способен перенаправить поведение агента.
Изоляция и песочница
Host изолирует клиентов друг от друга: сервер получает только нужный срез контекста, без всей истории диалога. Локальные серверы стоит запускать в с ограниченными правами на файловую систему и сеть.
Эксплуатация: где запускать, как аутентифицировать, как наблюдать
Где запускать
Выбор транспорта сразу определяет эксплуатационную нагрузку. stdio-серверы живут рядом с host-приложением как дочерние процессы и почти ничего не требуют; удалённые серверы по Streamable HTTP — это полноценные сетевые сервисы со своим масштабированием, таймаутами и обработкой перегрузки.
Аутентификация
Для удалённых серверов нужна реальная авторизация: спецификация MCP описывает HTTP-слой на базе 2.1. Локальный stdio чаще опирается на доверие к процессу и переданные переменные окружения.
Наблюдаемость вызовов
Каждый tools/call стоит логировать с аргументами, результатом и тем, какой сервер его обслужил. Без невозможно ни отлаживать агента, ни проводить аудит безопасности.
Ключевые компромиссы
- Стандарт против ad-hoc: общий протокол даёт переиспользуемые серверы и экосистему, но добавляет слой рукопожатия, согласования возможностей и версионирования поверх простого .
- Отделение интеграций от приложения упрощает повторное использование, но переносит часть ответственности (и рисков) на внешние серверы, которые вы не контролируете.
- Удалённые серверы дают многопользовательский доступ и централизованное обновление, но приносят сетевую задержку, аутентификацию и эксплуатацию полноценного сервиса.
- Чем больше инструментов подключено, тем шире поверхность атаки и тем выше шанс, что модель выберет не тот инструмент или будет сбита с толку похожими описаниями.
Частые ошибки
Рекомендации
Источники и материалы
Фактура главы привязана к версии спецификации MCP 2025-06-18. Для будущих релизов перепроверяйте жизненный цикл сессии, транспорт, примитивы сервера и требования безопасности по versioned docs.
Связанные главы
- Агентные процессы и архитектура вызова инструментов - Как агент планирует и вызывает инструменты — слой, который MCP стандартизирует со стороны подключения источников.
- AI Engineering: обзор - Контекст всей дисциплины: где интеграция инструментов и данных стоит в жизненном цикле AI-приложения.
- Защитные ограничения LLM и защита от внедрения инструкций (prompt injection) - Почему недоверенный контекст из инструментов и ресурсов — главный класс рисков при подключении внешних серверов.
- Архитектура RAG-системы - Альтернативный способ давать модели контекст; MCP-ресурсы и генерация с извлечением контекста (RAG) решают близкую задачу с разных сторон.