MCP-шлюз: зачем он команде и сколько стоит эксплуатация

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

Что делает MCP-шлюз

MCP-шлюз — это единая точка контроля между агентами и MCP-серверами: здесь проверяют подлинность пользователей, задают списки разрешённых инструментов, ведут журналы и ограничивают частоту запросов. Model Context Protocol, или MCP, — общий интерфейс, через который приложение на базе ИИ обнаруживает инструменты и вызывает их. Шлюз позволяет управлять этими подключениями централизованно. Набор доступных средств контроля зависит от реализации. В объяснении Kong описана именно эта роль: проксирование и применение политик.

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

Для разработчиков, использующих Claude, ChatGPT, Codex и Cursor, преимущество в том, что доступ к инструментам можно согласовать во всех одобренных организацией клиентах. При этом тарифы клиентов, поддержку аутентификации и способы подключения всё равно нужно проверять по отдельности.

У каждого средства контроля своя задача:

• Аутентификация: установить, какой пользователь или какая рабочая нагрузка отправляет запрос. Затем авторизация определяет, что им разрешено делать. Один общий API-ключ может лишить вас возможности установить, кто именно совершил действие.
• Списки разрешённых инструментов: показывать и разрешать только заранее выбранные действия. Например, помощнику поддержки можно разрешить поиск клиента, но запретить инструмент удаления. Правило должно действовать и при получении списка инструментов, и при самом вызове.
• Журналирование: сохранять сведения об исполнителе, сервере, инструменте, решении политики и результате — всё, что потребуется для разбора действия. Заранее определите, какие аргументы можно записывать и как обрабатывать чувствительные значения.
• Ограничение частоты запросов: задавать лимиты по учётной записи, инструменту или вышестоящему сервису, который нужно защитить. Агент, зациклившийся на повторных вызовах, должен упереться в заданный лимит раньше, чем перегрузит бэкенд.

Это требования, которые нужно проверять, а не гарантированный набор функций любого продукта со словом «шлюз» в названии. Локальный агрегатор инструментов может быть полезен, даже если интеграцию с корпоративными учётными записями или ограничение частоты запросов вам придётся реализовать самостоятельно.

Чем MCP-шлюз отличается от MCP-сервера

MCP-сервер предоставляет возможности, а MCP-шлюз управляет доступом к одному или нескольким серверам. Сервер может предоставлять инструмент для запроса к базе данных или создания обращения. Шлюз показывает клиентам одобренные возможности, направляет вызовы и применяет настроенные средства контроля.

В архитектуре MCP клиент получает список инструментов через tools/list, а вызывает их через tools/call. Для агента шлюз может выступать сервером, а для вышестоящих серверов — клиентом. Какие записи вызывающая сторона вправе читать или изменять, по-прежнему определяет само приложение.

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

В чём отличие от шлюза для ИИ или LLM

Шлюз для ИИ или LLM, то есть большой языковой модели, управляет запросами к моделям. MCP-шлюз управляет запросами к инструментам. От этого различия зависит, какую задачу решает каждый из них.

В документации Cloudflare AI Gateway описаны журналирование запросов к моделям, кэширование, ограничения частоты, повторные попытки и переключение на резервные варианты. Эти функции помогают контролировать стоимость инференса и надёжность работы с провайдерами. Политика инструментов в MCP-шлюзе решает другую задачу: может ли агент вызвать одобренное действие в системе, где хранятся данные клиентов.

Некоторые продукты охватывают оба вида запросов. Оценивайте их по отдельности: бюджет на модель не подтверждает права на инструмент, а список разрешённых инструментов не ограничивает все запросы к моделям. Если выделенный бюджет должен решить проблему маршрутизации моделей, расходов на инференс или отказов провайдеров, обратитесь к сравнению шлюзов для ИИ-агентов, которые пишут код.

Обычный API-шлюз тоже может проверять подлинность отправителя и ограничивать частоту HTTP-запросов. Поддержка MCP позволяет учитывать содержимое запросов: обнаружение инструментов, их названия и аргументы вызова. Несколько действий могут использовать один URL /mcp, поэтому разрешение только на уровне этого адреса может дать гораздо больше прав, чем предполагала ваша политика инструментов.

Что изменилось 24 сентября 2026 года

Cloudflare открыла MCP Server Portals для всех клиентов Cloudflare 24 сентября 2026 года, переведя продукт в общедоступный статус. В официальном анонсе описаны единая точка подключения к одобренным серверам и журналы Access для действий с инструментами, промптами и ресурсами.

Среди возможностей релиза также названы аутентификация автономных агентов с помощью сервисных токенов, маршрутизация через Gateway для более подробных HTTP-журналов и предотвращения утечек данных, а также поддержка Logpush для экспорта сведений об активности. Предотвращение утечек данных, или DLP, проверяет содержимое по правилам выявления чувствительной информации.

