Ключевые выводы

Спека 2026-07-28 — инфраструктурный релиз, не косметика. Убрали initialize/initialized и идентификатор сессии. Каждый запрос самодостаточен: версия протокола, клиент и возможности едут в _meta. Запрос может попасть на любой инстанс за обычным round-robin.

Состояние не исчезло — его сделали видимым для модели. Если нужен контекст между вызовами, сервер выдаёт handle (id задачи, снимок, черновик), а агент передаёт его аргументом. Скрытое состояние в транспорте хуже: модель его не видит и не может осознанно «протащить» между tools.

Безопасность — главный барьер масштабирования. Shadow MCP (серверы в IDE без учёта IT) часто в разы шире ожиданий. Инструмент с записью в прод или доступом к секретам опаснее «просто чата». Песочницы и allowlist серверов — обязательный контур рядом с самим MCP.

Дизайн tools важнее количества методов API. Восемь предметных инструментов с понятными режимами обычно надёжнее восьмидесяти почти одинаковых обёрток. Это уже видно на практике в разборах MCP для внешних API.

Авторизация и наблюдаемость — часть продукта. RFC 9207 (iss), отказ от DCR в пользу Client ID Metadata Documents, заголовки Mcp-Method / Mcp-Name для шлюзов — без этого «продакшен» остаётся демо на ноутбуке.

Что такое MCP и зачем он команде разработки

MCP — открытый протокол, как LLM-агент обнаруживает и вызывает tools, читает resources, использует prompts и (в новых сценариях) запрашивает подтверждение у человека. Клиенты — Cursor, Claude Desktop, VS Code, облачные agent runtimes. Серверы — ваши обёртки над Git, тикетами, БД, внутренними API, CI.

До MCP каждая связка «модель ↔ сервис» была одноразовым коннектором. Смена вендора модели ломала библиотеку интеграций. Протокол выносит контракт наружу: один сервер обслуживает несколько клиентов; один клиент подключает много серверов.

Почему тема взорвалась именно сейчас

К июлю 2026 экосистема выросла до промышленного масштаба: сотни миллионов загрузок SDK в месяц, тысячи публичных серверов, поддержка крупных платформ. 28 июля вышла спецификация 2026-07-28 с переходом на stateless protocol core — самый заметный сдвиг с момента появления remote MCP.

Параллельно команды столкнулись с «теневой» установкой серверов: разработчик добавил MCP в Cursor к пятнице, а security узнала об этом на инциденте. Это пересекается с темой песочниц для агентного кода и с тем, что «локальная» модель не равна приватности.

Как устроен MCP: роли и поверхность

Клиент

Хост агента: держит диалог с моделью, подключает серверы, показывает elicitations, применяет политики (какие серверы разрешены). Клиент решает, какие tools попадут в контекст модели.

Сервер

Процесс или HTTP-endpoint, который объявляет capabilities и исполняет вызовы. В 2026 remote MCP поверх Streamable HTTP — норма для прода; локальный stdio остаётся удобным для разработки и персональных инструментов.

Tools, resources, prompts

Tools — действия с побочными эффектами или вычислениями (создать тикет, прогнать запрос, переобход URL).
Resources — читаемые сущности (файл, схема, отчёт).
Prompts — шаблоны, которые сервер предлагает клиенту.

Для агента критичен каталог: имена, описания, схемы аргументов. Плохие описания → неверный tool. Слишком много похожих tools → путаница. Хороший сервер группирует API вокруг задач пользователя, а не вокруг OpenAPI paths.

Спека 2026-07-28: что реально меняется

Официальный анонс подчёркивает: ядро стало request/response без привязки к сессии на конкретном инстансе.

Нет handshake и Mcp-Session-Id

Раньше клиент и сервер обменивались initialize / initialized, дальше жила сессия. Теперь каждый запрос несёт нужный контекст сам. Опциональный server/discover позволяет узнать capabilities заранее — но он не обязателен перед первым tools/call.

Это напрямую влияет на деплой: можно крутить MCP за load balancer без sticky sessions и без shared session store на уровне протокола.

Состояние приложения через handles

Если tool создаёт долгую операцию или черновик, сервер возвращает идентификатор. Следующий вызов принимает этот id в arguments. Модель видит handle в истории и может передать его дальше — в отличие от невидимого session bag на сервере.

Multi Round-Trip Requests (MRTR)

Раньше server-initiated elicitation/sampling требовали удерживать двунаправленный поток. MRTR позволяет серверу ответить input_required, клиент собирает ответы человека (или другой подсистемы) и повторяет исходный вызов с inputResponses. Типичный кейс: «подтвердите удаление» или «укажите проект перед дорогим действием».

Маршрутизация по заголовкам

Запросы Streamable HTTP обязаны нести Mcp-Method и Mcp-Name. Шлюз, WAF и rate limiter могут резать или учитывать квоты по имени инструмента, не разбирая JSON body. Для ops это разница между «чёрным ящиком POST /mcp» и нормальным HTTP-сервисом.

