Конг спонсировал этот пост.
Когда мы приближаемся к 2025 году, интерес и волнение вокруг протокола контекста моделя Антропика (MCP) выросли без ослабления. Но вокруг него все еще много неопределенности: действительно ли это изменение игры, или это всего лишь последняя часть в цикле шума? В этой серии я попытался помочь вам ответить на эти вопросы.
В первой части я углубился в MCP — что это такое, что это не так и зачем вам нужно сделать его частью вашей инфраструктуры. Во второй части я посмотрел на главную причину, по которой вокруг этого так много гудений: включение агентских рабочих процессов искусственного интеллекта. И в этой третьей и последней части я объясню проблемы с местными серверами MCP, проблемы, с которыми вы, вероятно, столкнетесь в вашем удаленном путешествии MCP и почему знакомый инструмент может помочь вам решить их.
Недостатки местных серверов MCP
Сегодня подавляющее большинство серверов MCP работают локально и используют стандартный транспорт ввода/вывода (Stdio) для локальной связи. Это означает, что каждый сервер MCP должен быть установлен локально вместе с клиентом MCP. В то время как отлично подходит для быстрого тестирования, это значительно препятствует возможности иметь более крупную сеть инструментов по следующим причинам:
- Ограниченная совместимость: Красота MCP заключается в том, чтобы помочь выдерживать разнообразную экосистему устойчивых услуг для крупных языковых моделей (LLMS) и агентов. Местные серверы MCP не могут быть легко распространены между командами, инструментами или агентами — даже при реестре каждый пользователь должен вручную установить и настроить их, что фрагментирует экосистему.
- Нет центральных обновлений: Обновления требуют, чтобы каждый клиент переустановил или повторно синхронизировал вручную, увеличивая накладные расходы на техническое обслуживание и риск дрейфа версии по окружающей среде.
- Труднее обеспечить и проверять: Более трудно применить централизованные политики безопасности, контролировать поведение инструмента использования или аудита, когда каждый экземпляр работает локально и независимо.
- Плохой опыт разработчиков для потребителей: Другие разработчики или агенты не могут просто «вызовать» ваш сервер или обнаружить его инструменты, если они не клонируют всю вашу настройку, которая уклоняется от повторного использования и композиции.
Благодаря недавним обновлениям Anpropic для спецификации MCP, он явно закладывает почву для взрыва роста на удаленных серверах, который поможет решить вышеуказанные проблемы. Это наиболее очевидно при добавлении экспериментальной поддержки транспорта «потоковой HTTP» для замены существующего подхода HTTP+SSE. Это устраняет жесткое требование для постоянных, состоящих в состоянии соединений и по умолчанию на сервере MCP без сохранения.
Кроме того, Anpropic недавно обновил спецификацию MCP, чтобы ввести авторизацию MCP на основе OAuth 2.1. Несмотря на необходимый шаг для удаленных серверов MCP, было много обсуждений по вопросам, представленным этим подходом, а именно, требуя, чтобы сервер MCP выступал как на сервере ресурса и авторизации.
Проблемы масштабирования для удаленного MCP
Серверы MCP, идущие удаленные, неизбежны, но не легкие. В то время как сдвиг в сторону удаленного первого сервера MCP обещает расширяемость и повторное использование, он также вводит новый набор оперативных и архитектурных проблем, которые требуют внимания. Когда мы уходим от тесно связанных локальных рабочих процессов и придерживаемся распределенной композиции, мы должны столкнуться с рядом критических проблем, которые угрожают как опыту разработчика, так и устойчивости системы.
Проблемы с аутентификацией и авторизацией
Спецификация MCP предлагает OAuth 2.1 в качестве основы для безопасного удаленного доступа, но детали его реализации остаются сложными и проблематичными. Ожидается, что серверы MCP будут действовать как серверы авторизации, так и серверы ресурсов. Эта двойная ответственность нарушает обычные модели безопасности и увеличивает риск неправильной конфигурации.
В отличие от традиционных API, которые могут полагаться на устоявшиеся модели управления идентичностью и доступом (IAM), MCP вводит новые проблемы с идентичностью, особенно при цепочке инструментов на вложенных серверах с различными политиками доступа.
Риски безопасности и атаки отравления инструментами
Одна из самых тонких, но критических уязвимостей в модели MCP была недавно изложена Invariant Labs. В том, что он называет «атаками отравления инструментами (TPA), вредоносные актеры могут вводить вредные инструкции непосредственно в метаданные инструментов MCP. Поскольку эти описания интерпретируются LLMS как естественный контекст, отравленный инструмент мог бы тихо подорвать агентские рассуждения и привести его к утечке данных, выполнять непреднамеренные действия или коррумпированные логики решений.
Эти риски усугубляются, когда серверы MCP общедоступны или делятся по организационным границам, и нет четкой границы, чтобы проверить или ограничить, какие инструменты заслуживают доверия.
Хрупкая инфраструктура: высокая доступность, баланс нагрузки и аварийное переключение
Когда местные инструменты ломаются, это личные неудобства; Когда удаленные серверы MCP терпят неудачу, это системный сбой, который может каскад по всему агенту. Высокая доступность становится трудной в этом мире, особенно когда цепочки инструментов зависят от цепочки сервера. Единый вверх по течению сервера, заходящего в автономном режиме, может задержать все выполнение плана.
Тем не менее, сегодня MCP не хватает встроенного механизма для балансировки нагрузки или аварийного переключения. Это критические пробелы, которые необходимы для решения, так как мы в большей степени полагаемся на распределенную композицию.
Разработчик на адаптировании и фрагментации экосистемы
С пролиферацией серверов MCP обнаружение становится неотложной проблемой. Как разработчики находят надежных, поддерживаемых серверов? Как они знают, какие инструменты доступны или как их вызвать? В то время как Антропик намекал на систему реестра на своей дорожной карте, сегодня не существует надежного решения для обнаружения.
Без четких стратегий документирования, адаптации и управления, разработчикам оставляют навигацию по фрагментированной экосистеме, где страдают повторное использование и сотрудничество.
Контекст раздут и смещение LLM
Удаленная композиция звучит элегантно, пока вы не поймете, что каждый сервер, добавленный в сеанс, расширяет окно контекста LLM. Метаданные инструмента, схемы параметров, шаблоны приглашения-все это складывается, особенно в многоагентных, многоагентных средах.
И как только инструменты введены в контекст, нет никакой гарантии, что они будут использоваться с умом. LLM часто смещены в сторону вызывания инструментов, которые появляются в контексте, даже если ненужные. Это может привести к избыточным вызовам, раздутым приглашным цепям и неэффективным рабочим процессам. Эта проблема будет усугублена растущим количеством зарегистрированных удаленных серверов.
Образец шлюза: старый друг для нового интерфейса
Людям, которые живут и дышат API, многие из этих проблем звучат знакомо. Аутентификация причуды? Балансировка нагрузки? Разработчик на борьбе с? Это те виды проблем, которые современный инструмент управления API — особенно шлюзы API — решается в течение более десяти лет.
MCP не заменяет API. Он просто представляет новый слой интерфейса, который делает API более дружелюбными LLM. На самом деле, многие серверы MCP являются просто умными обертками вокруг существующих API. Таким образом, вместо того, чтобы заново изобретать колесо, давайте рассмотрим, как мы можем применить проверенные в битве API Gateway к появившемуся миру удаленных серверов MCP.
Аут? Уже решено
Шлюзы уже хороши в управлении аутентификацией и авторизацией, особенно в корпоративных средах. Вместо того, чтобы полагаться на каждый сервер MCP, чтобы выступать в качестве собственного поставщика OAuth 2.1 (шаблон, который вводит безопасности и операционную сложность), вы можете делегировать Auth в центральный шлюз, который взаимодействует с надлежащими поставщиками идентификационных провайдеров и серверами авторизации.
Это упрощает обработку токенов, поддерживает централизованное правоприменение политики и придерживается реальных моделей IAM, которым организации уже доверяют.
Безопасность, ограждения и трастовые границы
Ворота может служить жизненно важным уровнем безопасности, который фильтрует и принуждает, какие серверы и инструменты MCP даже имеют право на передачу в контекст LLM. Это обеспечивает естественную контрольную точку для организаций для реализации разрешений, сканирования на наличие моделей разработки инструментов и гарантировать, что только проверенные, надежные источники когда-либо включаются в агентские рабочие процессы.
По сути, шлюз становится программируемой трастовой границей, которая стоит между вашим агентом и открытым миром MCP. При правильном использовании это только это может нейтрализовать большой класс атак по производству инструментов.
Устойчивость, балансировка нагрузки и встроенные наблюдения
Когда серверы MCP зарегистрированы за шлюзом, вы получаете автоматические преимущества: балансировка нагрузки, отказоустойчивость, проверки здоровья и телеметрия. Шлюзы создаются для высокой доступности, и они предназначены для маршрутизации запросов на самый здоровый сервер вверх по течению.
Это важно для агентских рабочих процессов, где отказ одной ссылки может нарушить всю цепь. Добавьте в мониторинг и автоматические выключатели, и у вас есть создание надежного, наблюдаемого уровня инфраструктуры, которого в настоящее время не хватает MCP.
Gateway как разработчик Engine
Современные шлюзы API не просто направляют трафик, но и закрепляют целые экосистемы разработчиков. Порталы API, внутренние каталоги, аналитику использования и потоки адаптации хорошо поддерживаются в сегодняшних стеках управления API. Там нет причин, по которой MCP должен быть иначе.
Раскрытие серверов MCP через что-то вроде портала разработчика, управляемого шлюзом, может предложить последовательное обнаружение, документацию и контроль доступа, превратив фрагментированный разрастание сервера на кураторский рынок возможностей.
Борьба с раздуванием контекста и накладные расходы клиентов
Последние две проблемы — контекст LLM раздувается и предвзятость — более жесткие орехи, чтобы взломать. Но именно здесь могут сиять будущее, более интеллектуальные шлюзы.
Представьте себе шлюз не только как прокси, но как адаптивный MCP -сервер: тот, который подключается к UPSTREAM MCP -серверам, осматривает их инструменты и выборочно вводит соответствующий контекст на основе подсказки пользователя. Он может поддерживать постоянные подъездные соединения и динамически обрабатывать регистрацию инструментов, снижая необходимость нереста избыточных процессов клиента и минимизации токенов в контексте LLM.
Инструменты, такие как MCPX, уже начали эту дорогу, но имеет смысл централизовать и масштабировать эту возможность в шлюзе. В конце концов, это уже входная дверь для API вашей организации.
Заключение
По мере того, как агенты ИИ развиваются от новинок до основных компонентов современного программного обеспечения, их потребность в структурированном, надежном доступе к инструментам и данным становится основополагающей. MCP представляет новый мощный интерфейс для разоблачения этой функциональности, который позволяет агентам разум, планировать и действовать в разных услугах. Но по мере того, как серверы MCP движутся к модели с удаленным первым, разработчик и оперативная сложность резко возрастает.
От аутентификации и балансировки нагрузки до управления контекстом и обнаружения сервера, путь к удаленному MCP не без выбоин. Тем не менее, многие из этих проблем знакомы тем, кто провел время в мире инфраструктуры API. Вот почему шлюз API, который долго доверял защиту, масштабированию и выставке услуг HTTP, может быть идеальным решением для расширения MCP на производственную территорию, готовую к предприятию.
В Kong мы считаем, что эта конвергенция уже происходит. С платформой Kong Konnect и Gateway Kong AI организации могут начать применять проверенные шаблоны шлюза к появляющимся интерфейсам ИИ, как MCP. От масштабируемой ауты до загрузки балансировки и разработчика, большая часть того, что необходимо для удаленного MCP, уже здесь.
Хотите узнать больше? Посмотрите, как Kong решает реальные проблемы MCP Server сегодня.
Kong Inc. является ведущим разработчиком Cloud API Technologies и выполняет миссию, позволяющая компаниям по всему миру стать «Pi-Pirst». Конг помогает организациям во всем мире — от стартапов до предприятий из списка Fortune 500 — выпустить производительность разработчиков, надежно строить и ускорить время на рынке. Узнайте больше новейших из Cong Trending Stories youtube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Майкл Филд служит менеджером по маркетингу технического продукта в Kong Inc., подпитываемой любопытством и любовью к решению сложных задач, он управлял карьерой, охватывающей машиностроение в транспортном секторе, физически соединяя людей, к работе с API … Подробнее от Michael Field
