Что такое MCP? Как ИИ-агенты подключаются к вашим данным (Обновление спецификации 2026)

MCP, или Model Context Protocol, — это открытый стандарт, который позволяет ИИ-агенту получать доступ к инструментам и источникам данных через один общий интерфейс. Вместо создания отдельной интеграции для каждого приложения клиент использует один протокол, на который может ответить любой совместимый сервер. Спецификация была переписана 28 июля 2026 года, и это изменение весьма существенно.
В этом руководстве рассказывается о том, как работает протокол и что изменилось в релизе от 2026-07-28. Мы также разберем, какие функции теперь устарели, чем этот подход отличается от обычной интеграции через API и в каких случаях он вам не понадобится. Все данные актуальны на 5 августа 2026 года.
Что такое MCP?
Представьте себе это как универсальный разъем. До появления стандарта подключение ассистента к вашей базе данных, тикет-системе и файлам требовало трех уникальных интеграций. Каждая из них имела собственную авторизацию, свою обработку ошибок и требовала отдельной поддержки.
MCP определяет это подключение один раз. Клиент находится на стороне агента. Сервер оборачивает источник данных или инструмент и открывает доступ к его возможностям. Клиент запрашивает у сервера, что именно доступно, а затем вызывает нужную функцию.
Обычно серверы предоставляют три типа сущностей. Инструменты — это действия, которые может вызывать агент. Ресурсы — это контент для чтения. Промпты — это шаблоны многократного использования. Клиент обнаруживает все три типа в процессе работы (runtime), а не использует жестко закодированные значения.
Это название часто используют слишком свободно, поэтому важно внести ясность. Протокол — это не модель, не агент и не продукт. Это формат передачи данных между ними.
Большую часть путаницы вокруг него объясняют два понятия. Обнаружение означает, что клиент узнает о возможностях сервера во время работы. Повторное использование означает, что один и тот же сервер может отвечать любому совместимому клиенту.
Внедрение протокола уже вышло из плоскости теории. Разработчики протокола сообщают о почти полумиллиарде скачиваний в месяц для SDK первого уровня (Tier 1). Суммарное число скачиваний SDK для TypeScript и Python уже превысило один миллиард для каждого.
Что изменилось в спецификации от 2026-07-28
Этот релиз стал самым масштабным обновлением протокола за всю его историю. Главное нововведение — ядро теперь не хранит состояние (stateless).
| Изменение | Что это значит |
|---|---|
| Ядро без состояния (Stateless) | Сессии и рукопожатия (handshakes) ушли в прошлое. Каждый запрос теперь содержит собственную версию протокола и идентификатор клиента |
| Многораундовые запросы (Multi Round-Trip) | Заменяют запросы, инициируемые сервером, которые требовали открытого потока. Теперь инструмент может запрашивать ввод у пользователя прямо во время вызова |
| Маршрутизация на основе заголовков | Имена методов и инструментов передаются в заголовках Mcp-Method и Mcp-Name, что позволяет шлюзам выполнять маршрутизацию и авторизацию по заголовкам |
| Кэшируемые списки результатов | Списки инструментов, промптов и ресурсов теперь содержат параметры ttlMs and cacheScope |
| Усиление авторизации | Валидация издателя по RFC 9207, переход от Dynamic Client Registration к Client ID Metadata Documents, а также привязанные к издателю учетные данные (issuer-bound credentials) |
| Фреймворк расширений | Задачи перенесены из экспериментального ядра в официальное расширение, наряду с Apps и Enterprise Managed Authorization |
Этот список можно представить как одно решение, повторенное шесть раз. Каждое изменение устраняет допущения, которые усложняли работу с удаленными серверами. При этом сами возможности инструментов никак не изменились.
Полный список изменений доступен в официальной публикации о спецификации от 2026-07-28. SDK для TypeScript, Python, Go и C# уже поддерживают эти изменения, а версия для Rust находится в бета-тестировании.
Почему отсутствие состояния важно, если вы запускаете сервер
Предыдущая архитектура предполагала постоянное двунаправленное соединение. Именно это допущение и создавало большую часть эксплуатационных сложностей.
Раньше удаленному серверу требовались сессии с привязкой (sticky sessions), чтобы клиент всегда попадал на один и тот же инстанс. Также требовалось общее хранилище сессий, чтобы состояние сохранялось при перезапуске. Шлюзам часто приходилось анализировать тело запроса (payload), чтобы понять, какое действие выполняется.
Теперь ничего из этого не требуется. Сервер может находиться за обычным балансировщиком нагрузки, работающим по принципу round-robin. Маршрутизация происходит на основе заголовка. Клиенты кэшируют список инструментов на время, указанное сервером. Протокол превратился из технологии, требующей деликатного развертывания, в стандартное решение для обычного деплоя.
Конечно, это потребует затрат на миграцию. Серверы, созданные на базе старого ядра, нуждаются в доработке, и клиентские библиотеки должны обновляться вместе с ними.
Это изменение также снижает порог входа для тестирования. Раньше запуск сервера был серьезным инфраструктурным решением. Теперь это практически ничем не отличается от развертывания любого небольшого веб-сервиса.
Если вы оцениваете MCP-сервер от стороннего поставщика, стоит задать практический вопрос: на какую версию спецификации он ориентирован и когда планируется переход на новую.
Что объявлено устаревшим и сколько у вас есть времени
Три возможности выводятся из эксплуатации: Roots, Sampling и Logging. Устаревший транспорт HTTP+SSE также объявлен устаревшим.
Разработчики обязались предоставить как минимум 12-месячный переходный период перед окончательным удалением. Это щедрый срок, но в то же время это жесткий дедлайн. Если вы использовали любую из этих четырех возможностей, внесите миграцию в дорожную карту (roadmap), а не просто откладывайте в бэклог.
Проверьте не только сервер, но и клиент. Клиент, привязанный к старому транспорту, продолжит работать в течение переходного периода, но затем перестанет функционировать.
Функция Dynamic Client Registration официально признана устаревшей в пользу Client ID Metadata Documents. Учетные данные, привязанные к издателю (issuer-bound credentials), теперь предотвращают повторное использование токена, выданного для одного сервера, на другом сервере.
Сравнение MCP с обычной интеграцией через API
| Собственная интеграция через API | MCP-сервер | |
|---|---|---|
| Работа с каждым источником | Каждый раз новая авторизация, схема данных и обработка ошибок | Один протокол для многократного использования |
| Обнаружение (Discovery) | Вы жестко кодируете доступные функции | Клиент запрашивает их в процессе работы |
| Кто может использовать | Только приложение, в которое она встроена | Любой совместимый клиент |
| Поддержка | Ломается при изменении API поставщика | Сервер берет изменения на себя |
| Лучше всего подходит для | Одного глубокого высоконагруженного сценария | Множества источников, к которым обращается агент |
Еще один важный аспект — кто поддерживает коннектор. Сервер, опубликованный самим поставщиком, обновляется вместе с его продуктом, избавляя вас от этой работы.
Если говорить честно, MCP не будет быстрее или дешевле для одной-единственной интеграции. Он выигрывает, когда количество источников растет или когда вам нужно, чтобы несколько агентов обращались к одному источнику без необходимости переписывать код.
Что можно создавать после подключения источника данных
Подключение — это лишь техническая часть. Главная цель — это конечный результат.
Подключив источник данных, агент может извлечь актуальные показатели и провести анализ. На выходе вы получаете готовый результат: график, текстовый отчет или презентацию. Ценность заключается в исключении этапа ручного экспорта, а не в самом протоколе. Конечный результат — это также то, что оправдывает внедрение системы внутри компании. Подключение, которое никто не использует для создания отчетов, со временем просто тихо отключают.
Powerdrill Bloom поставляет сервер, работающий по этой схеме. Согласно документации, он проходит аутентификацию с помощью вашего User ID и Project API Key. После этого клиент может просматривать наборы данных в вашей учетной записи, запрашивать подробную информацию по любому из них и запускать задачи, задавая вопросы на естественном языке. Он работает с Claude Desktop и другими совместимыми клиентами. В анонсе MCP-сервера описан процесс настройки, а на странице data connectors перечислены другие типы источников.
Когда MCP вам вообще не нужен
Эту часть часто упускают из виду в большинстве обзоров, поэтому стоит сказать об этом прямо.
Если ваши данные поступают в виде файла, вам не нужен протокол. Вам нужна простая загрузка. Квартальный отчет, CSV-файл, присланный по почте, выписка в формате PDF — ничто из этого не требует развертывания сервера. Просто перетащите файл и задайте свой вопрос.
Перед тем как что-то создавать, задайте себе один вопрос: понадобится ли этот же экспорт в следующем месяце кому-то еще, кроме вас?
MCP оправдывает себя, когда источник данных является активным и регулярно обновляемым. Это может быть база данных, меняющаяся каждый час, очередь тикетов или таблица склада, на основе которой строится еженедельный отчет. Главный критерий: пришлось бы вам в противном случае снова экспортировать те же данные на следующей неделе.
Существует также аспект безопасности. Подключенный источник — это постоянный доступ, а не разовый обмен файлами. Изменения в авторизации от 2026-07-28 появились именно потому, что эта разница имеет значение.
Коротко о главном
MCP — это универсальный разъем между агентами и источниками данных. Релиз от 2026-07-28 сделал ядро протокола независимым от состояния (stateless), перенес маршрутизацию в заголовки, добавил кэширование списков результатов и ужесточил авторизацию. Функции Roots, Sampling, Logging и старый транспорт HTTP+SSE объявлены устаревшими с 12-месячным переходным периодом.
Для разовой работы с файлом все это не нужно. Попробуйте Powerdrill Bloom бесплатно — загрузите файл, задайте вопрос на естественном языке и экспортируйте график или презентацию. Если вы выбираете серверные решения, ознакомьтесь со списком лучших платформ MCP.
Часто задаваемые вопросы
Как расшифровывается MCP?
Model Context Protocol. Это открытый стандарт для подключения ИИ-клиентов к инструментам и источникам данных через единый интерфейс. Благодаря этому для каждого нового источника не нужно создавать отдельную интеграцию.
Что изменилось в спецификации MCP от 2026-07-28?
Ядро стало работать без сохранения состояния (stateless), сессии и рукопожатия (handshakes) были упразднены. Многораундовые запросы (Multi Round-Trip Requests) заменили запросы, инициируемые сервером через открытые потоки, а маршрутизация переместилась в заголовки Mcp-Method и Mcp-Name. Списки результатов теперь кэшируются, а авторизация была усилена за счет валидации издателя и использования привязанных к издателю учетных данных (issuer-bound credentials).
Является ли MCP тем же самым, что и API?
Нет. API — это интерфейс конкретного поставщика к конкретной системе. Протокол же представляет собой общую оболочку, которую могут реализовать многие системы, благодаря чему любой совместимый клиент может обнаруживать и вызывать их без написания уникального кода под каждый источник.
Что объявлено устаревшим в новой спецификации MCP?
Функции Roots, Sampling и Logging объявлены устаревшими, как и старый транспорт HTTP+SSE. На смену Dynamic Client Registration приходят документы Client ID Metadata Documents. Разработчики установили минимальный переходный период в 12 месяцев перед их окончательным удалением.
Нужен ли мне MCP для анализа электронных таблиц с помощью ИИ?
Нет. Если у вас уже есть файл, его проще и быстрее просто загрузить. Настраивать протокол имеет смысл тогда, когда источник данных постоянно обновляется и в противном случае вам пришлось бы регулярно делать повторный экспорт вручную.