AI технологии меняются так быстро, что каждые несколько месяцев задаешься вопросом: чем сейчас лучше всего заняться в этой индустрии? И ответ каждый раз новый.
Я недавно понял, что сейчас самое время заняться MCP — протоколом контекста моделей, и открыть возможности внешних интеграций для моих AI агентов. По мере того, как растет количество публично доступных MCP серверов, разница между агентом с MCP-адаптером и без такового приближается к разнице между компьютером с интернетом и без.
Инициатива OpenAI, которые адаптировали MCP для своей платформы приложений внутри ChatGPT, произвела на меня определенное впечатление, и я проделал довольно основательный эксперимент (на трех облачных H200 и DeepSeek V3.2-Exp), показавший, что основной функционал такой платформы можно воспроизвести усилиями одного разработчика.
Сам эксперимент – в этом видео:
Вместо ChatGPT я использовал Open WebUI, который поддерживает MCP из коробки. Логичный выбор — это самый полноценный открытый аналог веб-интерфейса ChatGPT.
Однако, ограничения Open WebUI по части MCP меня сильно разочаровали. Моей целью было сделать как у OpenAI: при желании пользователь может передать URL своего MCP-сервера на инференс-API, и этого должно быть достаточно, чтобы вызывать его tools.
tools=[
{
"type": "mcp",
"server_label": "deepwiki",
"server_url": "https://mcp.deepwiki.com/mcp",
"require_approval": {
"never": {
"tool_names": ["ask_question", "read_wiki_structure"]
}
}
},
]Но Open WebUI не поддерживает напрямую транспортные протоколы, через которые MCP-клиент и сервер обмениваются сообщениями – streamable HTTP и SSE. Вместо этого у Open WebUI есть собственный прокси (mcpo), с помощью которого можно конвертировать MCP сервер, доступный локально через stdio, в RESTful HTTP. Прямо скажем, неудобно.
У большинства разработчиков задача сводится к деплою готового MCP сервера, реализующего какую-либо внешнюю интеграцию – например, с Jira или PostgreSQL — и его связке с AI-агентом.
Поэтому я подумал: а почему бы не сделать платформу, позволяющую автоматизировать оба шага, или во всяком случае дать разработчику инструменты, позволяющие все сделать максимально просто?
Хорошо бы, чтобы платформа поддерживала понятный удобный пользовательский интерфейс – Open WebUI, но без выявленных выше ограничений. На самом деле одного Open WebUI мало; с учетом запросов рынка, как подсказывает мой опыт, нельзя забывать о популярности телеграм-ботов применительно к AI, а также о необходимости программного доступа по API. Но все же Open WebUI — хорошая стартовая точка.
Решение, которое позволяет обойти ограничения поддержики MCP протокола — это пайплайны Open WebUI. Например, вы можете поднять свой AI агент как отдельный микросервис. Пайплайн — это модуль, который свяжет агента через Open WebUI и позволит вам написать тонкую программную прослойку, чтобы конвертировать ответы агента в формат Open WebUI, добавить какие-то кастомные фичи. В моем случае это передача URL внешнего MCP-сервера.
Здесь тоже все не так просто. Предположим, что код агента написан, например, на LangChain. Мне очень не нравится официальный MCP адаптер для LangChain, мне нужно что-то более простое, желательно синхронное, совместимое с любой python-библиотекой. Клиентской библиотеки, обладающей перечисленными свойствами, в открытом доступе не хватает, и я решил написать свою.
Сам по себе MCP протокол очень прост. Клиент инициализирует сессию, согласно конвенции, определенным JSON-RPC сообщением, может вызывать список tools, prompts, resources сервера, и вызывать тулзы. По замыслу разработчиков протокола, передача JSON-RPC сообщений должна быть возможна поверх нескольких транспортных протоколов – как минимум, HTTP-стрима и stdio. Оба транспорта достаточно легко реализуются стандартными средствами Python.
Сложности начинаются, когда дело доходит до продвинутых функций MCP, таких как elicitation и sampling. Если большинство пользователей (пока) ими не пользуются, это не значит, что эти функции бесполезны.
Напротив, я убедился на опыте, что как минимум elicitation — возможность запросить детали у юзера при выполнении определенного шага рабочего процесса агента – в ряде случаев необходима.
Правда, когда мне пришлось реализовать такой механизм в реальном агенте, выбранный мной способ был далек от того elicitation, который мы видим в официальном MCP SDK от Anthropic, и не без причин. Мало того, что elicitation требует двустороннего обмена сообщениями между агентом и пользователем, так еще и агент сам должен иметь возможность задавать вопрос, выступая в некоторых случаях инициатором диалога, а не тем, кто только отвечает на сообщения пользователя. Эти ситуации пока что не проработаны в большинстве диалоговых AI-систем.
Впрочем, свой MCP-клиент я решил не перегружать нестандартным функционалом. По замыслу он должен остаться относительно простым и включать следующие компоненты:
-
MCP-сессию, реализующую отправку JSON-RPC сообщений на сервер;
-
Транспортный слой, который включает поддержку HTTP-стрима и stdio;
-
Адаптер, в настоящий момент – для LangChain/LangGraph, но с возможностью добавлять другие агентские бэкенды.
В ближайшем будущем я планирую выложить его в открытый доступ, как и часть других модулей моей платформы. Мне кажется, современная AI-платформа должна быть открытой и обеспечивать максимальную кросс-совместимость с различными AI-инструментами. Именно поэтому я изначально выбрал MCP протокол, который предназначен как раз для этого, и Open WebUI, как самый популярный открытый AI интерфейс.
Наконец, модульная архитектура пайплайнов в OpenWebUI позволяет легко поддерживать несколько LLM провайдеров – я тестировал свою платформу с API OpenAI и публичными эндпоинтами в облаке.
В общем, я решил проблему интеграции агента с внешними MCP-серверами. Остается вопрос развертывания самих MCP-серверов на моей платформе, над решением которого я сейчас работаю. Насколько я могу судить, Docker MCP каталог является популярным местом для поиска серверов, предоставляющих интеграции на все случаи жизни. Если есть более известные MCP хабы, дайте знать в комментариях.
А пока я решил деплоить контейнеры с MCP в облачную среду, откуда мои агенты смогут без проблем их вызывать. Это звучит относительно просто, но неоднозначен как минимум сетевой вопрос: как сделать, чтобы общение агента с MCP было должным образом защищено?
Возникает потребность в приватной сети, но об этом уже в другой раз.
Создание платформы, которая позволяет автоматизировать интеграцию агентов с внешними инструментами, стоит на повестке дня в AI индустрии.
Однако, как и MCP протокол, эта платформа должна быть открытой для кастомизации, предоставлять разработчикам доступ к своим внутренним модулям и API. Тот уровень контроля, который дает OpenAI в случае со своими MCP коннекторами в режиме разработчика ChatGPT, на мой взгляд, недостаточен.
В этом и состоит рациональное обоснование моего пока еще экспериментального проекта.
Автор: ruslandevlabs
