Что такое MCP и почему каждый ИИ-инструмент вдруг заговорил на нём?
Большую часть последнего десятилетия подключение модели ИИ к инструментам компании означало отдельную интеграцию для каждой пары. Model Context Protocol, открытый стандарт, который Anthropic представила в ноябре 2024 года, заменил это одной вилкой, которая подходит везде — и OpenAI, Google и Microsoft с тех пор его приняли. Вот как он устроен на самом деле и настоящий чек-лист перед тем, как подключать его к данным команды.
Откройте настольное приложение Claude и попросите его проверить открытые pull request вашей команды — и оно просто это сделает. Не потому, что Anthropic встроила в Claude интеграцию с GitHub. А потому, что где-то — ваша ИТ-команда, поставщик, разработчик на GitHub — кто-то написал небольшую программу, которая говорит на протоколе под названием MCP, и Claude уже умеет разговаривать со всем, что говорит на нём. То же самое теперь верно для ChatGPT, Gemini от Google и Microsoft Copilot. Эта конвергенция, больше чем любой отдельный релиз, и объясняет, почему MCP стал тем, поддержку чего почти каждый ИИ-вендор добавлял в свои продукты весь прошлый год.
Чем MCP является на самом деле
MCP расшифровывается как Model Context Protocol. Anthropic разработала его и открыла спецификацию вместе с первыми SDK 25 ноября 2024 года. Собственные материалы запуска описали идею аналогией, которая прижилась: думайте о MCP как о порте USB-C для приложений ИИ — один физический стандарт разъёма вместо отдельного кабеля на каждое устройство. На запуске Anthropic назвала ранних пользователей, которые уже встраивали поддержку MCP в свои продукты, включая компании корпоративного ПО Block и Apollo, а также создателей инструментов для разработчиков Zed, Replit, Codeium и Sourcegraph. Настольное приложение Claude вышло в тот же день с возможностью запускать MCP-серверы локально на машине самого человека.
Какую задачу он решает: N инструментов умножить на M источников данных
У задачи, которую решает MCP, есть имя, которым инженеры пользуются вскользь: проблема интеграции N на M. Допустим, компания использует пять ИИ-инструментов, которым нужно действовать с данными компании — Claude, ChatGPT, GitHub Copilot, Cursor и внутренний бот поддержки — а эти данные лежат в восьми местах: Slack, GitHub, база Postgres, Salesforce, Notion, Google Drive, Jira и внутренний API. Без общего протокола полезно соединить каждый инструмент с каждым источником — это до сорока отдельных интеграций, пять умножить на восемь, у каждой своя схема аутентификации, своя обработка ошибок и свой налог на сопровождение каждый раз, когда один из этих API меняет форму. Добавьте шестой ИИ-инструмент — и число прыгает до сорока восьми. На практике никто не построил все сорок. Каждый поставщик ИИ сделал ту горстку, которую счёл достойной инженерного времени, а всё остальное осталось ручным: скопировать, вставить, объяснить заново, повторить.
MCP превращает умножение в сложение. Компании, которая хочет, чтобы Claude читал её базу Postgres, не нужно строить коннектор Postgres специально под Claude. Она строит — или переиспользует уже опубликованный кем-то другим — один MCP-сервер, который открывает Postgres, и этот сервер работает с Claude, ChatGPT, Gemini или любым другим совместимым с MCP агентом без дополнительного кода. Собственный список Anthropic на запуске называл готовые серверы для Google Drive, Slack, GitHub, Git, Postgres и инструмента автоматизации браузера под названием Puppeteer. Смысл никогда не был в том, что Anthropic построит их все. Смысл в том, что это мог сделать кто угодно, и каталог доступных серверов вырос далеко за пределы того, что одна компания смогла бы укомплектовать людьми.
Как протокол устроен на самом деле
Если снять оболочку, MCP — довольно обычный клиент-серверный протокол, намеренно неэффектный по замыслу. Он задаёт три роли. Host — это приложение, которое человек действительно открывает: Claude Desktop, IDE вроде Cursor, приложение ChatGPT. Host встраивает MCP Client, который открывает прямое соединение с сохранением состояния к MCP Server — небольшой программе, открывающей одну конкретную систему: базу данных, систему заявок, файловую систему, внутренний API. Клиент и сервер обмениваются сообщениями в формате JSON-RPC 2.0, лёгком формате удалённого вызова процедур, уже распространённом в существующей инфраструктуре, по одному из двух транспортов: stdio, когда сервер — программа, запущенная локально на той же машине, или Streamable HTTP, когда это размещённый сервис, работающий где-то ещё.
То, что сервер может открыть наружу, сводится к трём примитивам. Tools — функции, которые модель может вызвать, чтобы совершить действие: create_task, run_query, send_message, — и модель решает, когда вызвать одну из них, исходя из разговора. Resources — контекст только для чтения, который Host может подтянуть и передать модели, не дожидаясь её просьбы: содержимое файла, схема базы, заявка в поддержку. Prompts — переиспользуемые шаблоны, которые запускает человек: готовое «суммируй эту ветку» или «набросай обновление статуса», которое человек вызывает явно, а не то, что модель решает сделать сама. Хорошо собранный сервер прямо говорит, какой из трёх он предлагает для данной возможности, потому что именно это различие определяет, может ли подключённый ИИ-инструмент только смотреть на что-то или ещё и менять это.
Кто ещё его подхватил и когда
Первые месяцы MCP были проектом одной Anthropic. Это быстро изменилось, и изменилось так, как в сфере ИИ бывает по-настоящему редко: прямые конкуренты сошлись на протоколе одной компании, вместо того чтобы выпускать свои. В марте 2025 года OpenAI добавила поддержку MCP в свой Agents SDK, чтобы разработчики могли подключать рабочие процессы агентов к любому MCP-серверу, а не строить заказные интеграции инструментов только под OpenAI. В следующем месяце Google DeepMind подтвердила, что Gemini и собственный набор для разработки агентов тоже будут поддерживать MCP — шаг, который Google соединила со своим дополняющим протоколом Agent2Agent, рассчитанным на то, чтобы независимые агенты согласовывали действия друг с другом, а не только с инструментами. К маю 2025 года Microsoft добавила встроенную поддержку MCP в Windows 11 через то, что она называет Windows AI Foundry, и поддержка также появилась в GitHub Copilot и Copilot Studio.
Эти четыре компании почти ни в чём не сходятся, когда речь об архитектуре моделей, ценах или платформенной стратегии. Все четыре теперь поставляют продукты, которые говорят на одном протоколе, чтобы соединить агента с инструментом. В этой отрасли это достаточно редко, чтобы быть настоящей историей — важнее любой отдельной функции, которую MCP делает возможной.
Почему это вопрос доверия, а не только проводки
Это схождение по-настоящему полезно, и именно поэтому MCP заслуживает проверки, а не слепого доверия. Протокол, который делает тривиальным подключение агента к системам компании, — это протокол, который делает тривиальным и то, что плохо собранное или плохо настроенное соединение доберётся до тех же систем. Сам MCP этого не предотвращает. Спецификация определяет, как клиент и сервер разговаривают друг с другом, — она ничего не говорит о том, кому разрешено выдавать соединение, к чему этому соединению можно прикасаться и заметит ли кто-нибудь, если что-то пойдёт не так. Эти решения целиком лежат на том, кто собрал или настроил конкретный сервер или клиент перед вами. Одни поставщики строят всё это тщательно. Другие не строят вовсе, и протокол их не остановит.
MCP — это проводной протокол, а не система контроля доступа. Он стандартизирует то, как агент просит инструмент что-то сделать. Ограничен ли этот запрос, записан ли он и можно ли его отозвать — это решение, которое кто-то принял поверх протокола. Или не принял.
Чек-лист перед подключением
Прежде чем команда подключит MCP-сервер — будь то продукт поставщика, инструмент с открытым кодом, который кто-то нашёл на GitHub, или то, что собрали внутри, — шесть вопросов отделяют управляемое соединение от открытой двери. Ни один из них не требует читать спецификацию. Они требуют только, чтобы кто-то спросил до нажатия «одобрить» и действительно прочитал ответ, который возвращает экран подключения.
| Спросите вот это | Как выглядит хороший вариант | На что смотреть |
|---|---|---|
| Какие области доступа или инструменты он запрашивает? | По пунктам Именованный конкретный список, который можно прочитать до одобрения — «создавать задачи, читать сообщения в этом канале». | Оптом «Полный доступ к аккаунту» без поимённого списка того, что он на самом деле может делать. |
| Он только для чтения или может писать и действовать? | Разделено Чтение по умолчанию; любое действие, которое меняет данные, требует отдельного видимого разрешения. | В комплекте Право на запись включено автоматически, и нельзя понять, какая возможность что делает. |
| Это на человека или общее на всю команду? | На человека Каждый входит под своим логином; агент видит только то, что видит этот человек. | На всех Один API-ключ или служебная учётная запись на всю команду, в обход личных прав. |
| Есть ли журнал аудита того, что он сделал? | С журналом Каждый вызов инструмента записан — кто подключил, к чему прикоснулся и когда. | Без журнала Никакой записи, кроме того, что сам ИИ-инструмент решит вам рассказать. |
| Можно ли отозвать его сразу? | Сразу Один переключатель, действует немедленно, со страницы настроек, которой вы управляете. | С задержкой Отзыв требует заявку в поддержку, звонок поставщику или невозможен вовсе. |
| Не сломает ли отзыв что-то ещё? | Изолировано Область только этого соединения; выключение затрагивает лишь его. | Связано Делит учётные данные с другими инструментами, так что отзыв одного тихо ломает ещё три. |
Как на самом деле выглядит хорошо собранное соединение
Собственная настройка MCP в FabricLoop — один конкретный ответ на этот чек-лист. Не потому, что она необычна, а потому, что каждая часть прямо отвечает на один из шести вопросов выше, и стоит назвать настоящую механику, а не маркетинговую версию. FabricLoop одновременно играет обе роли: это MCP-сервер, к которому подключаются внешние инструменты, так что Cursor, Claude или ChatGPT могут создать задачу, добавить комментарий или прочитать заметку с правами конкретного человека в FabricLoop — и это MCP-клиент, который подключается наружу, так что канал может подтянуть MCP-приложение поставщика, например GitHub или Linear, и упомянуть его через @ как коллегу.
Каждое соединение, в любую сторону, начинается с человека, а не с рабочего пространства. Подключение внешнего клиента вроде Cursor открывает экран согласия OAuth по адресу app.fabricloop.com/oauth/consent, где этот человек выбирает рабочее пространство и одобряет конкретные инструменты, которые просит клиент — после этого клиент может действовать только в рамках областей, выданных на этом экране, под правами одного этого человека, и никогда через общую служебную учётную запись. Обратное направление устроено так же: администратор может включить MCP-приложение поставщика для всей команды, но каждый человек всё равно проходит свой вход, прежде чем оно заработает для него, а администратор может перевести приложение в режим только для чтения или ограничить его списком разрешённых инструментов вместо всего, что открывает поставщик.
Каждый подключённый клиент появляется на экране настроек рядом с элементом «Отозвать», который отключает его сразу — на собственной странице человека, а не в заявке в поддержку. На планах Enterprise эта активность — включая выдачи MCP и то, что подключённый агент действительно сделал, — попадает в журнал аудита, который служба безопасности может просмотреть по запросу, а не в скриншоты, вытащенные из переписки задним числом.
Ничего из этого не является экзотической инженерией. Это небольшой, намеренно неэффектный набор решений, повторённый последовательно: ограничить область, привязать к человеку, записать, сделать отзыв возможным без побочного ущерба. Тот же довод мы шире разбираем в материале о Прозрачности — доступ, который можно назвать, записать и отозвать, лучше доступа, о котором никому не приходится думать, — и MCP даёт это только тогда, когда кто-то так его и собирает. Протокол делает проводку стандартной. Он не делает управление автоматическим.
Решение, которое действительно важно
MCP никуда не денется, и возражать против него сейчас немного похоже на возражение против USB. Каждый крупный поставщик моделей теперь его поставляет, список доступных серверов продолжает расти, а агент, который не достаёт до ваших инструментов, для большей части настоящей работы — это агент, который мало что может. Интересное решение не в том, пускать ли ИИ-инструмент к вашим системам: всё чаще какую-то версию этого решения уже принимают за вас, по одной интеграции за раз, когда инструменты, которыми команда уже пользуется, тихо добавляют поддержку MCP под функцией, в которую вы зашли, не читая мелкий шрифт. Решение, которое всё ещё действительно ваше, — что вы проверяете, прежде чем нажать «одобрить».
MCP стандартизировал то, как ИИ-агент просит инструмент что-то сделать. Он ничего не стандартизировал в том, безопасно ли этот запрос одобрять — эта часть по-прежнему, и останется, решением человека, который нажимает «одобрить».