Пользовательские каталоги и профили MCP в Docker

Когда мы начали работать с MCP в командном контексте, первый же вопрос оказался не техническим, а организационным: как договориться о том, каким серверам доверять и как не настраивать одно и то же по десять раз? Пользовательские каталоги и профили MCP — это прямой ответ на этот вопрос, и в этой статье я разберу, как они устроены и как их использовать на практике

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

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

Установка Docker на Ubuntu — это первый шаг для работы с контейнерами. В отдельной инструкции разобран базовый путь от установки до первого запуска Docker на сервере. Как установить Docker на Ubuntu — пошаговая инструкция

Понимание Dockerfile необходимо для создания собственных образов Docker. Прочитайте, как создать свой собственный образ для эффективного управления серверами. Dockerfile — создаём собственный образ Docker

Docker Compose позволяет запускать многоконтейнерные приложения легко и просто. Узнайте, как использовать Docker Compose для вашей инфраструктуры с помощью этой инструкции. Docker Compose — запуск многоконтейнерных приложений

Как создать пользовательский каталог MCP в Docker

С внедрением MCP организации часто сталкиваются с одной и той же проблемой: командам необходимо создать доверенный список серверов MCP, включая те, которые разработаны внутри компании

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

Пользовательские каталоги могут ссылаться на серверы из каталога MCP Docker, сообщества и пользовательские разработки внутри компании, обеспечивая гибкость и контроль в одном интерфейсе

Создание и публикация каталога MCP: пошаговое руководство

В этом примере мы создадим пользовательский каталог, содержащий серверы из каталога Docker MCP и сервер MCP, созданный нами самостоятельно с помощью CLI (интерфейса командной строки). Затем мы покажем, как использовать Docker Desktop для импорта каталога

Функциональные возможности, которые мы продемонстрируем, доступны через CLI; часть пользовательских функций можно использовать через Docker Desktop

В примерах мы будем использовать идентификатор Docker Hub roberthouse224; пожалуйста, адаптируйте команды под свои данные

Шаг 1: Создание пользовательского сервера

MCP и его публикация в Docker Hub

Мы создали эталонный сервер под названием roll-dice (репозиторий GitHub). Это обычный сервер MCP, который взаимодействует через stdio и может быть собран как образ Docker. Образ уже собран и опубликован в Docker Hub

Мы можем создать метаданные, описывающие сервер, включая расположение образа, и сохранить их в файл с именем mcp-dice.yaml для использования при создании каталога

Шаг 2: Создание каталога, включающего серверы из каталога

Docker MCP и сервер, созданный самостоятельно

Теперь мы можем создать пользовательский каталог, содержащий серверы из каталога Docker MCP и сервер MCP, созданный нами самостоятельно

Шаг 3: Проверка серверов MCP в пользовательском каталоге

Теперь мы можем вывести список наших каталогов и увидеть созданный нами каталог:

docker mcp catalog list

Мы также можем просмотреть содержимое каталога:

docker mcp catalog show roberthouse224/our-catalog --format yaml

На текущий момент наш пользовательский каталог существует только на нашем компьютере. Следующий шаг — неизменяемый OCI-артефакт, который включает наши доверенные серверы MCP и подходит для передачи внутри команды

Мы можем опубликовать наш каталог в контейнерном реестре; в данном случае это будет Docker Hub. Теперь любой, у кого есть доступ к пространству имён вашей организации, сможет использовать данный каталог

docker mcp catalog push roberthouse224/our-catalog

Использование пользовательского каталога MCP

Теперь, когда наш пользовательский каталог опубликован, коллеги могут импортировать его из Docker Desktop или из CLI с помощью команды docker mcp catalog pull

Импортируйте каталог из Docker Desktop, выбрав «Import catalog», а затем указав ссылку OCI в диалоговом окне

Рисунок 1: Импорт пользовательского каталога по ссылке OCI

Каталог теперь доступен для просмотра. Вы можете дважды щёлкнуть по каталогу и увидеть все содержащиеся в нём серверы. Обратите внимание на пользовательский сервер MCP, который мы добавили под названием «Roll Dice»

Рисунок 2: Пользовательский каталог MCP в приложении Docker Desktop, включая только что добавленный сервер «Roll Dice»

Чтобы сделать каталог приватным, достаточно управлять доступом к репозиторию так же, как вы всегда делали это для образов контейнеров — никакой новой инфраструктуры для управления или систем для изучения