Практический результат — управляемый способ централизовать доступ к удалённым MCP-серверам без самостоятельной эксплуатации процесса шлюза. Но общедоступность не снимает двух вопросов: совместимы ли ваши серверы и клиенты с продуктом и включает ли выбранный тариф нужные функции аудита.

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

Когда небольшой команде нужен MCP-шлюз

Шлюз нужен, когда правила доступа должны сохраняться при смене клиента, сотрудника или владельца сервера. Если серверов уже больше нескольких, стоит присмотреться к ситуации. Но более веская причина — расхождение политик доступа.

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

Возьмём условный пример: шесть разработчиков, четыре клиента для агентов и восемь MCP-серверов. Каждый разработчик настраивает каждый сервер в каждом клиенте:

• Прямые подключения: 6 × 4 × 8 = 192 записи подключения клиентов к серверам.
• Один общий шлюз: 6 × 4 = 24 записи подключения клиентов к шлюзу, плюс 8 описаний вышестоящих точек подключения.
• Всего ссылок на точки подключения: 32.

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

Польза в том, что адрес одобренного сервера или политику инструментов можно будет менять централизованно. Ошибиться централизованно тоже возможно. Ведите версии политики и определите, кто вправе её менять.

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

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

Что учитывать разработчикам, эксплуатации и закупкам

Разработчикам: сначала проверьте транспорт

Выбирайте шлюз, который способен подключиться к вашим серверам. При stdio клиент общается с локальным процессом через его потоки ввода и вывода. Streamable HTTP передаёт трафик MCP к удалённой точке подключения. Оба варианта описаны в архитектуре протокола.

Управляемый удалённый шлюз не может автоматически запустить процесс stdio на вашем ноутбуке. Чтобы превратить такой процесс в размещённый на сервере HTTP-сервис, придётся решить вопросы развёртывания и учётных данных. Проверьте совместимость транспорта до замены настроек клиентов.

Эксплуатации: контролируйте реальный маршрут вызовов

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

Для процесса поддержки важны сведения о том, кто и каким действием изменил обращение. Запись об успешном подключении сама по себе на этот вопрос не отвечает. Проверяйте, какие именно записи формирует выбранный продукт: одинаковое слово «журналирование» не означает одинаковую доказательную ценность.

Закупкам: оплачивайте нужный уровень контроля

Заложите в бюджет шлюз, вышестоящие серверы и работу человека, который отвечает за то и другое. Тариф Free может подходить по числу пользователей, но не по сроку хранения журналов. Открытое ПО может отвечать требованиям к развёртыванию, но требовать дополнительной интеграции с системой учётных записей.

Если требования включают обнаружение несанкционированных серверов, подробную проверку во время выполнения или реагирование на инциденты в масштабе предприятия, такой более широкий выбор рассмотрен в сравнении платформ безопасности MCP.

Три варианта MCP-шлюза: проверено 4 октября 2026 года

Cloudflare подходит для управляемого доступа к удалённым серверам, Docker — для запуска серверов в контейнерах, Lasso — для оркестрации с помощью плагинов. Выбор зависит от транспорта, контроля доступа, журналирования и того, кто будет эксплуатировать сервис.

Приведённые ниже цены и лицензии проверены по публичным страницам и репозиториям владельцев 4 октября 2026 года. Сценарии расходов далее — расчёты с явно указанными допущениями.

Источники: тарифы Cloudflare, лицензия Docker и лицензия Lasso.

Cloudflare MCP Server Portals

Cloudflare MCP Server Portals — управляемый вариант для одобренных удалённых MCP-серверов, если Cloudflare One соответствует вашим требованиям к учётным записям и эксплуатации. Продукт объединяет серверы за одной HTTP-точкой подключения, использует Cloudflare Access для аутентификации и позволяет администраторам выбирать инструменты и промпты, доступные через портал.

В текущей таблице тарифов указаны Free за $0 с лимитом 50 пользователей, Pay-as-you-go за $7 за пользователя в месяц и Contract с индивидуальной годовой ценой за пользователя. Стандартный срок хранения журналов составляет до 24 часов на Free и до 30 дней на Pay-as-you-go; конкретный срок зависит от используемого сервиса.

Главные ограничения — совместимость и право на нужные функции аудита. Согласно документации порталов Cloudflare, поддерживаются удалённые HTTP-серверы MCP, до 80 серверов на портал. Сервер, работающий только через stdio, сначала нужно разместить за HTTP-точкой подключения с аутентификацией. Некоторые вышестоящие серверы отклоняют подключения клиентов через прокси.

Журналы портала и экспорт журналов во внешнюю систему — тоже разные статьи закупки: интеграция Cloudflare с Logpush доступна только на Enterprise. Проверьте наличие этого права, прежде чем обещать аудитору внешний архив.

