Что такое MCP-сервер? Как работают MCP и MCP UI в 2026 году

1 апреля 2025 года Invariant Labs опубликовала инструмент под названием add. Он принимал два числа и возвращал их сумму. Но в его описании был еще и блок с пометкой IMPORTANT, невидимый в интерфейсе клиента, который приказывал модели прочитать ~/.cursor/mcp.json и ~/.ssh/id_rsa и отправить оба файла наружу через лишний параметр. Модель подчинилась. Пользователь видел сложение.

Эта демонстрация лучшее введение в MCP-серверы, которое я знаю, потому что она показывает обе половины сразу. Протокол сработал ровно так, как задумано: AI-клиент обнаружил инструмент, прочитал его описание и вызвал его. Модель доверия была той частью, которую еще никто не построил.

Что такое MCP-сервер

MCP-сервер это программа, которая открывает AI-приложениям инструменты, данные и промпты через Model Context Protocol (MCP). Официальная документация определяет MCP как «открытый стандарт для подключения AI-приложений к внешним системам». AI-клиент, например Claude, ChatGPT, Visual Studio Code или Cursor, подключается к серверу, спрашивает, что тот предлагает, и вызывает эти возможности от имени пользователя.

Anthropic анонсировала MCP 25 ноября 2024 года вместе с шестью готовыми серверами: Google Drive, Slack, GitHub, Git, Postgres и Puppeteer. OpenAI приняла протокол в марте 2025 года. Google DeepMind последовала в апреле. В декабре 2025 года Anthropic передала протокол Agentic AI Foundation, целевому фонду под эгидой Linux Foundation, который основали Anthropic, Block и OpenAI.

Проблема в размножении связей. До MCP каждое приложение ИИ для работы с GitHub писало свой коннектор, а каждый поставщик создавал подключение к каждому приложению. Десять моделей и десять инструментов могли означать до ста интеграций. MCP сокращает число до двадцати: клиент один раз реализует протокол, а система предоставляет один сервер.

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

Как работает MCP-сервер

Текущая спецификация, версия 2026-07-28, использует сообщения JSON-RPC 2.0 между тремя ролями. Ее собственное описание занимает три строки: хосты это «LLM-приложения, которые инициируют подключения», клиенты это «коннекторы внутри хост-приложения», а серверы это «сервисы, которые предоставляют контекст и возможности».

Хост, клиент, сервер

Хост это приложение, в котором вы печатаете: Claude Desktop, IDE, ваш собственный агент. Внутри него работает по одному клиенту на каждое подключение к серверу. Сервер находится на другой стороне и общается с реальной системой, будь то база данных Postgres, GitHub API или папка на вашем диске. Хост решает, что видит модель и что должен подтвердить пользователь. Сервер решает, что сделает система за ним.

1. Хост Claude Desktop · IDE · ваш собственный агент

   показывает модели инструменты, запрашивает согласие пользователя

2. Клиент по одному на каждое подключение к серверу

   говорит на JSON-RPC через stdio или Streamable HTTP

3. MCP-сервер инструменты · ресурсы · промпты

   описывает, что предлагает, и выполняет вызовы

4. Базовая система база данных · SaaS API · локальные файлы

   выполняет работу

Инструменты, ресурсы и промпты

Сервер может предлагать три вида вещей:

• Инструменты (tools) это функции, которые модель может выполнить: create_issue, query_orders, send_email. У каждого есть имя, описание и JSON Schema для входных данных.
• Ресурсы (resources) это контекст и данные, которые читает пользователь или модель: файл, схема базы данных, запись.
• Промпты (prompts) это шаблоны сообщений и сценариев, которые может выбрать пользователь, например «кратко опиши этот pull request».

Инструментам достается больше всего внимания, потому что они действуют. По той же причине на них приходится и больше всего риска.

Вызов инструмента, шаг за шагом

Ревизия 2026-07-28 сделала MCP протоколом без состояния. Рукопожатия initialize больше нет. Каждый запрос несет версию протокола и возможности клиента в поле _meta, а серверы обязаны реализовать метод server/discover, чтобы клиент мог заранее узнать, что они поддерживают. Один вызов инструмента теперь проходит так:

