MCP-серверы и Docker MCP Toolkit: запуск и интеграция

Серверы Model Context Protocol (MCP) — это спецификация для предоставления инструментов, моделей или сервисов языковым моделям через единый интерфейс. Они служат адаптерами, которые улучшают взаимодействие между инструментом и LLM (большой языковой моделью) с помощью предсказуемого протокола, позволяющего модели работать с API, базами данных и агентами, не вникая в детали реализации

Но, как и у большинства хороших идей, дьявол кроется в деталях

Зная, как установить Docker на Ubuntu, вы сможете быстро развернуть свои MCP-серверы. Подробности можно найти в пошаговой инструкции

Использование Dockerfile позволит вам создать собственный образ для вашего MCP-сервера. Ознакомьтесь с нашими рекомендациями здесь

Для развертывания сложных приложений с использованием нескольких контейнеров стоит использовать Docker Compose. Узнайте больше о том, как запустить многоконтейнерные приложения

Реальные проблемы запуска MCP-серверов: рантайм, секреты, интеграции

Запуск MCP звучит просто: поднимите Python- или Node-сервер, который предоставляет ваш инструмент. Готово, правда? Не совсем

Проблемы возникают быстро, и я сам с ними сталкивался при первых экспериментах с MCP

Трения со средой выполнения. Если MCP написан на Python, вашей среде нужен Python — плюс зависимости, плюс, возможно, виртуальное окружение Python (virtualenv), плюс, возможно, драйверы GPU. То же самое касается Node. Это быстро умножается, когда вы управляете множеством MCP-серверов или развёртываете их в командах

Управление секретами. MCP-серверам часто нужны учётные данные: API-ключи, токены и т.д. Для эффективного функционирования требуется безопасный способ хранения и внедрения этих секретов в рантайм MCP, что усложняется при взаимодействии разных команд, инструментов или облаков. Рекомендуется хранить секреты в зашифрованных хранилищах (например, Docker Secrets) и передавать их в контейнер через переменные окружения, чтобы не вшивать значения в образ

Боль интеграции N×N. Если у вас три клиента, которые хотят потреблять MCP, и пять MCP для обслуживания, это приведёт к необходимости управлять 15 отдельными интеграциями

Чтобы сделать MCP практичными, необходимо решить три ключевые проблемы: сложность рантайма, внедрение секретов и соединение клиентов с серверами. При более внимательном контакте с этими проблемами становится очевидно, что мы уже располагаем технологиями, которые разработчики используют более десяти лет, — это Docker-контейнеры

В остальной части этого материала я рассмотрю три разных подхода — от наименее сложного к наиболее сложному — для интеграции MCP-серверов в ваш процесс разработки

Подробнее о настройке среды для работы с MCP-серверами и безопасном управлении секретами читайте на aglamov.biz

Docker MCP Toolkit и Catalog: запуск MCP-серверов без боли с рантаймами

Для разработчика, который уже использует контейнеры и хочет начать работу с MCP с минимальными трудностями

Если вы уверенно работаете с Docker и только начинаете знакомиться с MCP, вы на правильном пути. В классическом подходе к MCP вам нужно было бы клонировать серверы на Python или Node, управлять рантаймами, самостоятельно внедрять секреты и настраивать соединения с каждым клиентом. Именно эти вопросы решает экосистема Docker MCP

Docker MCP Catalog — это курируемый реестр контейнеризированных MCP-серверов. Каждая запись — это готовый контейнер со всем необходимым для запуска MCP-сервера

MCP Toolkit (доступный через Docker Desktop) — это ваша панель управления: поиск в каталоге, запуск серверов с безопасными настройками по умолчанию и подключение их к клиентам

Чем это помогает:

• Не нужно устанавливать языковые рантаймы
• Встроенное управление секретами
• Включение в один клик через Docker Desktop
• Простое подключение MCP к существующим агентам (Claude DesktopCopilot в в сравнении с Code и т.д.)
• Централизованный доступ через MCP Gateway

Docker MCP Catalog позволяет просматривать сотни MCP-серверов с фильтрами для локального или удалённого использования и чёткими различиями между официальными и сообщественными серверами