Выбирайте этот вариант для совместимых удалённых инструментов, если нужен общий контроль доступа без ответственности за вычислительную инфраструктуру шлюза. Отдельные расходы на пользователей, хостинг и аудит разобраны в статье «Бесплатен ли Cloudflare MCP Portals?».

Docker MCP Gateway

Docker MCP Gateway — вариант с открытым исходным кодом для тех, кому нужно также организовать запуск MCP-серверов. Он запускает серверы в изолированных контейнерах, управляет их жизненным циклом, учётными данными и маршрутизацией, а также группирует доступные серверы в профили. Профиль — сохранённый набор серверов, доступных клиенту.

Код самостоятельного шлюза распространяется под лицензией MIT. Docker описывает ручную установку с Docker Engine, а также вариант с Docker Desktop. За хост, обновления, учётные данные и схему развёртывания по-прежнему отвечаете вы.

У Docker Desktop отдельные коммерческие условия. На странице лицензирования Docker указано: для бесплатного коммерческого использования Desktop малый бизнес должен иметь менее 250 сотрудников и годовую выручку менее $10 млн. Более крупным организациям и государственным учреждениям нужна платная подписка. Docker Pro стоит $11 за пользователя в месяц при ежемесячной оплате или $9 за пользователя в месяц на годовом тарифе. Это стоимость подписки Desktop, а не плата за код шлюза.

Есть и отдельный коммерческий продукт: в текущей документации Docker MCP Gateway в составе Docker AI Governance обозначен как доступный только по приглашению, через отдел продаж. Публичный репозиторий под MIT остаётся вариантом для самостоятельного использования кода. Нельзя считать стоимость коммерческого решения для управления доступом равной стоимости лицензии репозитория.

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

Lasso MCP Gateway

Lasso MCP Gateway — посредник для запросов и ответов MCP, расширяемый плагинами. Он читает конфигурации серверов, управляет настроенными серверами и предоставляет их возможности через единый интерфейс. В репозитории есть примеры для Cursor и Claude Desktop.

Код шлюза распространяется под лицензией MIT. Плагин basic маскирует токены и секреты. Необязательный плагин presidio отвечает за маскирование персональной информации, а xetrack добавляет трассировку с хранением событий в SQLite и требует отдельной установки.

Главное ограничение здесь связано с тем, как работает плагин. Плагину lasso нужен API-ключ Lasso, а для проверок он отправляет содержимое через API Lasso. Лицензия MIT на шлюз не определяет цену или условия использования этого размещённого у провайдера API; в README цена также не указана. При составлении бюджета и решении о том, куда допустимо передавать содержимое, учитывайте его как отдельную зависимость от сервиса.

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

Во сколько обходится эксплуатация MCP-шлюза

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

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

Вот пример планирования для небольшой команды. Примем внутреннюю полную стоимость труда за $100/час, включая накладные расходы, а дополнительные расходы на вычислительные ресурсы и журналы при самостоятельном размещении — за $20/месяц. Это выбранные исходные данные для бюджета, а не цены поставщиков или измеренные требования к хостингу.

При этих допущениях самостоятельное размещение экономит $180/месяц относительно базовых расходов на поддержку прямых подключений. Оно обходится в $220/месяц, хотя лицензия на код шлюза стоит $0. Если внедрение занимает восемь рабочих часов, добавьте $800. Оценка для первого года: 12 × $220 + $800 = $3,440, тогда как указанный базовый сценарий поддержки прямых подключений стоит $4,800.

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

Подставьте цены поставщиков для своей команды

Для шести активных пользователей Cloudflare тариф Free может означать $0 платы за тариф Cloudflare в пределах лимита 50 пользователей. В сценарии совместимого управляемого сервиса из таблицы внутренние трудозатраты на политику всё равно составят $50/месяц. Хостинг вышестоящих серверов, использование моделей, подписки и дополнения в эту сумму не входят.

Для 60 приобретённых мест Pay-as-you-go опубликованная ставка $7 даёт 60 × $7 = $420/месяц, или $5,040/год. Здесь оплачиваются все 60 приобретённых мест. Лимит Free в 50 пользователей относится к отдельному тарифу: вычитать эти 50 мест из расчёта нельзя. В документации Cloudflare о местах сказано, что число доступных мест определяется числом приобретённых пользователей, а одна учётная запись занимает одно место независимо от количества используемых приложений.

Для шести новых подписок Docker Pro с ежемесячной оплатой, если они нужны для выбранного варианта с Desktop, цена Docker даёт 6 × $11 = $66/месяц. Если подходящие подписки уже есть, дополнительные расходы на подписку могут составить $0. Для развёртывания на Engine нужен собственный инфраструктурный бюджет.