1. Пользователь просит: создай тикет для этого бага

2. Шаг 1

   Обнаружение

   • Клиент может вызвать server/discover, чтобы узнать версии и возможности
3. Шаг 2

   Список инструментов

   • tools/list возвращает имена, описания и схемы входных данных
4. Шаг 3

   Модель выбирает инструмент

   • Хост передает модели определения инструментов
5. Шаг 4

   Согласие пользователя

   • По спецификации хост обязан получить явное согласие перед вызовом любого инструмента
6. Шаг 5

   Вызов

   • tools/call с аргументами, версия протокола в _meta

7. Не хватает данных? Сервер возвращает input_required, клиент повторяет вызов с ответами

   Шаг 6

   Результат

8. Результат возвращается модели как контекст

Шаг 6 появился в этой ревизии. Сервер, которому нужно больше информации, больше не отправляет клиенту собственный запрос. Он возвращает результат с пометкой input_required, клиент собирает ответ и повторяет исходный вызов. Спецификация называет это паттерном Multi Round-Trip Request.

Транспорты: stdio и Streamable HTTP

Спецификация определяет два стандартных транспорта:

• stdio: клиент запускает сервер как подпроцесс и обменивается с ним JSON-RPC, разделенным переводами строк, через стандартный ввод и вывод. Так работает большинство локальных серверов, и это значит, что сервер работает на вашей машине с вашими правами.
• Streamable HTTP: каждое сообщение это HTTP POST на один эндпоинт, а ответы приходят как JSON-объект или как поток событий в рамках запроса. Так работают удаленные, размещенные серверы.

Старый транспорт HTTP+SSE официально признан устаревшим. Ревизия 2026-07-28 также убрала сессии на уровне протокола и заголовок Mcp-Session-Id. Сервер, которому нужно состояние между вызовами, теперь сам выпускает свой идентификатор и получает его обратно как обычный аргумент инструмента.

Авторизация

Авторизация в MCP опциональна и применяется только к HTTP. Для stdio спецификация говорит, что серверам следует брать учетные данные из окружения. По HTTP защищенный MCP-сервер выступает как resource server по OAuth 2.1. Он обязан публиковать OAuth Protected Resource Metadata (RFC 9728), чтобы клиенты могли найти его сервер авторизации. Клиенты обязаны указывать точный сервер, для которого предназначен токен (resource indicators по RFC 8707). Серверы обязаны отклонять любой токен, выпущенный не для них, а рекомендации по безопасности прямо запрещают «token passthrough», то есть пересылку токена клиента без изменений в нижестоящий API.

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

Что добавляет MCP UI: серверы, которые возвращают интерфейс

Текстовые ответы перестают работать в тот момент, когда пользователю нужно сравнить сорок строк, поправить форму из двенадцати полей или подтвердить пакет изменений одно за другим. «MCP UI» это название, под которым люди ищут решение: сервер возвращает интерактивный интерфейс, который отрисовывается прямо в AI-клиенте, рядом с диалогом.

Статус важно передать точно. Идея началась с общественного проекта MCP-UI. OpenAI создала похожий механизм в Apps SDK. Проект MCP вместе с обеими сторонами предложил общий стандарт 21 ноября 2025 года, а 26 января 2026 года опубликовал MCP Apps как первое официальное расширение MCP. Пакеты MCP-UI теперь реализуют эту спецификацию и остаются площадкой сообщества для будущих улучшений.

Значит, MCP UI сегодня это MCP Apps. Расширение официальное, но это именно расширение, а не ядро протокола. Расширения опциональны: их должны поддерживать и клиент, и сервер, и документация прямо говорит, что «поддержка хостов зависит от клиента». Документация MCP Apps называет поддерживающими хостами Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam и Archestra.AI. Сервер, чьи инструменты возвращают UI, по-прежнему должен работать и для клиента, который показывает только текст.

Механически расширение использует собственные элементы MCP:

