Эра MCP: как Model Context Protocol незаметно перекроил AI-приложения в 2026 году

Anthropic опубликовала Model Context Protocol в конце 2024 года. Большинство отнесло его к категории «ещё один стандарт» и пошло дальше. Восемнадцать месяцев спустя MCP стал фактической трубопроводной системой стека AI-приложений. Claude Code построен вокруг MCP. Cursor запускает несколько серверов в одной сессии. Linear, Figma, Notion, GitHub, Slack и Stripe выпускают официальные серверы. Протокол победил.

Это рабочий букварь и одновременно состояние протокола. Что такое MCP на уровне провода, почему он обошёл прежние стандарты, какие канонические серверы работают в продакшене, что с ним делать и где он всё ещё спотыкается.

MCP: кабель, который наконец подошёл

Model Context Protocol позволяет любому AI-клиенту общаться с любым инструментом или источником данных через стандартный сервер. До MCP каждая интеграция была штучной. Каждый клиент изобретал свой формат инструментов. Каждый инструмент писал кастомный адаптер под каждый клиент. Комбинаторная стоимость была чудовищной, и большинство разработчиков сдавалось и хардкодило пару интеграций.

MCP это схлопнул. Написал сервер один раз, и любой MCP-клиент может им пользоваться. Написал клиент один раз, и любой MCP-сервер доступен. Правильный примитив в правильное время, развитие в открытую: Anthropic делает работу над протоколом, но не владеет стандартом.

Что такое MCP на уровне провода

MCP это JSON-RPC поверх транспорта с небольшим набором стандартных примитивов. Сервер предоставляет ресурсы (данные, которые модель может читать), инструменты (действия, которые она может вызывать) и промпты (шаблоны, которые может запускать пользователь). Клиент говорит с каждым сервером одними и теми же методами: list, read, call. Вот и вся абстракция.

JSON-RPC скучен, хорошо изучен, отлаживается через curl и проходит через любой файрвол, когда-либо построенный. Разделение на примитивы даёт модели достаточно структуры, чтобы понимать, что умеет сервер, и не заставляет сервер втискиваться в универсальную схему.

Три транспорта и почему они важны

MCP работает поверх трёх транспортов: stdio, HTTP плюс SSE и WebSockets. Stdio запускает сервер как дочерний процесс клиента, это значение по умолчанию для десктопных клиентов вроде Claude Desktop. HTTP плюс SSE запускает сервер как удалённый сервис, к которому клиент обращается и с которого стримит данные, это правильная форма для облачных MCP-серверов. WebSockets закрывают редкий случай, когда нужен полнодуплексный канал с удалённым сервером.

Транспорт в основном вопрос деплоя, а не возможностей. Одна и та же логика сервера работает на всех трёх. Команда может прототипировать локально на stdio и выпускать на HTTP плюс SSE за своим auth-шлюзом, не переписывая слой протокола.

Почему MCP победил там, где прежние стандарты проиграли

ChatGPT plugins, спецификации function-calling и OpenAPI-для-LLM пытались стать стандартом инструментов для агентов. Все три застопорились. MCP победил, потому что выбрал правильный примитив в правильное время с правильным управлением.

ChatGPT plugins были привязаны к одному клиенту и одной модели оплаты, а манифест предполагал stateless HTTP-эндпоинты со спецификациями OpenAPI, которые почти ни один реальный продукт не отдаёт чисто. Спецификации function-calling от каждой лаборатории были форматами одного вендора, наряженными в стандарты. OpenAPI-для-LLM пытался задним числом превратить формат документации в runtime-контракт, и несоответствие импедансов его раздавило.

Правильный примитив: сервер, а не плагин

Выбор MCP сделать интеграцию долгоживущим сервером с типизированным контрактом, а не stateless-манифестом плагина, это архитектурное решение, из которого вытекает всё остальное. Сервер может держать подключения к базам данных, кэшировать ресурсы, управлять токенами авторизации, стримить ответы и выкатывать обновления, не ломая клиент. Stateless-плагин почти ничего из этого не умеет. Реальным интеграциям нужны состояние, ретраи, наблюдаемость и обработка лимитов. Серверы это несут. Плагины с этим борются.

Правильное время: после tool use, до агентного стека

MCP вышел ровно тогда, когда разработчики перестали спорить, важен ли tool use, и начали спорить, как подключить десять инструментов к одному агенту, не переписывая их при каждом релизе. С tool use всё было решено. Следующей проблемой стала оркестрация. MCP дал слою оркестрации чистую абстракцию.

Помогло и управление. Anthropic открыла спецификацию, открыла организацию на GitHub, принимала внешние вклады с первого дня и позволяла другим лабораториям реализовывать клиенты без разрешения. К середине 2026 года OpenAI выпустила поддержку MCP в своём стеке Assistants. Gemini поддерживает его через Gemini API. Именно большой шатёр превратил побочный проект в стандарт.

Канонические MCP-серверы в продакшене

Всю тяжёлую работу делает короткий список. Большинство агентных стеков в 2026 году это какая-то комбинация этих девяти.