Для Lasso начните с кода шлюза под MIT, затем добавьте расходы на хост и журналирование. Если включаете плагин, зависящий от API, отдельно получите условия размещённого у провайдера сервиса. Зависимость с неизвестной ценой нельзя честно занести в бюджет как $0.

Что выбрать: прямые подключения, свой шлюз или управляемый сервис

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

Выбирайте открытое ПО с самостоятельным размещением, когда можете назначить ответственного за среду выполнения. Для MCP-серверов в контейнерах понятнее начинать с Docker. Если нужен перехват запросов через плагины, более уместен пример Lasso. Отдельно заложите в бюджет интеграцию с системой учётных записей, хостинг и журналы; проверьте работу необходимых средств контроля.

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

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

Какие ожидания от MCP-шлюзов завышены

Один URL сам по себе не создаёт единую надёжную систему разрешений. Главное заблуждение — считать, что подключение к шлюзу разом решает вопросы авторизации, аудита и безопасности.

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

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

У Cloudflare есть конкретный пример ограничения политики. В документации порталов сказано: когда сервер авторизуется через портал, отдельная проверка MFA, обоснование цели доступа и временная аутентификация не применяются, хотя условия вроде принадлежности к группам и состояния устройства продолжают действовать. MFA означает дополнительный фактор аутентификации. Прочитайте об этом ограничении политики, прежде чем использовать портал как процесс согласования действий.

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

С чего начать в понедельник

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

1. 1

   Составьте карту текущих подключений

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

2. 2

   Выберите способ эксплуатации

   Используйте прямые подключения, если существующего контроля достаточно. Начинайте пилот с самостоятельным размещением только при наличии ответственного за среду выполнения. Для пилота Cloudflare откройте Zero Trust > Access controls > MCP Portals, добавьте совместимые HTTP-серверы, назначьте политики Access для серверов и портала и выберите разрешённые инструменты и промпты.

3. 3

   Проверьте обнаружение и вызов инструментов

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

4. 4

   Отзовите доступ и найдите записи о действиях

   Уберите разрешение у учётной записи пилота и убедитесь, что следующая попытка действия завершается отказом. Найдите разрешённые и отклонённые запросы в записях, которые предоставляет ваш продукт. Подтвердите, что место хранения журналов и срок их хранения отвечают требованиям.

5. 5

   Оцените расходы и закрепите ответственность

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

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

Что такое MCP-шлюз?

MCP-шлюз — точка контроля между клиентами ИИ и MCP-серверами. Он может централизовать аутентификацию, списки разрешённых инструментов, журналирование, ограничение частоты запросов и маршрутизацию. Проверяйте каждую функцию в конкретной реализации: нельзя считать, что всё это есть у любого агрегатора.

Чем MCP-шлюз отличается от MCP-сервера?

MCP-сервер предоставляет инструменты, ресурсы и промпты. Шлюз управляет доступом к одному или нескольким серверам и может показывать одобренные возможности через общий интерфейс. Саму работу по-прежнему выполняют и разрешают вышестоящий сервер и приложение.

Нужен ли нашей команде MCP-шлюз?

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

В чём разница между прокси и MCP-шлюзом?

Обычный прокси пересылает трафик. Шлюз с поддержкой MCP может понимать обнаружение и вызов инструментов, объединять возможности и применять политику для отдельных инструментов. Поскольку действия MCP могут использовать одну HTTP-точку подключения, одних разрешений на уровне URL может не хватить для нужных ограничений действий.

MCP похож на API-шлюз?

Сам MCP — протокол. MCP-шлюз играет роль, похожую на роль API-шлюза, но управляет возможностями и вызовами MCP. В той же архитектуре может оставаться API-шлюз для аутентификации HTTP-запросов, сетевого контроля или ограничения частоты.

MCP и HTTP — одно и то же?

Нет. MCP определяет сообщения и возможности, а HTTP — один из способов передавать эти сообщения удалённым серверам. MCP также поддерживает stdio для локальных процессов. Именно это различие транспорта объясняет, почему управляемый HTTP-шлюз не может напрямую работать с любым сервером, доступным только локально.

Зачем использовать MCP вместо REST?

MCP даёт совместимым клиентам ИИ общий способ обнаруживать и вызывать инструменты. Сервер может предоставлять доступ к существующему REST API, так что REST можно сохранить на нижележащем уровне. Выбирайте интерфейс, который нужен вашим реальным клиентам: добавление MCP не требует переписывать API каждого приложения.

MCP основан на JSON?

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

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

MCP — протокол интеграции с инструментами и данными. RAG (генерация с дополнением контекста найденной информацией) извлекает сведения, на которые модель опирается в ответе. Инструмент поиска можно предоставить через MCP, поэтому они могут работать вместе. Само по себе добавление шлюза не улучшает качество поиска.

Больше практических решений по инфраструктуре и проверок цен с указанием даты — в рассылке. Подпишитесь.