1. Описание инструмента содержит _meta.ui.resourceUri, указывающий на ресурс ui://.
2. Хост загружает этот ресурс, HTML-страницу с ее скриптами, и может подгрузить его заранее, еще до вызова инструмента.
3. Хост отрисовывает его в изолированном iframe, который не может читать родительскую страницу, ее cookies или хранилище.
4. Приложение и хост общаются через postMessage на JSON-RPC-диалекте MCP. Приложение может запрашивать вызовы инструментов, а хост решает, какие разрешить.

Цена реальна. Вы теперь поставляете веб-фронтенд внутри чужого приложения, с content security policy, которую нужно объявить, с правилами отрисовки, которые вы не контролируете, и с текстовым запасным вариантом для каждого хоста, который интерфейс игнорирует. Выигрыш в том, что подтверждение перестает быть стенограммой чата. Список удачных сценариев в документации заканчивается словами «утверждение авансовых отчетов, ревью изменений в коде или сортировка задач», и в этом честная суть: MCP UI лучше всего подходит для решений, а не для украшений.

Пример Tajo только для чтения

Поверхность Alto MCP в Tajo включает query_contacts, который ищет контакты, сохранённые в подключённом рабочем пространстве. Найдите существующий контакт по адресу электронной почты и проверьте возвращённый ID, состояние согласия на письма и время последнего наблюдения. Отдельный инструмент get_contact_topic_status читает подписки контакта по темам.

Это чтение данных рабочего пространства. Инструменты не получают свежую копию данных поставщика, не запускают синхронизацию и не отправляют сообщения. Они также не доказывают работу всех коннекторов. Недостающие или устаревшие данные исследуйте в источнике. Пустой результат не означает, что человека нет в Brevo.

Через документацию Tajo MCP подключите поддерживаемый клиент и проверьте инструменты, действительно доступные Вашему авторизованному рабочему пространству. Интерактивная панель помогает проверке, если приложение поддерживает MCP Apps; текстовый результат всё равно должен объяснять итог.

Вызов инструмента не равен устойчивой синхронизации

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

После тайм-аута чтение обычно можно повторить. Отправка или платёж уже могли произойти. Сохраните журнал исполнения и сверите результат до новой попытки. Уверенность модели не даёт разрешения и не делает повтор безопасным.

Запись конкретного контакта в целевой системе разбирает руководство по API Brevo. Когда вычисляемым полям нужна отдельная поддерживаемая синхронизация, поясняет reverse ETL.

Счет за безопасность прилагается к протоколу

Возражение заслуживает того, чтобы привести его полностью: «MCP дает вероятностной модели список функций, которые могут удалять данные и отправлять письма, а затем доверяет тексту, написанному незнакомцами, чтобы их описать. Это не стандарт интеграции. Это атака на цепочку поставок со спецификацией». Большая часть этого верна. Спецификация согласна с посылкой. Ее раздел о безопасности говорит, что инструменты «представляют собой выполнение произвольного кода, и с ними нужно обращаться с должной осторожностью», что описания инструментов «следует считать недоверенными, если они не получены от доверенного сервера», и что MCP «не может обеспечить соблюдение этих принципов безопасности на уровне протокола».

Вот что накопилось на сегодня:

• Tool poisoning (отравление инструментов). Публикация Invariant Labs в апреле 2025 года, тот самый инструмент add. В том же посте описаны rug pull, когда сервер меняет описание инструмента после того, как вы его одобрили, и shadowing (затенение), когда один вредоносный сервер переписывает поведение модели по отношению к доверенному серверу.
• Компрометация локального сервера. В июле 2025 года JFrog раскрыла CVE-2025-6514 в mcp-remote версий с 0.0.5 по 0.1.15, которая позволяла вредоносному серверу выполнять команды на машине пользователя. Тем же летом CVE-2025-49596 затронула собственный MCP Inspector от Anthropic, который по умолчанию поставлялся без аутентификации.
• Раздувание скоупов. Официальные лучшие практики безопасности называют этот паттерн: токены с files:* или admin:*, выданные заранее, потому что сервер перечислил все скоупы, а клиент запросил их все.
• Официальная обеспокоенность. В мае 2026 года Агентство национальной безопасности США (NSA) заявило, что «стремительное распространение MCP опередило развитие его модели безопасности».