Одним из ключевых компонентов, работающим за кулисами как в MCP Toolkit, так и в cagent (фреймворке для создания мультиагентных приложений), является MCP Gateway. Это проект с открытым исходным кодом от Docker, который предоставляет централизованный фронтенд для всех MCP-серверов

Независимо от того, работаете ли вы через GUI для запуска контейнеров или определяете агентов в YAML, Gateway обеспечивает маршрутизацию, аутентификацию и трансляцию между клиентами и инструментами, предоставляя единую точку доступа

Использование MCP-серверов в сочетании с существующими AI-агентами — это часто первый шаг для разработчиков. Вы можете подключить несколько инструментов, интегрироваться с календарём или поисковым API и использовать их с такими системами, как Claude или ChatGPT

Пошаговые руководства по автоматизации рабочих процессов с помощью Docker MCP Catalog и Toolkit с популярными клиентами можно найти в материалах для ChatGPT, Claude Desktop, Codex, Gemini CLI и Claude Code. Как только этот паттерн становится понятным, логичным шагом будет использование тех же MCP-серверов как инструментов внутри мультиагентной системы

cagent: декларативные мультиагентные MCP-приложения

Для разработчика, который хочет создавать пользовательские мультиагентные приложения, не погружаясь в традиционные агентные фреймворки.

Если вы вышли за рамки простых MCP-серверов и хотите агентов, которые могут делегировать, координировать и рассуждать вместе, cagent — ваш следующий шаг. Это открытый, YAML-ориентированный фреймворк Docker для определения и запуска мультиагентных систем — без необходимости погружаться в сложные SDK агентов или логику LLM-циклов

Cagent позволяет описать:

• Самих агентов (модель, роль, инструкции)
• Кто кому делегирует
• К каким инструментам имеет доступ каждый агент (через MCP или локальные возможности)

Ниже приведён пример чат-бота в стиле пирата:

agents: root: description: An agent that talks like a pirate instruction: Always answer by talking like a pirate. welcome_message: | Ahoy! I be yer pirate guide, ready to set sail on the seas o' knowledge! What be yer quest? model: auto

cagent run agents.yaml

Вы не пишете код оркестрации. Вы описываете, что хотите, и cagent запускает систему

Почему это работает:

• Инструменты ограничены областью видимости каждого агента
• Делегирование явное
• Использует MCP Gateway за кулисами
• Идеально для создания агентных систем без написания Python-кода

На мой взгляд, cagent — наиболее удобная точка входа для команд, которые хотят получить мультиагентную систему без написания кода оркестрации с нуля. Если вы хотите попробовать cagent, в репозитории проекта на GitHub есть множество примеров. Ознакомьтесь с руководством по созданию мультиагентных систем за 5 минут

Традиционные агентные фреймворки для MCP: LangGraph, CrewAI, ADK

Для разработчиков, создающих сложные, полностью программные агентные системы.

Традиционные агентные фреймворки, такие как LangGraph, CrewAI или Agent Development Kit (ADK) от Google, позволяют определять, контролировать и оркестрировать поведение агентов непосредственно в коде. Вы получаете полный контроль над логикой, состоянием, памятью, инструментами и рабочими процессами

Они незаменимы, когда вам нужны:

• Сложная логика ветвления
• Восстановление после ошибок, повторные попытки и персистентность
• Пользовательские слои памяти или хранилища
• Тесная интеграция с существующим бэкенд-кодом

Пример: LangGraph + MCP через Gateway

import requests
from langgraph.graph import StateGraph
from langchain.agents import Tool
from langchain_openai import ChatOpenAI
# Discover MCP endpoint from Gateway
resp = requests.get("http://localhost:6600/v1/servers")
servers = resp.json()["servers"]
duck_url = next(s["url"] for s in servers if s["name"] == "duckduckgo")
# Define a callable tool
def mcp_search(query: str) -> str: return requests.post(duck_url, json={"input": query}).json()["output"]
search_tool = Tool(name="web_search", func=mcp_search, description="Search via MCP")
# Wire it into a LangGraph loop
llm = ChatOpenAI(model="gpt-4")
graph = StateGraph()
graph.add_node("agent", llm.bind_tools([search_tool]))
graph.add_edge("agent", "agent")
graph.set_entry_point("agent")
app = graph.compile()
app.invoke("What's the latest in EU AI regulation?")

