Перегрузка обязанностей MCP
Часто высказывается критика, что на MCP возлагается слишком много ответственности. Автор утверждает, что MCP должен служить главным образом шлюзом для доступа LLM к внешним ресурсам и взаимодействия с ними. Рассмотрение его просто как “двери” или “моста” помогает прояснить его цель и ограничения.
Приписывание таких проблем, как случайное раскрытие данных, уязвимости к инъекциям промптов и недостатки контроля затрат, непосредственно MCP является перекладыванием вины. Эти проблемы должны решать разработчики в пределах контролируемых ими границ. Разработчикам необходимо внедрять ограничения скорости и отслеживать использование, независимо от используемого протокола. Сравнение этого с обвинением дороги в превышении скорости является уместным - инфраструктура не несет ответственности за индивидуальное поведение.
В конечном счете, многие из поднятых проблем являются более широкими вопросами, связанными с делегированием задач AI-агентам. Разработчики должны взять на себя ответственность за управление этими проблемами в рамках своих конкретных приложений, а не ожидать, что сам API будет обрабатывать все.
Оборотная сторона LLM и инъекция промптов
Недавние дискуссии вокруг MCP часто напоминают предупреждения о врожденных опасностях острых ножей - они могут порезать, если с ними обращаться неаккуратно. Инъекция промптов, вызывающая серьезную обеспокоенность, является следствием самой природы LLM. Попытки устранить риск инъекции промптов приводят к ухудшению тех самых возможностей, которые делают LLM ценными.
Понятие разделения “контроля и данных”, распространенное в традиционных системах, не существует естественным образом в LLM. LLM получают свою силу и общность именно потому, что им не хватает этого жесткого разделения. Эта врожденная характеристика делает их уязвимыми для атак с использованием инъекций промптов.
В то время как удаленные MCP как услуга могут представлять риски, вина лежит не на самом протоколе, а на доверии конфиденциальных задач ненадежным третьим лицам. Эта аналогия распространяется на идею приклеивания ножа скотчем к неустойчивой Roomba - проблема не в самом ноже, а в решении прикрепить его к непредсказуемому устройству.
Увещевания “быть осторожным” или предложения защитной экипировки, хотя и технически верны, упускают из виду суть проблемы: необдуманное решение объединить острый инструмент с неконтролируемой системой.
Проблемы масштабируемости
Помимо проблем безопасности, MCP сталкивается с фундаментальными ограничениями масштабируемости. Автор подчеркивает отрицательную корреляцию между надежностью LLM и объемом предоставляемого контекста инструкций. Это ставит под сомнение распространенное мнение о том, что добавление большего количества данных и интеграций автоматически решит проблемы. По мере увеличения числа инструментов и интеграций производительность агента может ухудшаться, одновременно увеличивая стоимость каждого запроса.
Автор подчеркивает, что MCP не масштабируется за определенный порог. Попытка добавить неограниченное количество инструментов в контекст агента неизбежно негативно скажется на его возможностях. Это ограничение присуще концепции MCP и требует большего внимания, чем проблемы аутентификации.
Пользователи могут в конечном итоге столкнуться со снижением производительности по мере включения большего количества серверов MCP, что приведет к помехам между ними. Это резко контрастирует с типичными системами управления пакетами, где невмешательство является фундаментальным свойством.
Основная проблема с MCP заключается в том, что его фактическое поведение отклоняется от ожиданий пользователей. Крайне важно признать, что MCP - это не решение plug-and-play, которое плавно интегрирует неограниченное количество инструментов без последствий.
Решение ограничений с помощью пользовательского интерфейса и управления инструментами
Одним из предлагаемых решений ограничений MCP является улучшение пользовательского интерфейса. Если инструмент выполняется непреднамеренно, пользовательский интерфейс должен предоставлять простой способ отключить его или изменить его описание, чтобы уточнить предполагаемое использование.
Автор также отмечает, что рост контекста часто приводит к улучшению производительности и способностей реального использования, что противоречит представлению о строго отрицательной корреляции. Однако он признает, что в определенных случаях использования или при плохо разработанных контекстах может произойти ухудшение производительности.
Для решения проблемы подавляющего выбора инструментов предлагается подход “разделяй и властвуй”. Это включает в себя добавление инструмента, специально разработанного для выбора наиболее релевантных инструментов для данной задачи. Этот “инструмент выбора инструментов” может быть другим вызовом LLM, которому поручено возвращать подмножество доступных инструментов “родительскому” агенту. Этот многослойный подход добавляет дополнительные уровни косвенности для управления сложностью.
Однако просто наличие инструментов в контексте может значительно изменить вывод модели. В то время как контекстуально релевантные инструменты (достигаемые с помощью таких методов, как Retrieval-Augmented Generation или RAG) полезны, сокрытие всех инструментов за запросом “get_tools” может быть вредным.
MCP как транспортный уровень и уровень авторизации
MCP в основном функционирует как транспортный уровень и формат проводной связи с жизненным циклом запрос/ответ, уделяя особое внимание авторизации на уровне инструментов. В эссе утверждается, что самая большая проблема с MCP заключается в его неспособности позволить AI-агентам функционально компоновать инструменты.
Автор предполагает, что MCP может быть вообще не нужен, поскольку LLM уже обладают возможностью взаимодействовать с API, документированными с использованием спецификаций OpenAPI. Недостающим элементом является авторизация - возможность контролировать, к каким API может получить доступ AI. Вместо MCP автор предлагает разрешить AI выполнять HTTP-запросы, применяя авторизацию к конкретным конечным точкам. Этот подход согласуется с текущей тенденцией обертывания существующих API тонкими инструментами MCP.
Особенно раздражает в MCP отсутствие поддержки потоковой передачи результатов вызовов инструментов. Одна пара запрос/ответ заставляет клиентов многократно вызывать инструменты для разбиения на страницы, что затрудняет длительные процессы. Реализация возможности потоковой передачи, возможно, с использованием gRPC, могла бы значительно повысить эффективность MCP.
Простота раскрытия конфиденциальных данных
Серьезной проблемой с MCP является потенциальная возможность легкого раскрытия конфиденциальных данных. Кроме того, MCP по своей сути не делает AI-агентов более надежными; он просто предоставляет им доступ к большему количеству инструментов, что может парадоксальным образом снизить надежность в определенных ситуациях.
Автор признает, что он не ожидает, что MCP решит или будет нести ответственность за все эти проблемы. Скорее, MCP создает большую поверхность для этих проблем, требуя от разработчиков приложений и пользователей бдительности.
Аналогии и градостроительство
Автор использует аналогию с градостроительством, чтобы проиллюстрировать проблему. Сравнение MCP с шестиполосной городской дорогой с ограничением скорости 25 миль в час подчеркивает несоответствие между дизайном и предполагаемым использованием. Простое наложение штрафов или добавление поверхностных “исправлений” не решает основную проблему плохого дизайна.
Эффективное градостроительство предполагает проектирование дорог, которые естественным образом поощряют соблюдение скоростного режима. Аналогичным образом, MCP следует разработать таким образом, чтобы он по своей сути смягчал потенциальные риски, а не полагался исключительно на внешний контроль.
LLM выполняют нежелательные действия
Статья переходит к более широкой критике протоколов, которые позволяют LLM выполнять действия над сервисами. Автор выделяет основную проблему: LLM могут предпринимать действия, которые пользователи не намерены предпринимать. Он различает действия, которые LLM могут предпринимать независимо, и действия, которые требуют запроса пользователя.
В то время как конечной целью может быть управление LLM целыми предприятиями, технология еще не готова к такой автономии. В настоящее время пользователи могут даже не захотеть, чтобы AI отправляли электронные письма без предварительного просмотра.
Автор отвергает решение запрашивать у пользователя подтверждение, ссылаясь на риск того, что пользователи впадут в привычку автоматического подтверждения (“YOLO-mode”), когда большинство инструментов кажутся безвредными. Это сравнивается с психологическим феноменом, когда люди тратят больше с помощью карт, чем с наличными - проблема, коренящаяся в поведении человека, а не в технологии.
Фундаментальный вопрос: почему бы просто не использовать API?
Повторяющийся вопрос в дискуссиях об MCP: почему бы просто не использовать API напрямую.
MCP позволяет LLM-клиентам, которые пользователи не контролируют напрямую (например, Claude, ChatGPT, Cursor, VSCode), взаимодействовать с API. Без MCP разработчикам пришлось бы создавать пользовательские клиенты с использованием LLM API, что намного дороже, чем использовать существующих клиентов с подпиской и обучать их использовать определенные инструменты.
Один разработчик делится своим опытом создания MCP-сервера для подключения к своему FM-аппаратному синтезатору через USB, что позволяет разрабатывать звук с помощью AI.
Интеграция LLM-клиентов и стандартизация
Основная проблема заключается в том, что не все LLM-клиенты изначально поддерживают прямое взаимодействие с API, при этом пользовательские действия ChatGPT являются заметным исключением. Anthropic, Google и OpenAI договорились принять MCP в качестве общего протокола для упрощения процесса для клиентов на основе LLM, таких как Claude, ChatGPT и Cursor.
MCP упрощает процесс для тех, кто создает LLM-клиенты. Если вы хотите, чтобы LLM взаимодействовал с API, вы не можете просто предоставить ключ API и ожидать, что он будет работать - вам нужно создать агента.
MCP можно рассматривать как способ документирования API и описания того, как их вызывать, а также как стандартизированный инструментарий для предоставления этой документации и облегчения вызовов. Он обеспечивает достаточную абстракцию для обертывания API без ненужных усложнений, но эта простота также может привести к тому, что пользователи “выстрелят себе в ногу”.
Эффективность и повторное использование MCP
Без MCP разработчикам пришлось бы неоднократно объяснять LLM, как использовать инструмент, каждый раз, когда он вызывается. Это несет в себе риск того, что LLM не сможет использовать инструмент правильно из-за забытой информации или нестандартного поведения API.
Это постоянное объяснение и дублирование тратит токены в контексте, увеличивая затраты и время. MCP упрощает этот процесс, объединяя всю необходимую информацию, делая использование инструментов более эффективным и облегчая совместное использование инструментов.
Сообщая LLM-провайдеру “вот инструмент, который вы можете использовать” вместе с документацией API, пользователи могут повторно использовать этот инструмент в нескольких чатах без повторных напоминаний. Это также позволяет настольным LLM-клиентам подключаться к программам, запущенным локально, решая проблему процессов выполнения, специфичных для ОС.
MCP и доступ к локальным ресурсам
MCP облегчает доступ к локальным ресурсам, таким как файлы, переменные среды и доступ к сети для LLM. Он предназначен для локального запуска, предоставляя LLM контролируемый доступ к этим ресурсам.
Стандартная “форма” вызова инструмента LLM точно отражает “форму” вызова инструмента MCP, что делает его простым стандартом для подключения инструментов к агентам.
MCP действует как мост между схемой вызова функций, предоставляемой AI-модели, и базовыми API. Он преобразует вызовы функций в инструменты, обеспечивая бесперебойную связь.
Если вы являетесь поставщиком инструментов, MCP предлагает стандартизированный протокол для подключения внешних интерфейсов AI-агентов к вашему инструменту. Это отвечает на вопрос, почему стандартным протоколом не может быть просто HTTP и OpenAPI.
MCP - это мета-API, который включает конечные точки и детали их работы в спецификацию, позволяя LLM более эффективно взаимодействовать с ними.
MCP в конкретных сценариях
MCP может решать проблемы, когда пользователи задают вопросы или не уверены, какие API использовать. Он также может обрабатывать запросы на основе предыдущих сообщений.
Один пользователь делится своим опытом, когда он хотел получить “X” пользователя и отправить его в конечную точку. Он обнаружил, что MCP является излишним для такой простой задачи, указывая на то, что он не всегда необходим для базовых взаимодействий с API.
MCP сравнивают с веб-приложением FastAPI для создания программного обеспечения, которое может общаться по сети, специально разработанного для агентских взаимодействий. Его можно рассматривать как “Rails-for-Skynet”, предоставляющий стандартизированную основу для разработки AI-агентов.
Проблемы с контролем провайдера
Есть опасения, что MCP продвигается для усиления контроля провайдера над системой. LLM-провайдеры могут в конечном итоге ограничить доступ к API, аналогично тому, как Google затруднил использование IMAP/SMTP с Gmail.
Использование OpenAPI позволяет агентам получать спецификации API из /openapi.json.
MCP обеспечивает быстрое взаимодействие, позволяя пользователям выполнять задачи за секунды, а не тратить время на подготовку входных данных, отправку их в API, синтаксический анализ выходных данных и повторение процесса для каждого сообщения.
Песочница и риски безопасности
Одной из самых больших проблем является то, как выходные данные инструмента MCP-сервера могут повлиять на другие инструменты в том же потоке сообщений. Это требует песочницы между инструментами для предотвращения непреднамеренных последствий. Invariant labs решила эту проблему с помощью описаний инструментов, в то время как другие использовали вложения ресурсов MCP. Отсутствие песочницы усугубляет риски инъекции промптов.
Это сравнивается с SQL-инъекцией - системой, собранной воедино, где уязвимости могут быть использованы в любой момент с минимальной наблюдаемостью.
Интерфейс промптов также восприимчив к форме SQL-инъекции, поскольку модель не может отличить надежные части промпта от испорченных пользователем входных данных. Решение этой проблемы требует фундаментальных изменений в кодировании, декодировании и обучении модели.
Это позволяет как инъекцию промптов, так и инъекцию инструментов, потенциально приводя к выполнению ненадежного кода.
Контейнеризация и контролируемый доступ
Один разработчик создал MCP-сервер, который запускает контейнер Docker с подключенным кодом проекта. Этот подход позволяет LLM получить доступ ко всему набору инструментов Unix и инструментам, специфичным для проекта, в изолированной среде.
Этот агентский рабочий процесс, управляемый через интерфейс на основе чата, оказался более эффективным, чем традиционные методы.
Ключ в том, чтобы предоставить агентам MCP доступ к тому, что им нужно, и не более того. Контейнеризация и прозрачный пользовательский интерфейс инструментов имеют решающее значение для снижения рисков безопасности.
Виртуальные машины и доступ к Интернету
Предоставление агентам компьютера с минимальной установкой Linux (в качестве виртуальной машины или контейнера) может дать лучшие результаты, позволяя им получать информацию из Интернета. Однако это вызывает опасения по поводу безопасности, касающиеся вредоносных инструкций и утечки данных.
Ограничение доступа к надежным веб-сайтам может снизить некоторые риски, но даже надежные источники могут размещать вредоносный контент. Компромисс между вероятностью столкновения с вредоносными инструкциями и преимуществами повышения производительности должен быть тщательно взвешен.
Различия между сотрудниками и AI-агентами значительны. Сотрудники являются юридическими лицами, на которых распространяются законы и контракты, обеспечивающие подотчетность. AI-агентам не хватает этой правовой основы, что затрудняет доверие.
Ранние стадии разработки MCP
MCP был объявлен только в ноябре 2024 года, и RFC активно развивается.
Некоторые рассматривают всю концепцию AI-личного помощника, включая MCP, как принципиально ошибочную.
Первоначальный толчок для AI-помощников в конце 1990-х и начале 2000-х годов провалился, потому что агрегаторы контента с вертикальной интеграцией и возможностью массовых закупок оказались более эффективными. Это привело к подъему таких платформ, как Expedia и eBay.
Многоагентные системы требуют, чтобы программисты влияли на состояние агентов, что является сложной задачей программирования.
Пределы бесплатной ценности
Желание “ранжировать результаты по наличию парковки” подчеркивает проблему доступа к данным, находящимся за платными API или рекламными интерфейсами. Компании вряд ли будут свободно предоставлять доступ ко всему своему набору данных через API.
Хотя не все компании будут интегрировать свои данные в AI-агентов, потенциал объединения различных инструментов для питания рабочих процессов остается значительным.
Компании, которые уделяют приоритетное внимание поддержанию защитного барьера данных, скорее всего, будут сопротивляться новым технологиям, которые угрожают этому барьеру.
Если бы у booking.com был API, они, вероятно, вернули бы те же результаты, что и их веб-сайт, возможно, с форматированием JSON или XML.
Обход посредника
Не имеет особого смысла, чтобы такой посредник, как booking.com, позволял пользователям полностью обходить их услуги.
Однако отдельные отели могут счесть выгодным обход booking.com, посредника, который им часто не нравится.
Deep Research AI может сканировать отели на основе определенных критериев и взаимодействовать с MCP-серверами Hotel Discovery, управляемыми отдельными отелями, обходя необходимость навигации по интерфейсу и рекламе booking.com.
Практические варианты использования
MCP может облегчить выполнение таких задач, как извлечение журналов из Elasticsearch или запрос баз данных более структурированным способом.
Статическая природа конфигурации MCP-сервера, где новые серверы требуют редактирования файла .json и перезапуска приложения, может быть ограничивающей.
Точно настроенные модели
MCP можно рассматривать как небольшую, точно настроенную модель, которая понимает многочисленные инструменты MCP и выбирает правильные для каждой беседы.
Динамическая настройка инструментов на основе контекста может быть необходима для определенных сценариев.
Открытые беседы и бизнес-проблемы
MCP хорошо подходит для общих систем открытых разговоров без предопределенного потока. Однако это не универсальное решение для каждой бизнес-проблемы. Он не предназначен для замены таких фреймворков, как LangChain.
Альтернативой MCP, открытому стандарту, управляемому сообществом, являются разрозненные, проприетарные и привязанные к поставщикам протоколы. Ошибочный, но развивающийся стандарт предпочтительнее отсутствия стандарта вообще.
Лучший способ взглянуть на MCP - это переход от отдельных разработчиков, создающих обертки клиентов вокруг API, к поставщикам API или поддерживаемым сообществом оберткам, создающим их. Это предоставляет большой набор инструментов, аналогичный NPM или PyPi. Однако по-прежнему требуются оркестровка, безопасность и определение использования.
Следующее поколение Langchains выиграет от этого большего набора инструментов, но все еще необходимы инновации.
Инструменты, специфичные для пользователя
В некоторых случаях инструменты могут быть специфичными для данных пользователя, например, инструменты для нарезки и манипулирования загруженными CSV-файлами.
Одна из часто упускаемых из виду проблем заключается в том, что MCP может перегрузить контекст модели слишком большим количеством опций. Приоритизация и предоставление метаданных имеют решающее значение для избежания расточительного использования токенов и неустойчивого поведения модели.
Стандарты и развивающиеся технологии
Новые стандарты появляются со временем, и прошло так много времени с тех пор, как стандарты действительно имели значение, что люди забыли, как они развиваются.
Загрузка крошечных серверных программ от случайных разработчиков для добавления “инструментов” в LLM-клиенты может быть рискованной.
Поднятые вопросы являются законными проблемами, которые экосистеме MCP необходимо решить. Некоторые решения будут в рамках спецификации MCP, в то время как другие будут внешними.
Код Claude и реальное использование
Существуют противоречивые мнения об успехе MCP. Некоторые слышали истории о компаниях, интегрирующихся с MCP, в то время как другие слышали от пользователей, которые сочли его разочаровывающим.
Это подчеркивает недостаток шумихи и раннего внедрения.
Некоторые разработчики считают, что HTTP API превосходят MCP для большинства вариантов использования. Они утверждают, что использование “инструментов” сводится к конечным точкам API для возможностей и функциональности.
API не являются самоописываемыми по умолчанию, что представляет собой упущенную возможность для сторонников REST и HATEOAS продемонстрировать свои подходы.
MCP как альтернатива LangChain?
MCP был описан как имеющий “запах LangChain” - не решая насущную проблему, будучи чрезмерно абстрактным и с трудом объясняя свои преимущества.
Возможно, ему нужно сказать “КОНЕЦ СТРОКИ” и изгнать подражателей хакеров в игровую сетку!
Ключевой вопрос заключается в том, сохранится ли “общая” парадигма Chatbot. Специализированным приложениям со своими собственными инструментами может не понадобиться MCP.
И наоборот, по мере того, как LLM становятся более способными, внешние инструменты могут стать менее необходимыми. Зачем вам MCP для управления Photoshop, когда LLM может просто редактировать изображение напрямую?
Мечта о научно-фантастическом роботе-помощнике может не осуществиться, и инструменты манипулирования специализированными языками могут быть более полезными.
База пользователей и осведомленность о безопасности
База пользователей MCP включает в себя менее технических лиц, что делает вопросы безопасности особенно актуальными. Повышение осведомленности о передовых методах обеспечения безопасности имеет решающее значение.
Основание Xops на OpenRPC, который требует определения схемы результатов, помогает планировать, как выходные данные подключаются к входам, повышая надежность сложных рабочих процессов.
Вполне вероятно, что технология со временем будет развиваться и стабилизироваться.
Избыточность и облачная инфраструктура
Некоторые ставят под сомнение выгоды от использования MCP по сравнению со стандартом OpenAPI, рассматривая его как избыточный.
Что будет использовать LLM для вызова системы OpenAPI? Как он свяжется с оболочкой? Как хост LLM будет это организовывать?
MCP предоставляет структурированный способ для LLM делать вызовы инструментов.
MCP-серверы уже являются HTTP-серверами.
Самое большое преимущество MCP - для LLM-провайдеров, таких как OpenAI, а не для разработчиков приложений.
LLM - это мозги без инструментов, а вызов инструментов расширяет их возможности. Однако при использовании обычных API LLM-провайдеры не имеют доступа к этим инструментам. MCP предоставляет им доступ, позиционируя их как шлюз в AI.
CLI vs. API
Почему бы не использовать CLI напрямую, учитывая, что LLM обучаются на естественном языке, а CLI - это распространенное решение для чтения и записи человеком?
MCP появился слишком быстро и ему нужно время для созревания. Ему не хватает проверки обычной организацией по стандартизации и он движим шумихой.
Отсутствует реальное применение.
Основные приложения MCP
MCP используется в Claude Desktop и нишевых AI-чат-приложениях, инструментах автоматизации кода и фреймворках автоматизации агентов/LLM.
Это еще одна поспешная технология, которая, вероятно, будет отброшена, когда появится следующий привлекающий внимание акроним.
Существуют два типа протоколов вызова инструментов языковой модели: те, на которые люди жалуются, и те, которые никто не использует.
Anthropic разработал этот “стандарт” в вакууме, что привело к проблемам с безопасностью.
JSON-RPC 2.0
MCP построен на JSON-RPC 2.0, облегченном протоколе, который позволяет клиенту и серверу общаться с использованием JSON.
Он кажется централизованной спецификацией, разработанной для конкретной экосистемы, претендующей на универсальность, не заслужив ее.
MCP достаточно мощный, чтобы делать полезные вещи, что вызывает опасения по поводу безопасности.
Это не зрелый стандарт и не был разработан как безопасный.
Хотя рекомендации существуют, они не применяются и не реализуются.
Langchain и вызов инструментов
Langchain - один из многих фреймворков, которые реализуют шаблон “вызова инструментов”.
MCP - это спецификация того, как внешняя информация входит в контекстное окно языковой модели, включая вызов инструментов, ввод шаблонов, отмену, отслеживание хода выполнения и состояние серверов инструментов.
Он помогает стандартизировать детали, чтобы любое сочетание помощника/интеграции было совместимым.
Хотя у MCP есть законные проблемы, критики должны уточнить свои аргументы.
Аутентификация имеет решающее значение и не должна была быть опущена из первоначальной версии.
Слишком много сложностей.