Именно это описывал Джим Кларк в своей статье «Приватные каталоги MCP и путь к компонуемому корпоративному ИИ»

Этот простой шаблон можно расширить для поддержки более сложных сценариев использования. Например, вместо Docker Hub можно использовать приватный реестр контейнеров или подключиться к удалённому серверу MCP через streamable HTTP, который вы размещаете самостоятельно, вместо запуска контейнеризованного сервера, как показано в примере

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

Профили MCP: создание и совместное использование рабочих процессов

С помощью MCP Profiles (профилей MCP) разработчики могут эффективно организовывать рабочие процессы и поддерживать отдельные коллекции серверов и конфигурации для разных сценариев использования. Профили можно передавать между командами, что обеспечивает совместную работу над настройками серверов и гарантирует единообразие конфигураций для команд, работающих в рамках одних и тех же проектов или контекстов

Переключение между профилями

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

Рассмотрим пример в действии

Мы создаём профиль с именем coding и ещё один с именем planning. Открываем наш пользовательский каталог, выбираем нужные MCP-серверы — например, Playwright, GitHub и Context7 — затем нажимаем выпадающий список «Add to» и выбираем «New profile»

Рисунок 3: Выбор MCP-серверов для добавления в новый профиль

Задаём имя профилю, выбираем клиент, к которому хотим подключиться, и нажимаем «Create»

Рисунок 4: Создание нового MCP-профиля с именем coding в Docker Desktop

На вкладке Profiles мы видим только что созданный профиль. Клиент подключён, и инструменты готовы к использованию

Рисунок 5: Пример профиля, подключённого к клиенту

Далее создаём профиль с именем planning с серверами, актуальными для планирования — например, Atlassian, Markitdown, Notion

Возвращаемся в «our-catalog» (если мы уже не там), выбираем серверы, относящиеся к планированию, и нажимаем «Add to» → «New profile». Задаём имя профилю (planning), затем нажимаем «Create», чтобы создать профиль planning без клиента. Указание клиента является необязательным

Рисунок 6: Пример создания нескольких профилей, включая отдельные профили для coding и planning

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

Рисунок 7: Переназначение Claude Code на профиль planning

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

Это работает с любым агентом, а не только с Claude Code. Профили обеспечивают по-настоящему переносимый способ управления настройками MCP-серверов и позволяют избежать привязки к конкретному поставщику

Сохранение конфигурации

Можно избежать повторной настройки MCP-серверов, используя профиль. Профили добавляют уровень сохранения конфигураций MCP-серверов. Когда MCP-сервер предоставляет настраиваемые параметры, их можно один раз задать в профиле и загружать по мере необходимости, избегая повторной настройки

В этом примере мы указываем, к каким путям может обращаться Markitdown

Рисунок 8: Использование MCP-профиля для сохранения конфигураций серверов с целью повторного использования

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

Здесь мы включаем инструмент get_me из MCP-сервера GitHub и отключаем все остальные. Все остальные инструменты не будут отображаться в нашей агентской сессии и не будут занимать место в контекстном окне

Рисунок 9: Оптимизация контекстного окна путём включения только нужных инструментов в MCP-профиле

Эта модель сохранённой конфигурации становится значительно мощнее для MCP-серверов, разработанных внутри компании. Предоставляя более широкие параметры конфигурации, можно повторно использовать один и тот же сервер в разных проектах, перенастраивать его поведение в зависимости от контекста и добиваться более предсказуемых результатов

Совместное использование профилей

Поиск MCP-серверов и конфигураций, которые хорошо работают для проекта, не должен повторяться каждым членом команды. Как только вы нашли подходящую настройку, поделитесь ею с остальными участниками команды

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

docker mcp profile push coding [your-namespace]/coding

Чтобы загрузить его, достаточно выполнить соответствующую команду pull:

docker mcp profile pull [your-namespace]/coding

Хотя приведённый выше пример демонстрирует совместное использование профилей внутри команды, эта концепция естественным образом распространяется и на агентов. Навык агента мог бы, например, ссылаться на профиль и подтягивать необходимые MCP-серверы и их конфигурации в качестве зависимостей

Частые ошибки при работе с каталогами и профилями MCP

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

Смешивание доверенных и непроверенных серверов в одном каталоге. Пользовательский каталог — это инструмент доверия. Если добавлять в него серверы из произвольных источников без проверки, ценность каталога как «одобренного списка» теряется. Лучше поддерживать отдельные каталоги для экспериментальных и проверенных серверов