Кэш списков

Ответы tools/list, prompts/list, resources/list и часть resources/read несут подсказки ttlMs и cacheScope. Клиенты реже дёргают каталог; стабильный порядок списка помогает prompt cache не «дрожать» при каждом reconnect.

Авторизация

Усиливают проверку iss (RFC 9207), привязку credentials к issuer, постепенный уход от Dynamic Client Registration к Client ID Metadata Documents (CIMD). DCR ещё жив для совместимости, но новые реализации должны планировать CIMD.

Tasks и расширения

Долгие задачи оформляются расширением Tasks (poll через tasks/get, обновления через tasks/update), а не «вечной» сессией. Roots, Sampling и Logging помечены deprecated с минимум двенадцатимесячным окном — не строить на них новые продукты.

Как писать MCP-сервер, который доживёт до прода

Начните с вопросов пользователя, не с OpenAPI

Выпишите 5–15 вопросов, которые агент должен закрывать («какие URL с ошибками индексации», «создай черновик PR», «покажи медленные запросы»). Каждый вопрос — кандидат в tool или режим одного tool. Идентификаторы, которые нельзя угадать из URL, отдавайте отдельным «discover»-шагом.

Делайте результаты компактными и объяснимыми

Модели плохо переваривают сырой dump на 50 КБ. Сортировка, фильтрация устаревшего, сводные счётчики, явный next step при ошибке — часть контракта. Различайте 401 (нужен новый вход) и 403 (нет прав на объект): иначе агент крутит OAuth впустую.

Явные побочные эффекты

Tool, который пишет данные, должен быть назван как действие (submit_, delete_, create_), а не как нейтральный get_. Для разрушительных операций закладывайте MRTR/elicitation.

Версии и совместимость

Меняйте схему аргументов осторожно. Добавление optional-полей безопаснее переименования. Документируйте MCP-Protocol-Version, которые вы поддерживаете; тестируйте клиентов на 2026-07-28 и на предыдущей линии, пока парк IDE не обновится.

Стек

TypeScript SDK остаётся самым частым выбором для веб-команд; Python, Go и C# закрыты на Tier 1 для новой спеки. Для serverless (Workers и аналоги) stateless-ядро как раз снимает главный операционный тормоз.

Миграция со сессионной модели

План без героизма:

1. Инвентаризация: где код читает session id или кладёт кросс-вызовное состояние в память процесса.
2. Для каждого куска состояния — явный handle (БД, Redis, object storage) + аргумент tool.
3. Включить/обновить SDK под 2026-07-28; прогнать tools/list и критичные tools/call за балансировщиком с двумя инстансами.
4. Проверить elicitations через MRTR, если использовали server-push.
5. Обновить шлюз: правила по Mcp-Method / Mcp-Name.
6. Зафиксировать deprecation: не использовать Roots/Sampling/Logging в новых фичах.

Смешанные версии клиентов и серверов в августе–сентябре 2026 — ожидаемый источник инцидентов. Имеет смысл canary и явный pin версии протокола в корпоративном образе клиента, если политика это позволяет.

Безопасность и governance: shadow MCP

Shadow MCP — серверы, которые разработчики подключили локально (или в личном облаке), минуя каталог компании. По оценкам индустрии разрыв между «что думает security» и «что реально в IDE» часто кратный.

Практический минимум для команды:

• Allowlist серверов в управляемом конфиге IDE / agent gateway.
• Запрет произвольных remote URL без review.
• Секреты только через корпоративный vault / short-lived tokens, не в arguments навечно.
• Логи вызовов с редакцией чувствительных полей.
• Песочница для tools, которые запускают код или шелл — см. контур Docker Sandboxes.
• Разделение read-only и write tools; write — за подтверждением.

Prompt injection через содержимое resource/tool result остаётся реальной угрозой: сервер должен считать внешние тексты недоверенными данными, а не инструкциями.

Наблюдаемость и эксплуатация

Без метрик MCP в проде — чёрный ящик. Минимальный набор:

• RPS и ошибки по Mcp-Name.
• Latency p50/p95 по tool.
• Доля input_required и отказов пользователя на elicitation.
• Размер ответов (байт) — защита от случайного dump.
• Версии протокола клиентов.
• Аудит: кто (субъект OAuth) вызвал какой tool с каким handle.

Трейсинг (OpenTelemetry) удобно вешать на границу gateway → server → downstream API. Имя tool — отличный span attribute.

Сравнение: MCP, function calling и «просто OpenAPI»

MCP не отменяет OpenAPI: часто MCP-сервер — кураторская фасадная над вашим API. OpenAPI остаётся контрактом для сервисов; MCP — контрактом для агентов.

Типичные ошибки

Скопировали весь REST один-в-один в tools. Модель тонет в синонимах.
Спрятали критичное состояние в памяти процесса. После перехода на stateless и двух реплик «потеряли» черновики.
Дают write-tools без подтверждения. Один ошибочный вызов — инцидент.
Логируют arguments как есть. Утекают токены и PII.
Игнорируют версию протокола. Клиент обновился — сервер молча деградировал.
Считают localhost безопасным по умолчанию. Локальный сервер с опасным tool и общим ноутбуком — всё ещё поверхность атаки.

