ИИтог

MCPGuard нашёл 13 и 19 расхождений со спецификацией в официальных MCP SDK

исследованияРедакция ИИтогarXiv🔥53Рейтинг ИИтог53Влияние40Новизна60Релевантность95Неожиданность30Участники15Достоверность72

Model Context Protocol (MCP) связывает ИИ-агентов на основе больших языковых моделей с внешними инструментами и сервисами. Это происходит через официальные SDK, которые реализуют проверку сообщений и логику сессий. По мнению авторов статьи, ограничения спецификации, пропущенные в этих SDK, могут перейти в downstream-приложения, то есть в программы, построенные на SDK. Поэтому важно проверять соответствие SDK спецификации. Существующие инструменты проверки соответствия MCP в основном обращаются к работающим конечным точкам (endpoints) и мало говорят о том, соблюдают ли модели внутри SDK требования спецификации.

Для этого предложен MCPGuard, автоматизированный фреймворк на основе LLM, который ищет расхождения между спецификацией и SDK. У него два «трека» анализа. Структурный трек сопоставляет ограничения JSON Schema с нормализованными моделями SDK и выдаёт доказательства по каждому ограничению. Поведенческий трек извлекает правила, записанные в тексте спецификации нормативным языком, берёт ограниченные срезы кода на уровне функций и с помощью LLM проверяет их на возможные пропуски.

Кандидатов затем проверяет динамический арбитр, учитывающий собранные доказательства: он изучает полный контекст исходного кода и строит PoC (программы-доказательства), чтобы подтвердить находку. Общее ядро с адаптерами под конкретные языки позволяет анализировать разные SDK одним инструментом.

На официальных SDK, Python версии 1.26.0 и TypeScript версии 1.29.0, MCPGuard подтвердил 13 и 19 находок соответственно. Ни одну из них не выявили два базовых метода «чёрного ящика», с которыми сравнивали фреймворк. Тесты на открытых MCP-серверах, как утверждают авторы, показывают, что такие пропуски могут системно переходить в приложения ниже по цепочке. Авторы подчёркивают, что MCPGuard дополняет, а не заменяет привычные наборы тестов соответствия, ориентированные на конечные точки.

Ключевые факты

  • MCPGuard, автоматизированный фреймворк на основе LLM для поиска расхождений между спецификацией MCP и её SDK.
  • Два трека анализа: структурный (ограничения JSON Schema против моделей SDK) и поведенческий (нормативные правила из текста спецификации, срезы кода на уровне функций, аудит LLM).
  • Динамический арбитр изучает полный контекст исходников и строит PoC, подтверждая кандидатов.
  • В официальных SDK Python 1.26.0 и TypeScript 1.29.0 подтверждено 13 и 19 находок; два базовых метода «чёрного ящика» не выявили ни одной из них.
  • Тесты на открытых MCP-серверах, по утверждению авторов, показывают возможное распространение пропусков на приложения ниже по цепочке.

Почему это важно

MCP стал способом подключать ИИ-агентов к инструментам и сервисам, а приложения обычно опираются на официальные SDK. Если SDK не проверяет часть ограничений спецификации, пропуск может унаследовать каждое приложение на его основе. Существующие тесты соответствия смотрят на работающие конечные точки, а MCPGuard проверяет сам код SDK. Это иной срез проверки.

Кому это важно

Разработчикам и сопровождающим SDK для MCP, авторам MCP-серверов и клиентов, командам, которые строят ИИ-агентов поверх этого протокола, а также исследователям тестирования соответствия и анализа кода с помощью LLM.

Как это применить

Практический вывод из аннотации: проверку соответствия SDK спецификации стоит вести на уровне кода SDK, в дополнение к привычным тестам конечных точек. Авторы прямо говорят, что MCPGuard дополняет такие наборы тестов, а не заменяет их. Готов ли инструмент к использованию и доступен ли его код, из аннотации не видно.

Можно ли доверять

Это препринт на arXiv, по сути аннотация: подробностей методики и самих находок в тексте нет. Результаты 13 и 19 подтверждённых находок и превосходство над двумя базовыми методами заявлены самими авторами. Не названы ни сами базовые методы, ни использованные LLM, ни число проверенных открытых серверов. Показателей ложных срабатываний и стоимости нет. Находки названы именно расхождениями с соответствием, а не уязвимостями безопасности.

Риски и подводные камни

Цифры 13 и 19 относятся только к конкретным версиям SDK (Python 1.26.0 и TypeScript 1.29.0), в новых версиях картина может отличаться. Утверждение о распространении пропусков на приложения ниже по цепочке сформулировано как возможность («могут»), а не как измеренная доля. Метод опирается на LLM, поэтому надёжность зависит от этапа динамической проверки с PoC, но оценок точности в аннотации нет. Какие именно находки и насколько они серьёзны, неизвестно.