Why MCP Exists: the N×M Integration Problem

К 2024 году сложилась парадоксальная ситуация. Модели научились вызывать функции, но каждое AI-приложение подключалось к каждому источнику данных собственным кодом. Claude Desktop писал свой коннектор к GitHub, свой — к Postgres, свой — к Slack. Cursor писал те же коннекторы заново, под свой формат. Внутренний ассистент вашей компании — в третий раз. При N приложений и M систем получается N×M интеграций, и каждая живёт со своим форматом описания инструментов, своей аутентификацией, своей обработкой ошибок и своим циклом поддержки. Стоило GitHub поменять API — чинить приходилось всем и каждому.

Корень проблемы в том, что function calling у провайдеров — это только формат описания функции для модели. Он ничего не говорит о том, как приложение находит инструменты, кто их исполняет, где живут секреты и как доставляются данные. Вся эта обвязка каждый раз изобреталась заново.

MCP (Model Context Protocol), открытый Anthropic в ноябре 2024 года, решает задачу так же, как LSP когда-то решил проблему «каждый редактор × каждый язык программирования»: вводится один стандартный протокол между приложением и провайдером возможностей. Автор источника данных пишет один MCP-сервер — и он работает в Claude, Cursor, VS Code, Zed и любом другом совместимом клиенте. Автор приложения пишет один MCP-клиент — и получает всю экосистему серверов. N×M превращается в N+M.

В терминологии MCP участвуют три роли, и путать их нельзя.

Host — приложение, с которым разговаривает пользователь: Claude Desktop, Claude Code, Cursor, VS Code. Host управляет моделью, интерфейсом и — критично — согласием пользователя на действия.

MCP-клиент — компонент внутри host, который держит соединение с одним сервером. Соотношение строго 1:1 — на каждый подключённый сервер host создаёт отдельный клиент с собственной сессией.

MCP-сервер — процесс (локальный или удалённый), который предоставляет возможности: инструменты, ресурсы, промпты.

Host (Claude Code)
 ├── MCP-клиент ──► сервер GitHub    (tools: create_pr, search_issues)
 ├── MCP-клиент ──► сервер Postgres  (tools: query; resources: schema)
 └── MCP-клиент ──► сервер вашего продукта

Такое разделение даёт важные гарантии. Сервер не видит переписку пользователя с моделью — он получает только конкретные вызовы своих методов. Сервер не видит другие серверы — изоляция по умолчанию. Host остаётся единственной точкой, где принимаются решения: какие инструменты показать модели, спросить ли подтверждение перед разрушительным действием, какие результаты вернуть в контекст. Вы как автор сервера проектируете «розетку», а не «электростанцию»: определяете контракт возможностей, а оркестрацией занимается host.

Стандарт ценен экосистемой. В официальном репозитории modelcontextprotocol/servers лежат эталонные серверы — filesystem, git, fetch, memory, time — плюс сотни community-серверов: от Stripe и Sentry до внутренних CRM. Любой из них подключается к любому совместимому клиенту строчкой конфигурации. Написав сервер для API своего продукта один раз, вы мгновенно получаете присутствие во всех AI-инструментах, которые поддерживают MCP, — это дистрибуция, а не просто интеграция.

Протокол версионируется датами: 2024-11-05 — первая стабильная ревизия, 2025-03-26 добавила транспорт Streamable HTTP, 2025-06-18 — авторизацию уровня resource server, elicitation и structured output. Клиент и сервер согласуют версию при рукопожатии, поэтому старые серверы продолжают работать с новыми клиентами.

Честности ради: MCP не всегда нужен. Если у вас одно приложение, один API и один провайдер модели — прямой function calling внутри вашего кода проще: меньше процессов, меньше слоёв, меньше задержек. MCP окупается, когда выполняется хотя бы одно из условий: возможностью должны пользоваться несколько приложений; вы хотите отдать интеграцию чужим приложениям (Claude, Cursor); нужна изоляция секретов от кода агента; или вы строите внутреннюю платформу, где команды публикуют возможности независимо друг от друга. В этом курсе мы пройдём весь путь: от кадров протокола до публикации собственного сервера.