Figma предоставляет фреймы, компоненты, переменные и деревья слоёв, так что модель читает фрейм так, как разработчик читает спецификацию. Linear предоставляет задачи, проекты и циклы, превращая Claude Code в кодера, который понимает проект. Notion предоставляет страницы, базы данных и блоки, становясь универсальным хранилищем контекста. GitHub предоставляет репозитории, задачи, pull request'ы и actions, это каноническая поверхность кодового контекста. Slack предоставляет каналы, треды и поиск. Stripe предоставляет клиентов, подписки, платежи и метрики, так финансовые и операционные агенты читают отчётность.

Postgres предоставляет схемы, таблицы и запросы с областями только для чтения или для чтения и записи. Filesystem предоставляет изолированную директорию, так Claude Code читает и пишет репозиторий. Browserbase предоставляет через MCP хостируемый парк Chromium, так агенты управляют браузером, не заводя инфраструктуру. Девять серверов, девяносто процентов работы агентов.

MCP-first клиенты, которые заправляют всем

Claude Code это канонический MCP-клиент. Каждая интеграция это MCP-сервер. Добавить инструмент значит отредактировать конфиг и указать на бинарник сервера или URL. Claude Desktop поставляет ту же модель с интерфейсом для настройки серверов по рабочим пространствам. Cursor добавил поддержку MCP в начале 2026 года и теперь запускает несколько серверов в одной сессии, поэтому та же панель Cursor, которая правит код, может заодно вытянуть фрейм из Figma, завести задачу в Linear и сделать запрос в Postgres.

Continue.dev выходит MCP-first. JetBrains AI добавил поддержку MCP. Zed выпустил MCP. Каждая IDE и каждый AI-клиент, который хочет, чтобы его воспринимали всерьёз, теперь поставляется с поддержкой MCP, а продукты без истории про MCP начинают казаться устаревшими.

Что дизайнерам стоит делать с MCP на самом деле

Перестаньте скриншотить Figma. Откройте свои инструменты как MCP-воркспейс. Сервер Figma MCP даёт модели реальные координаты фреймов, реальные переменные и реальные экземпляры компонентов вместо угаданных значений пикселей с картинки.

Ход покрупнее: собрать единый MCP-воркспейс. Подключите Figma, Notion и репозиторий с дизайн-токенами к Claude Code тремя серверами. Один и тот же промпт «собери этот компонент по спецификации» читает фрейм из Figma, достаёт обоснование из Notion, ссылается на файл токенов и пишет код. Впервые дизайн-система в AI-воркфлоу реально ведёт себя как единый непрерывный артефакт. Тот же паттерн работает для Claude Skills: Skill это персона, а MCP это рабочее пространство.

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

Выпустите внутренний MCP-сервер для каждого внутреннего инструмента, которым владеет ваша команда. Направьте на него Claude Code. Смотрите, как тот же агент, что пишет код, начинает выполнять операции. Паттерн, который выигрывает в 2026 году, это не «AI-ассистент для X». Это «каждый инструмент вашей команды, открытый как MCP-сервер, и один клиент, который занимается оркестрацией».

Хотите помощь с подключением MCP к инструментам вашей команды, чтобы не потерять квартал на модели авторизации, или с выпуском стека внутренних MCP-серверов, который держится в продакшене? Наймите Brainy. ClaudeBrainy поставляет шаблон MCP-сервера и библиотеки промптов, а AppBrainy делает полноценные продуктовые сборки для команд, которые хотят, чтобы их агенты делили реальное рабочее пространство, а не скриншоты.

Сборка не гламурная. Большинство внутренних MCP-серверов это тонкая обёртка над существующим API плюс авторизация плюс список ресурсов и инструментов. Пара сотен строк кода, и дашборд деплоя вашей команды, трекер ошибок, биллинговая консоль или админка становятся ещё одним инструментом, которым может пользоваться агент. После десяти серверов агент это коллега, а не чат-бот.

Где MCP всё ещё проигрывает

Задержка при оркестрации нескольких серверов, сложность авторизации и отсутствие мобильной истории это три места, где MCP всё ещё спотыкается, и демо, которые их прячут, стоит игнорировать.

Задержка при оркестрации нескольких серверов реальна. Промпт, который за один ход затрагивает Figma, Notion и Postgres, может заплатить за три обращения туда-обратно, прежде чем у модели хватит контекста для ответа, а на медленных транспортах суммарное ожидание уходит за пять секунд. Кэширование помогает. Пулы соединений помогают. Но задержка от этого не исчезает.

Сложность авторизации это вторая дыра. MCP не стандартизирует авторизацию. Каждый сервер выбирает свою модель: OAuth, API-ключи, токены с ограниченной областью, иногда вообще ничего. Подключить пятнадцать серверов к одному клиенту значит пятнадцать хранилищ учётных данных, пятнадцать политик обновления и пятнадцать журналов аудита. Большинство команд недооценивает это до первого раза, когда сервер с данными клиентов протекает в контекст, не относящийся к клиентам.