Практический чеклист запуска

1. Один сервер, 5–10 tools вокруг реальных задач команды.
2. Read-only сначала; write за MRTR.
3. OAuth / CIMD-план, проверка iss.
4. Деплой ≥2 инстансов без sticky.
5. Метрики по Mcp-Name, алерты на 5xx и аномальный размер ответа.
6. Allowlist в клиентах разработчиков.
7. Runbook миграции на 2026-07-28.
8. Связка с песочницей, если tool исполняет код.

Сценарии из практики

Агент сопровождает релиз

Сервер отдаёт tools: статус пайплайна, diff критичных файлов, создание release notes-черновика, вызов rollback только через elicitation. Без MCP тот же сценарий обычно живёт как набор скриптов в CI плюс ручной чат. С MCP тимлид в IDE спрашивает «почему красный deploy» и получает структурированный ответ tool, а не простыню логов.

Поддержка и внутренние данные

Read-only tools к CRM или базе знаний снижают риск, если агент помогает L2. Write-tools (смена статуса тикета, комментарий клиенту) лучше держать за подтверждением и с аудитом субъекта. Здесь снова важен компактный результат: агенту нужен «открытые тикеты клиента X с SLA < 4ч», а не полный JSON сущности.

Платформенная команда как владелец каталога

В зрелой модели MCP-серверы — продукты платформы, а не личные эксперименты. Платформа публикует каталог, SLA, версии протокола и канал breaking changes. Разработчики подключают серверы как зависимости, а не как «ещё один URL из твита».

Шлюз и enterprise-контур

Между IDE и origin-серверами почти всегда нужен gateway: единая точка OAuth, allowlist, rate limit, красaction логов, маршрутизация по Mcp-Name. Шлюз же удобно вешает canary: часть трафика на новую версию сервера. Без него каждый сервер заново изобретает auth и вы получаете зоопарк исключений в security review.

Имеет смысл разделить edge policy (кто вообще может вызвать MCP) и tool policy (какие имена tools доступны роли). Роль «стажёр» может иметь только read-каталог; роль «on-call» — write с elicitation. Это проще выразить на шлюзе, чем надеяться, что каждая IDE правильно локально отфильтрует tools.

Как тестировать сервер без полной IDE

Полный цикл «открыл Cursor → поговорил с моделью» дорог для регрессий. Держите контрактные тесты:

• tools/list стабилен по именам и обязательным полям схемы;
• golden-тесты на arguments → downstream HTTP (мок);
• два инстанса за nginx/caddy без sticky: один и тот же handle читается с обоих;
• сценарий MRTR: первый ответ input_required, второй — успех после inputResponses;
• негативные: просроченный токен, 403 на чужой ресурс, слишком большой ответ обрезается.

Отдельно гоняйте описания tools через чеклист для людей: незнакомый разработчик по одному description понимает, когда вызывать tool. Если нет — модель тоже не поймёт.

Частые вопросы

Дальнейшее чтение

• Как ИИ-агент получает доступ к API через MCP — пример курации tools над Вебмастером
• Безопасность песочницы для агентного ИИ
• Локальный ИИ не всегда означает приватность
• Корпоративная AI-платформа
• Архитектура enterprise RAG
• SEO / AEO / GEO готовность к AI-поиску — рядом по теме агентного доступа к данным сайта

Внешние первоисточники: анонс спецификации 2026-07-28, документация MCP и migration notes Tier 1 SDK.

Что сделать на этой неделе

Если тема для вас новая, не начинайте с «напишем свой Cursor-плагин». Возьмите один внутренний API, который агенты уже спрашивают вручную, и оберните в 5–7 tools с read-only доступом. Поднимите два инстанса без sticky, повесьте метрики по Mcp-Name, добавьте сервер в allowlist команды. Параллельно составьте список write-tools, которые нельзя отдавать без MRTR. Через неделю у вас будет не слайд про MCP, а рабочий контур и список дыр для следующего спринта.

Для уже существующих серверов неделя уходит на инвентаризацию session-состояния и пилот 2026-07-28 на одном некритичном сервисе. Документируйте handles и breaking changes так же, как для публичного HTTP API: changelog, версия протокола, контакт владельца.

Заключение

MCP в 2026 — это уже не эксперимент «подключим файловую систему к чату». Stateless-ядро, MRTR, заголовки для шлюзов и жёстче авторизация превращают протокол в обычную (и от того более требовательную) часть платформы. Выигрывают команды, которые проектируют маленький понятный каталог tools, явно переносят состояние в handles, ставят governance против shadow MCP и готовят миграцию спеки так же серьёзно, как миграцию API. Остальным рынок всё равно навяжет обновление клиентов — лучше встретить его с runbook, а не с инцидентом в пятницу.