Ошибается возражение в выводе. Решением никогда не было перестать подключать модели к системам. Команды и так это делали, с сырыми API-ключами, вставленными в промпты и скрипты, вообще без журнала аудита. Решение в том, чтобы относиться к MCP-серверу как к любой другой привилегированной зависимости:

• Устанавливайте серверы только из источников, которым доверили бы те же учетные данные и вне MCP.
• Предпочитайте удаленные серверы с OAuth и узкими скоупами локальным бинарникам с долгоживущими ключами.
• Требуйте подтверждения человеком для каждой записи и фиксируйте, кто что одобрил.
• Фиксируйте версии серверов и проводите повторную проверку, когда меняется описание инструмента.
• Открывайте инструменты под задачи, а не весь API. Модель не сможет злоупотребить эндпоинтом удаления, который никогда не открывали.

Протокол стандартизировал ящик. Проверять груз по-прежнему ваша работа.

Построить MCP-сервер или взять готовый

Публичные каталоги вроде mcp.so собирают серверы сообщества, а многие SaaS-вендоры публикуют собственные. Например, Brevo поставляет MCP-сервер, который также разделен на отдельные серверы, так что агенту можно дать контакты без кампаний. Решение зависит не столько от усилий, сколько от того, кто должен определять форму инструментов.

Какой MCP-сервер должен использовать ваш агент?

1. Вендор публикует сервер, который покрывает задачу

   Используйте сервер вендора

   Он следует за API, и его поддерживает вендор.

2. Одна система, но нужно меньше действий или более безопасные

   Используйте его с урезанными правами

   Выдайте минимальные скоупы и откройте только те группы инструментов, которые нужны агенту.

3. Внутренние данные или система без сервера

   Постройте небольшой сервер

   Несколько инструментов под задачи поверх вашего собственного API, с вашей собственной аутентификацией.

4. Задача охватывает две системы или больше

   Постройте или возьмите управляемый слой

   Один набор инструментов, правил согласия и истории аудита для всех систем сразу.

Построить базовый сервер это простая часть. С официальным SDK рабочий stdio-сервер с одним инструментом делается за полдня. Затраты приходят позже: OAuth для HTTP-версии, устаревания (ревизия 2026-07-28 объявила устаревшими Roots, Sampling и Logging, а также Dynamic Client Registration) и постоянная работа над описаниями инструментов, которые модель читает правильно. Оборачивать API по принципу один эндпоинт, один инструмент это самая частая ошибка. Каждое описание инструмента это текст, который модель должна прочитать и взвесить, поэтому короткий список инструментов под задачи выигрывает у всей поверхности API.

MCP, API, интеграции и iPaaS

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

Это различие проводит четкую границу с двумя другими вещами, с которыми MCP путают:

• Интеграции и iPaaS (основные платформы сравниваются здесь) перемещают данные по расписанию или по триггеру, детерминированно, независимо от того, сидит ли кто-то в чате. Ночная синхронизация 40 000 заказов в CRM не должна зависеть от того, решит ли модель сделать 40 000 вызовов инструментов.
• Обратный ETL (reverse ETL) отправляет смоделированные данные из хранилища обратно в рабочие инструменты. Что такое обратный ETL и когда он уместен отдельная тема, и это пайплайн, а не разговор.
• MCP нужен для моментов, когда человеку или агенту требуется что-то спросить, проверить или сделать в этих системах, по запросу.

Ошибка случается в обе стороны. Одни команды строят MCP-серверы для массовой синхронизации и получают медленные, дорогие, невоспроизводимые пайплайны. Другие строят аккуратные интеграции, а потом дают своему AI-ассистенту сырой API-ключ, чтобы он делал к ним запросы, и получают неуправляемый черный ход.

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

За 22 месяца MCP прошел путь от шести эталонных серверов до проекта Linux Foundation, на котором говорят Claude, ChatGPT, VS Code и Cursor. Подключить модель к системе теперь дешевая часть. Настоящая работа в том, чтобы решить, что ей там разрешено делать.