Мобильной истории нет. MCP предполагает долгоживущий клиент, который может запускать локальные процессы, держать сетевые соединения и управлять жизненным циклом серверов. Ничто из этого не соответствует мобильной модели исполнения. Полезного MCP на iOS в середине 2026 года нет. Несколько команд работают над профилями только для удалённого доступа, но протокол пока не дорос.

Три режима отказа, которые прячут раздутые MCP-демо

Большинство сожалений о MCP в 2026 году сводится к одним и тем же трём дырам.

Первое. Демо с отмашкой на авторизацию. Докладчик показывает сервер, подключённый к CRM клиента, агент отвечает, аплодисменты. Авторизация была личным токеном демо-аккаунта. Направить ту же конфигурацию на мультитенантную продакшен-систему значит перестраивать авторизацию с токенами ограниченной области, OAuth-потоками и изоляцией тенантов. Решение: выбирайте модель авторизации до выпуска сервера, а не после.

Второе. Демо только для локальной машины. Всё работает на ноутбуке докладчика, потому что сервер идёт через stdio с локальной файловой системой и личной базой данных. Ничего из этого не доедет до команды, которой нужны HTTP плюс SSE и общие учётные данные. Решение: прототипируйте на stdio, выпускайте на HTTP плюс SSE за своим auth-шлюзом и проверьте историю деплоя, прежде чем команда начнёт ей доверять.

Третье. Демо с одним сервером. Агент прекрасно использует один сервер, а докладчик делает вид, что оркестрация нескольких серверов это просто ещё одна строчка в конфиге. В продакшене второй и третий серверы приносят задержки, конфликты авторизации и путаницу в промптах. Решение: проектируйте набор серверов как систему, а не как список. Задокументируйте границы.

Первый шаг по ролям

У каждой роли в команде свой первый шаг с MCP. Работа распределена неравномерно.

Паттерн. Дизайнеры и фронтенд-разработчики отвечают за сборку воркспейса. Бэкенд-разработчики отвечают за контракт сервера и модель авторизации. Основатели выбирают направление.

FAQ

Что такое Model Context Protocol?

MCP это открытый протокол, который позволяет любому AI-клиенту общаться с любым инструментом или источником данных через стандартный сервер. Сервер предоставляет ресурсы, инструменты и промпты. Клиент говорит на JSON-RPC поверх stdio, HTTP плюс SSE или WebSockets. Anthropic опубликовала спецификацию в конце 2024 года, и к середине 2026 года это фактический стандарт интеграции инструментов с агентами.

MCP только для Claude?

Нет. MCP поддерживают Cursor, Continue.dev, JetBrains AI, Zed и стек Assistants от OpenAI. Gemini поддерживает его через Gemini API. Anthropic опубликовала протокол, но не владеет им.

Нужно ли мне писать собственный MCP-сервер?

Для канонических инструментов, скорее всего, нет. Figma, Linear, Notion, GitHub, Slack, Stripe, Postgres, Filesystem и Browserbase выпускают официальные или канонические серверы. Свой придётся писать для внутренних инструментов, кастомных баз данных и проприетарных API. Большинство внутренних MCP-серверов это пара сотен строк кода плюс модель авторизации.

Чем MCP отличается от tool use?

Tool use это возможность модели вызывать функции со структурированным входом и выходом. MCP это протокол, который определяет, как инструменты обнаруживаются, описываются и вызываются в любом клиенте. Tool use это двигатель. MCP это проводка. Букварь про агентов computer use разбирает третью ногу, когда чистого API для вызова нет.

Когда MCP не имеет смысла?

Когда у вас один инструмент, один клиент и захардкоженная интеграция, которая уже работает. Выигрыш в мире с несколькими инструментами и несколькими клиентами. Для одного агента и одного API вполне хватит обычного tool use.

Сдвиг, который MCP на самом деле открывает

MCP это не более умный агент. Это протокол, который наконец позволил агентам делить рабочее пространство, и продукты, которые считают это пространство своей основной поверхностью, выиграют следующий раунд.

Большинство команд по-прежнему воспринимают AI-интеграции как фичу, прикрученную к продукту. Команды, которые вырываются вперёд, считают рабочим пространством AI-клиент плюс набор MCP-серверов, а продукт это то, что появляется на краях. Первые выпускают ещё одну вкладку с чатом. Вторые выпускают инструмент, которым команда реально пользуется. Тот же сдвиг виден в сравнении AI-редакторов кода и в разборе Claude 4.7 для разработчиков.

Если в вашем стеке в этом квартале нет истории про MCP, агенты ваших клиентов вас обойдут. Если есть, эти агенты начнут относиться к вашему продукту как к коллеге. Выберите воркфлоу. Выпустите сервер. Соберите воркспейс.

Если вам нужна помощь с подключением MCP к инструментам вашей команды, чтобы не потерять квартал на модели авторизации, или с выпуском стека внутренних MCP-серверов, который держится в продакшене, наймите Brainy. ClaudeBrainy поставляет наборы Skill и шаблоны MCP-серверов. AppBrainy делает полноценные продуктовые сборки для команд, которые хотят, чтобы их агенты делили реальное рабочее пространство, а не скриншоты.