В этой конфигурации вы решаете, какие инструменты доступны. Агент выбирает, когда их использовать, исходя из контекста, но вы определили меню И да, это по-прежнему верно в Docker MCP Toolkit: вы решаете, что включить. LLM не может вызвать то, что вы не сделали видимым

Как выбрать правильный подход

Типичные ошибки при работе с MCP-серверами

Даже когда архитектура выбрана правильно, на практике встречаются одни и те же грабли

Смешивание рантаймов без изоляции. Запуск Python- и Node-серверов в одной среде без контейнеризации быстро приводит к конфликтам зависимостей. Контейнер решает это структурно: каждый MCP живёт в своей изолированной среде

Хранение секретов в коде или образе. API-ключи, вшитые в Dockerfile или переданные через аргументы сборки, попадают в историю слоёв образа. Используйте Docker Secrets или переменные окружения, передаваемые в момент запуска контейнера

Игнорирование N×N-проблемы на старте. Когда у вас один клиент и один MCP, прямое соединение кажется разумным. Но стоит добавить второй клиент — и вы уже пишете дублирующую логику. MCP Gateway решает эту проблему превентивно, даже если сейчас у вас всего два сервера

Отсутствие явного делегирования в мультиагентных системах. Если агенты могут вызывать инструменты друг друга без явных правил, отладка превращается в детективную историю. Cagent решает это через декларативное описание делегирования в YAML; в LangGraph и CrewAI это нужно прописывать вручную

Независимо от того, просто ли вы подключаете инструмент к Claude, проектируете пользовательскую мультиагентную систему или вручную создаёте production-рабочие процессы, инструментарий Docker MCP помогает начать работу легко и безопасно

Мой совет — начните с Docker MCP Toolkit, даже если в перспективе планируете перейти на LangGraph или CrewAI: это самый быстрый способ понять, как инструменты взаимодействуют с моделью, прежде чем писать код оркестрации

Ознакомьтесь с Docker MCP Toolkit, cagent и MCP Gateway для примеров кода, документации и других способов начать работу

Частые вопросы об MCP-серверах и Docker

Чем MCP-сервер отличается от обычного API? MCP-сервер реализует стандартизированный протокол, который LLM понимает нативно: модель знает, как обнаружить доступные инструменты, вызвать их и интерпретировать ответ. Обычный API требует дополнительного слоя адаптации — кода, который переводит вызовы модели в HTTP-запросы и обратно

Нужно ли писать код, чтобы начать использовать MCP через Docker MCP Toolkit? Нет. Docker MCP Toolkit позволяет запускать готовые MCP-серверы из каталога через интерфейс Docker Desktop — без написания кода. Секреты настраиваются через GUI, подключение к клиентам вроде Claude Desktop происходит в один клик

Когда стоит выбирать cagent, а не LangGraph или CrewAI? Cagent подходит, когда вы хотите описать мультиагентную систему декларативно в YAML и не нуждаетесь в сложной программной логике: ветвлениях, персистентности состояния или кастомных слоях памяти. LangGraph и CrewAI дают больше контроля, но требуют написания кода оркестрации

Как MCP Gateway решает проблему N×N-интеграций? Gateway выступает единой точкой входа для всех MCP-серверов. Любой клиент обращается к Gateway, а не к каждому серверу напрямую. Это превращает N×N соединений в N+N: каждый клиент подключается к одному Gateway, каждый сервер регистрируется в одном Gateway

Можно ли использовать MCP-серверы из Docker MCP Catalog в LangGraph или CrewAI? Да. MCP Gateway предоставляет единую конечную точку, которую можно вызывать из любого фреймворка через стандартные HTTP-запросы. Пример с LangGraph в статье именно это и демонстрирует: сервер обнаруживается через Gateway и оборачивается в инструмент LangChain