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, на мой взгляд, недостаточен.

В этом и состоит рациональное обоснование моего пока еще экспериментального проекта.