Протокол контекста модели (MCP) находится на пути к тому, чтобы стать золотым стандартом для интеграции внешних ресурсов в агентские рабочие процессы. В то время как разработчики могут использовать механизмы, специфичные для внедрения инструментов, специфичные для внедрения языка (LLM), MCP быстро становится эквивалентом интеграции.
Эта серия знакомит разработчиков Python с основами MCP и его архитектуры. Я начну с мотивации MCP и архитектуры высокого уровня, за которой следует подробная, практическая реализация серверов и клиентов.
Что такое протокол контекста модели?
Объявленный в ноябре 2024 года, MCP Antropic является открытым стандартом, предназначенным для оптимизации того, как модели ИИ взаимодействуют с внешними инструментами, источниками данных и ресурсами.
Anpropic представляет MCP как универсальный разъем инструментов для LLMS. Это сравнивает его с тем, как USB-C стандартизирует аппаратные соединения, позволяя разработчикам интегрировать любой инструмент или источник данных с их приложениями ИИ с помощью одного протокола. Принимая языковой подход и предоставляя SDK для Python, TypeScript, Java, Kotlin и C#, MCP устраняет необходимость в нестандартных, одноразовых интеграциях.
MCP работает через два основных компонента: серверы, которые разоблачают инструменты, ресурсы и подсказки, а также клиенты, которые соединяют модели искусственного интеллекта с этими серверами. Общение обрабатывается через JSON-RPC по HTTP, поддерживая синхронные и асинхронные рабочие процессы. Безопасность является неотъемлемой частью, с явными разрешениями и местным проектом, обеспечивающим конфиденциальность. MCP уже поддерживается крупными платформами искусственного интеллекта и способствует быстрому росту экосистемы, что делает его основополагающей технологией для создания надежных контекстных агентов ИИ.
Langchain, Agent Agent SDK, Google Agent Developer Kit и Microsoft Copilot Studio являются одними из платформ и платформ, которые изначально поддерживают MCP.
Более внимательный взгляд на серверы MCP и клиентов MCP
Агентные рабочие процессы требуют двух важных элементов для автономного управления: современные данные и доступ к существующим системам. Данные подаются в качестве контекста LLMS для предоставления фактической информации, которая помогает LLMS принимать решения. Как только решение принимается для принятия мер, они нуждаются в программном доступе к системам, которые обычно выявляются как API, которые становятся доступными в качестве инструментов.
Интересно, что серверы и клиенты MCP могут работать без каких -либо зависимостей от LLM. Когда клиент интегрирован с LLM, он формирует основу агентских рабочих процессов.
В архитектуре MCP серверы абстрагируют доступ к данным и инструментам. Например, база данных может быть частью сервера MCP в качестве ресурса. Клиент имеет доступ только для чтения к этому ресурсу для получения данных. Ресурсы также поддерживают параметры для применения фильтров или ограничения данных, общих с клиентами. Например, информация о заработной плате сотрудников является идеальным кандидатом на ресурс.
Кроме того, серверы MCP также выставляют инструменты, которые позволяют клиентам выполнять действия, выходящие за рамки извлечения данных. В то время как ресурсы обеспечивают доступ только для чтения, инструменты поддерживают вызов API, который манипулирует данными или предпринимает действие. Например, вызывание API Stripe API для завершения транзакции оплаты является отличным кандидатом на инструмент.
Помимо ресурсов и инструментов, серверы MCP также могут выступать в качестве центра для предопределенных подсказок. Клиенты могут получить эти подсказки и отправить их в LLMS. Это обеспечивает последовательный и стандартный репозиторий подсказок.
Серверы MCP могут быть запрошены, чтобы получить список ресурсов, инструментов и подсказок, которые они выставляют. Это действует как основной механизм открытия. Подводя итог, что серверы MCP могут подвергать ресурсы, инструменты и подсказки клиентам. То, что делает клиент, остается воображению разработчика.
Клиент MCP живет в хост -приложении, чат -боте или агенте. Типичными примерами хост -приложения являются настольный компьютер Claude и Cursor AI. Разработчики могут создать агентское приложение, а несколько клиентов взаимодействуют с одним или несколькими серверами MCP.
Мы можем создать клиента MCP, который не разговаривает с LLM. Тем не менее, клиент может стать мощным каналом для LLM для доступа к серверам MCP.
В типичном рабочем процессе хост -приложение, такое как чат -бот или агент, соединяется с сервером MCP, получает доступные ресурсы и инструменты и передает их в LLM в ожидаемом формате.
Основываясь на подсказке, LLM может вернуться к хосту, чтобы получить доступ к ресурсу или вызвать инструмент через клиента MCP. Большинство агентских рамок, такие как Agenai Agents SDK и Google ADK, абстрагируют эту функциональность, выполняя прозрачную поездку между LLM и хост -приложением.
Связь между сервером MCP и клиентом MCP
Наиболее важным аспектом архитектуры MCP является протокол связи. MCP -сервер поддерживает два транспортных протокола: Stdio и SSE.
Первый выбор прост и очевиден для многих разработчиков. Представьте себе, что вы вызовите инструмент командной строки, передавая несколько параметров и копируя и вставьте вывод в окне чат-бот как часть подсказки.
При использовании STDIO в качестве транспортного протокола клиент MCP напрямую вызывает сервер MCP и передает необходимые параметры. Затем он отражает вывод с сервера, который записывается на консоли, и передает его приложению хоста.
В этом сценарии клиент и сервер имеют тот же процесс. Сервер просто выполнит команду и немедленно выйдет. Это повторяется каждый раз, когда клиент вызывает сервер. По сути, клиент и сервер запускаются в процессе без участия в удаленном вызове или RPC. Это работает лучше всего, когда клиент и сервер находятся на одной и той же машине, и задержка не связана из-за продолжительных процессов. Суть в том, что MCP -сервер и клиент совместно используют соединение 1: 1 при использовании транспорта Stdio.
Второй транспортный протокол, который поддерживает MCP, является серверным событиями (SSE). Это позволяет серверу нажимать обновления в режиме реального времени для клиентов в течение одного долгоживущего HTTP-соединения. После того, как клиент инициирует соединение, серверы потокит данные в качестве событий, что устраняет необходимость повторного опроса. Этот подход особенно эффективен для таких приложений, как живые новости или уведомления, где обновления текут в основном от сервера к клиенту.
По сравнению с отдыхом, SSE обеспечивает более низкую задержку и большую эффективность, поскольку REST требует, чтобы клиенты многократно опросили сервер для новых данных, увеличивая накладные расходы и задержку. SSE также предлагает автоматическое воссоединение и беспрепятственно работает с большинством брандмауэров, что делает его более надежным для сценариев в реальном времени.
MCP использует SSE вместо Webockets для удаленной связи в первую очередь потому, что SSE предлагает более простое и надежное решение для сценариев, в которых требуется только потоковая передача сервера к клиенту. SSE работает над стандартным HTTP, облегчая работу с брандмауэрами и ограниченными сетями. Это также позволяет серверу распространять обновления в реальном времени для клиента без сложности управления полнодууплексным соединением WebSocket.
В MCP связь с клиентом к серверу обрабатывается с помощью запросов HTTP POST, в то время как SSE обрабатывает потоковые обновления от сервера к клиенту, что соответствует типичному шаблону взаимодействия для инструментов ИИ и уведомлений о ресурсах. Этот подход уменьшает накладные расходы, упрощает реализацию и улучшает совместимость с существующей инфраструктурой, особенно по сравнению с двунаправленным и часто более сложным протоколом WebSocket.
В то время как SSE является техникой связи, JSON-RPC является протоколом провода, используемым MCP. JSON-RPC-это легкий протокол без сохранения состояния, предназначенный для удаленных процедурных вызовов, что делает его идеальным для быстрых динамических обменов, требуемых в рабочих процессах искусственного интеллекта.
В MCP каждое взаимодействие, такое как вызов инструмента, получение данных или листинг доступных возможностей, кодируется как сообщение JSON-RPC, которое включает имя метода, параметры и идентификатор для отслеживания ответов. Этот подход позволяет клиентам MCP и серверам беспрепятственно общаться, независимо от их лежащего в основе языка реализации, и гарантирует, что все запросы, ответы и уведомления следуют предсказуемому, совместимому формату. Опираясь на JSON-RPC, MCP упрощает интеграцию, поддерживает обработку ошибок и позволяет разработчикам создавать гибкие, композиционные агентные рабочие процессы, которые могут взаимодействовать с различными внешними инструментами и ресурсами.
В отличие от протокола транспорта Stdio, SSE может поддержать несколько клиентов одновременно обслуживаемым одним MCP -сервером. Это полезно, когда серверы MCP размещены удаленно в таких средах, как платформа в качестве сервиса (PAAS) и без сервера.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Janakiram MSV является основным аналитиком в Janakiram & Associates и адъюнкт -преподавателем Международного института информационных технологий. Он также является квалифицированным Google Cloud Developer, сертифицированным архитектором решений Amazon, сертифицированным разработчиком Amazon, … Подробнее от Janakiram MSV
