Конг спонсировал этот пост.
Шумиха для протокола контекста модели Антропика (MCP) достигла точки кипения. Все выпускают что-то вокруг MCP, чтобы они не рассматривали их как отстающие в постоянно меняющемся ландшафте ИИ.
Тем не менее, в этом безумном духе остается путаница вокруг MCP, и что на самом деле позволяет стандарт. Некоторые видят MCP как общий план игры, а некоторые видят в нем чуть больше, чем тонкая и ненужная обертка.
Как обычно, правда находится где -то посередине. Давайте погрузимся в детали.
Что такое MCP?
MCP был выпущен Anpropic в ноябре 2024 года для минимальной фанфары. Протокол был объявлен как универсальный, открытый стандарт, в котором подробно описывается, как помощники ИИ могут получить контекст — внешние данные, инструменты и услуги — для выполнения задач. После того, как некоторые крупные игроки в пространстве ИИ приняли стандарт, интерес к нему взорвался в начале этого года.
Так зачем моделям нужен дополнительный контекст? Ну, например, скажем, пользователь представляет большую языковую модель (LLM) с:
«Можете ли вы составить последующее электронное письмо в Acme Corp, в котором ссылается наш последний звонок и связи в ценовой слайде из моей колоды предложения?»
Ни один LLM в мире не может успешно выполнить эту задачу без дополнительного контекста: доступ к стенограмме вызова и слайд -колоде предложения, знание ACME Corp и т. Д.
MCP — это просто стандартизированный способ (то есть протокол) для LLMS для доступа к контексту, необходимому им для выполнения задач. Есть много отличных ресурсов, которые попадают в сорняки протокола и основные транспорты, но сейчас давайте просто определим основные объекты в игре:
- LLM: Большая языковая модель, которая интерпретирует пользовательский ввод и любой дополнительный контекст.
- Ведущий MCP: Среда выполнения (например, чат -бот), которая соединяет LLM с одним или несколькими клиентами MCP.
- MCP клиент: Компонент, работающий внутри хоста MCP, который поддерживает соединения 1: 1 с серверами MCP и передает контекст в LLM.
- MCP -сервер: Служба, разоблачающая контекст в стандартизированном формате для клиентов MCP.
- Типы контекста: Четыре структурированные примитивы — инструменты, ресурсы, подсказки и отбор проб — что сервер MCP может предоставить LLM.
Хост или клиент: в чем разница?
Первоначально многие люди считают, что разница между хостом MCP и клиентом MCP путает, поскольку различие является тонким. Клиент MCP работает в контексте хоста (например, Claude Desktop), используя возможности хоста и пользовательский интерфейс для инициирования запросов и потребления услуг, предлагаемых серверами MCP.
Клиенты имеют соединение 1: 1 с серверами; Поэтому новый клиент -процесс должен быть развернут на хосте для каждого нового сервера MCP. Тем не менее, эти выделенные «внутренние клиенты» не являются отдельными пользовательскими сессиями; Они являются частью одного экземпляра оркестратора. Ради простоты, мы объединим концепцию MCP Host и Client Client и просто обратимся к клиенту MCP в этой статье.
Эти сущности работают вместе, чтобы создать последовательный подход в предоставлении дополнительного контекста для моделей. Этот контекст может быть чем угодно, от вызова функций (например, инструментов) до текстовых файлов (таких как ресурсы) до параметризованных подсказок, которые направляют LLM в структурированный рабочий процесс.
Чтобы проиллюстрировать, давайте пройдемся по простому примеру MCP в действии. Допустим, пользователь просит чат -бота, что требует дополнительного контекста за пределами учебных данных модели, например: «Какая погода в Сан -Франциско сегодня?»
Клиент MCP сначала гарантирует, что он имеет современные определения инструментов с подключенных серверов MCP. Он вводит инструмент get_weather в контекст разговора, прежде чем отправлять все в LLM. LLM признает необходимость в дополнительном контексте, чтобы ответить на запрос и вызывает get_weather (City = «San Francisco») с соответствующими параметрами.
Клиент MCP направляет этот вызов инструмента на правильный сервер, который выполняет логику — вызов API погоды — и возвращает результат. Эти данные передаются обратно в LLM, который используется для создания окончательного ответа для пользователя.
Источник: Конг
Примечательно, что фактическая логика, выполненная здесь, является просто стандартным вызовом API, который иллюстрирует важный момент. MCP не заменяет API; Это просто дополнительный интерфейс, чтобы сделать API более дружелюбными LLM.
Инструментальный звонок … переупакован?
Одна из первых вещей, которые люди замечают о MCP, — это то, что он не делает ничего совершенно нового. Это приводит к некоторым общим возражениям:
- Это просто инструмент вызов переупаковки.
- Это тонкая обертка на API.
- Почему бы просто не использовать отдых или GRPC?
Самое главное, люди спрашивают: «Ну и что?» Они видят ажиотаж без вещества.
В его простейшей форме, да, вы можете просто рассматривать MCP как инструмент, вызывая переупаковку. (Мы доберемся до того, что делает его больше в следующем разделе.) Но давайте вернемся к заявлению миссии Антропика для этого протокола: все дело в определении открытого, универсального стандарта. Основное внимание здесь уделяется вовлечению инноваций посредством совместимости в этом быстро развивающемся пространстве.
Тем не менее, многие спрашивают, зачем нам нужен слой поверх существующих API с четко определенными стандартами? Рассмотрим API REST, определяемый спецификацией OpenAPI, который является как машиной, так и человеком. Спецификация определяет такие вещи, как то, какие конечные точки существуют, какие параметры требуются, как может выглядеть ответ и т. Д. Другими словами, он говорит вам, как назвать API.
Что вам не говорит, так это то, почему или когда это назвать, или как интерпретировать ответ — все вещи, которые LLM, особенно автономные агенты, должны эффективно рассуждать. Например, конечная точка Post /Todos может позволить вам создать задачу с параметром task_description, но в ней не хватает каких -либо руководств о том, как она отображает такую цель, как «Планируйте мой день».
Эта комбинация размышлений и намерения общения, описывающая «что» вместо «Как», позволяет более устойчивому системам.
Напротив, MCP завершает ту же функцию add_task (task_description) с помощью естественного языкового подсказки, которая описывает ее намерение,-например, «Учитывая такую цель, как {user_goal}, разбивайте его на задачи и вызовите add_task, чтобы добавить их в список дел». Этот дополнительный контекст помогает LLMS рассуждать о том, когда и зачем вызывать инструменты, позволяя управлять целями, а не жесткую логику.
Кроме того, API REST не поддерживают концепцию, называемую «отражение» — возможность клиента спросить сервер: «Какие функции вы предлагаете, и как мне их позвонить?» Это важно для динамических модельных взаимодействий. Это требование сразу же заставляет людей обращаться к GRPC, что поддерживает отражение и определяет выводящиеся функции со структурированными входами и выходами (т.е. инструментами) через буферы протокола.
Но GRPC не был создан с учетом языковых моделей. GRPC приоритет производительности и использует компактный двоичный формат между машинами. Его схемы — это более высокие и отсутствуют описания естественного языка. Хотя это и эффективно, это затрудняет понимание интерфейсов GRPC для LLMS без дополнительного инструмента или перевода. MCP, с другой стороны, использует простой JSON со встроенным описанием и руководством по использованию для каждого инструмента, что значительно облегчает интерпретацию и использование LLMS. MCP фактически служит мостом между традиционными системами RPC и использованием инструментов, управляемых AI.
Эта комбинация размышлений и намерения общения, описывающая «что» вместо «Как», позволяет более устойчивому системам. Генеральный директор Dylibso Стив Мануэль удачно описывает MCP как «дифференциал для современных API и систем». Эта устойчивость достигается путем позволяет клиентам динамически обнаруживать возможности сервера во время выполнения вместо времени настройки, а семантические параметры, которые используют читаемые на человеку и концептуально сфокусированные определения, создают интеграции на основе MCP, способные беспрепятственно обрабатывать изменения в базовом API.
Подходит дальше
Хорошо, так что, надеюсь, теперь вы, по крайней мере, начнете рассматривать MCP как необходимый и ценный стандарт, но, возможно, вы все еще запутались, почему вокруг него так много шума. Во второй части я посмотрю на что -то еще, что предлагает MCP — позволяя агентским рабочим процессам — и в части 3 я пойду в важную смену, которая происходит в экосистеме 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