Избыточное количество инструментов в профиле. Контекстное окно агента ограничено. Профиль, включающий все доступные серверы и все их инструменты, быстро приводит к переполнению контекста и снижению качества ответов. Практичнее формировать узкие профили под конкретные задачи — как показано в примере с coding и planning

Отсутствие версионирования каталогов. OCI-артефакты поддерживают теги. Публикуя каталог без явного тега версии, вы лишаете команду возможности воспроизводимо работать с конкретной версией набора серверов. Используйте теги осмысленно — например, v1.0, stable, 2025-06

Повторная ручная настройка серверов вместо использования профилей. Если разработчик каждый раз вручную вводит параметры конфигурации MCP-сервера при старте новой сессии, это сигнал, что профиль ещё не используется по назначению. На нашем опыте, сохранённая конфигурация в профиле решает эту проблему раз и навсегда

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

Заключение и дальнейшие шаги

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

Пользовательские каталоги: общая основа

Пользовательские каталоги позволяют платформенным командам и администраторам определять одобренные MCP-серверы, объединять внутренние и публичные инструменты и распространять эти решения в виде единого переносимого артефакта. Это создаёт ясность и согласованность, одновременно снижая затраты на поиск и оценку инструментов

Профили: ускорение рабочих процессов

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

Вместе эти примитивы разделяют:

• что организация рекомендует — через пользовательские каталоги
• как люди работают изо дня в день — через профили

Это разделение обеспечивает здоровый баланс. Платформенные команды могут публиковать «золотые пути», устанавливающие стандарты и ограждения, тогда как разработчики сохраняют свободу адаптировать, экспериментировать и составлять профили, соответствующие их потребностям

Результатом является система, которая переносима, компонуема и масштабируема — делая MCP более простым для внедрения, более безопасным в управлении и более эффективным по мере его распространения в организации

Что дальше?

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

• Средства управления и контроля политик для ограничения использования MCP одобренными пользовательскими каталогами и доверенными источниками серверов
• Улучшенная обнаруживаемость и совместное использование как каталогов, так и профилей, что упрощает поиск и повторное использование проверенных настроек между командами
• Расширенные секреты и конфигурация на уровне профиля, обеспечивающие более безопасную и гибкую альтернативу файлам mcp.json на уровне проекта
• Чёткие лучшие практики для профилей, включая сохранение динамических конфигураций MCP-серверов для повторного использования и сочетание профилей с новыми оптимизациями рабочих процессов, такими как навыки агентов

Начало работы с пользовательскими каталогами и профилями

Если у вас установлен Docker Desktop 4.56, вы уже используете каталоги — наш Docker MCP Catalog теперь распространяется как OCI-артефакт, а профили поддерживаются начиная с Docker Desktop 4.63. Попробуйте создать свой первый профиль, изучив MCP Toolkit в Docker Desktop

Готовы приступить к практике? Откройте Docker Desktop или CLI и начните использовать MCP для оптимизации и автоматизации ваших рабочих процессов разработки

Ответы на эти вопросы могут быть для вас полезными

Чем пользовательский каталог MCP отличается от стандартного каталога Docker MCP?

Стандартный Docker MCP Catalog — это публичный набор серверов, поддерживаемый Docker. Пользовательский каталог создаётся организацией самостоятельно: он может включать как серверы из публичного каталога, так и внутренние серверы, разработанные внутри компании. Пользовательский каталог публикуется как OCI-артефакт в любом реестре контейнеров и доступен только тем, у кого есть права на соответствующий репозиторий

Можно ли использовать профили MCP с агентами, отличными от Claude Code?

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

Как профили помогают с переполнением контекстного окна?

В профиле можно явно указать, какие инструменты конкретного MCP-сервера включены, а какие отключены. Инструменты, не включённые в профиль, не передаются в агентскую сессию и не занимают место в контекстном окне. Это позволяет точно контролировать, что видит агент

Как сделать пользовательский каталог или профиль приватным?

Достаточно опубликовать OCI-артефакт в приватный репозиторий Docker Hub или в корпоративный реестр контейнеров. Управление доступом работает так же, как для любого образа контейнера — никакой дополнительной инфраструктуры не требуется

С какой версии Docker Desktop доступны каталоги и профили MCP?

Каталоги доступны начиная с Docker Desktop 4.56, профили — начиная с Docker Desktop 4.63