MCP стал stateless. Что новая версия протокола значит для разработчиков интеграций
28 июля 2026 года вышла самая крупная версия MCP за всю историю протокола: 2026-07-28. Через месяц с небольшим, 1 сентября, реестр MCP-серверов перешагнул отметку в 10 000. А сегодня, пока я пишу эту статью, DeepSeek объявил о снижении цен до 60%. Агенты массово выходят в продакшен — и это напрямую меняет то, как мы строим интеграции.
Если вы ещё не работали с MCP — кратко: это открытый протокол, который позволяет AI-агентам подключаться к инструментам и данным через стандартный интерфейс. Вместо того чтобы писать отдельного клиента под каждую модель, вы один раз делаете MCP-сервер — и его используют все поддерживающие агенты. SDK протокола скачивают более 400 миллионов раз в месяц.
Главное изменение: протокол стал без состояния
Раньше MCP работал через сессии: клиент и сервер обменивались handshake, сервер выдавал Mcp-Session-Id, и все последующие запросы должны были попадать на тот же экземпляр сервера. Для локальной разработки это нормально, а для продакшена — боль: нужны sticky sessions, общее хранилище сессий, сложная балансировка. Новая версия убрала сессию полностью. Каждый запрос теперь самодостаточен: версия протокола, данные клиента и возможности передаются в самом запросе. Сервер стал обычным HTTP-эндпоинтом, который можно положить за обычный round-robin балансировщик, масштабировать горизонтально и перезапускать без потери клиентов.
Почему это важно для интеграций
Для тех, кто строит интеграции, это меняет три вещи. Во-первых, MCP-сервер теперь можно разворачивать как обычный микросервис в Kubernetes. Уходит целый класс проблем с инфраструктурой. Во-вторых, появился server/discover — метод, через который клиент может узнать возможности сервера в любой момент, а не только при подключении. В-третьих, маршрутизация вынесена в HTTP-заголовки. Теперь шлюз или балансировщик видит, какой инструмент вызывает агент, ещё до разбора тела запроса. Это открывает дорогу нормальному управлению на уровне инфраструктуры.
Что теперь может делать шлюз
Раньше, чтобы понять, что именно агент вызывает, нужно было разбирать тело каждого запроса. С новой версией тип вызова и имя инструмента видны в заголовках. Это значит, что на уровне шлюза можно делать: ▪ Маршрутизацию запросов к нужным серверам ▪ Ограничение частоты вызовов для конкретных инструментов ▪ Проверку прав: может ли этот агент вызывать базу данных ▪ Аудит: кто, когда и какой инструмент вызвал ▪ Логирование и мониторинг Для предприятий это то, что раньше упиралось в кастомные решения. Теперь это стандартная задача инфраструктурного слоя.
Что я рекомендую делать уже сейчас
Если в вашем продукте есть API, которые могут быть полезны агентам, — не ждите, пока вас об этом попросят. Опубликуйте MCP-сервер поверх существующего REST API. Это несколько дней работы, а доступность для агентов становится конкурентным преимуществом. Если вы строите корпоративную инфраструктуру агентов — закладывайте шлюз между агентами и MCP-серверами с самого начала. Четыре вещи, которые должны быть в нём: аутентификация, авторизация, аудит и изоляция прав между агентами. И помните про старую версию транспорта: HTTP+SSE официально помечен как устаревший, с переходным периодом 12 месяцев. Если ваши интеграции на нём — планируйте миграцию.
Пара слов про контекст
По данным LangChain, больше половины организаций уже запустили хотя бы одного агента в продакшен. Один многошаговый сценарий агента может потреблять в 100–500 раз больше токенов, чем обычный чат. А при этом цены на модели продолжают падать: только вчера DeepSeek снизил цены на flash-модели до 60%. Это значит, что стоимость моделей перестаёт быть главным вопросом. Главным становится управление: как контролировать вызовы, считать расходы и не давать агентам делать то, что им не положено. Именно поэтому шлюз для агентных интеграций — тема, которую стоит изучить уже в этом квартале.
Итог
MCP 2026-07-28 — не очередное обновление протокола. Это переход от инструмента для локальной разработки к стандарту производственных интеграций. Если вы работаете с API и агентами — версия протокола, транспорт и шлюз теперь часть вашей архитектуры, а не опция. А вы уже подключали MCP-серверы в своих проектах? Если да — на чём остановились: stdio или HTTP? И как решаете вопрос контроля доступа агентов к внутренним системам?
Полный разбор новой версии MCP: список изменений, схема шлюза для корпоративных агентов и примеры кода — я собрал в телеграм-канале @api_integrate_notes.