Подключить первый MCP-сервер просто: нашли в списке, добавили пару строк в конфиг — и агент уже ходит в Jira. Проблемы начинаются на тридцатом: никто не помнит, какие серверы подключены, кто их одобрял, какие scope выданы и кто за них отвечает. Рост без каталога — это зоопарк, где каждый ноутбук живет своей жизнью.
Каталог — способ сделать рост управляемым: один реестр, версионирование, владелец и аудит.
Почему без каталога рост ломается
Без реестра через полгода невозможно ответить на базовые вопросы:
- какие MCP-серверы ходят в прод-данные;
- кто одобрял каждый из них;
- какие инструменты разрешены, а какие нет;
- кто и когда обновлял сервер в последний раз.
При локальной схеме каждый ноутбук — своя копия каталога, отзыв токена — обход команды, аудит — опрос «кто чем пользовался». Чем больше серверов, тем дороже каждая операция. Каталог переносит эти вопросы из голов в систему.
Что хранить в записи каталога
Минимальная запись, без которой каталог бесполезен:
- имя, источник (репозиторий/URL) и версия;
- владелец подключения — человек, который одобрил и отвечает;
- разрешенные инструменты и запрещенные категории операций;
- требуемые scopes и где хранится секрет;
- дата последнего ревью и хеш описаний инструментов на момент ревью.
Хеш описаний — простая защита от rug pull: при каждом ревью сравниваете текущие definitions с зафиксированными. Расхождение без смены версии — инцидент. Так вы ловите ситуацию, когда «безопасный вчера» сервер меняет поведение без вашего участия.
Храните каталог там же, где остальные инженерные политики — в репозитории с code review на каждое изменение. Новый MCP-сервер проходит процедуру как новый внешний подрядчик, а не как пакет по прихоти разработчика.
Версионирование и защита от rug pull
MCP-сервер — это сторонний код, который публикует описания инструментов. Эти описания агент видит всегда, даже если не вызывает инструмент. Поэтому версионирование — не формальность:
- пиньте версию (точное значение, а не «latest»);
- ведите changelog — что изменилось в инструментах между версиями;
- храните хеш описаний и сверяйте при обновлении;
- требуйте повторного ревью при любом расхождении.
Без этого обновление сервера ломает вашу модель угроз молча: вчерашний read-only инструмент завтра может стать пишущим, и вы узнаете об этом из инцидента.
Владелец и процесс одобрения
У каждой записи должен быть владелец — человек, а не команда. Владелец отвечает за ревью, scope и решение «оставляем или отключаем». Процесс одобрения — легкая, но явная процедура:
- чек-лист перед подключением (кто автор, где исполняется, какие scope, что умеют инструменты, чистые ли описания, как версионируется);
- ревью владельцем;
- запись в каталог с хешем описаний.
Так «подключить MCP-сервер» перестает быть действием одного разработчика в своем конфиге и становится инженерным решением с ответственностью.
Аудит использования
Каталог без аудита — справочник, а не контроль. Фиксируйте каждое использование:
- какой агент, под чьими правами вызвал инструмент;
- какой сервер и версия;
- какие данные затронуты.
Так вы видите, какие серверы реально используются, а какие можно отключить, и быстро отвечаете на вопрос «кто за это отвечает» при инциденте. Подробнее про аудит — в статье «Аудит действий агента».
Где Codenik: каталог как управляемый слой
Codenik построен как такой каталог: управляемый слой между AI-агентами и MCP-инструментами. Он ведет реестр одобренных серверов с версиями и владельцами, выдает агенту только разрешенные инструменты, хранит секреты на своей стороне и пишет аудит каждого вызова.
Команда добавляет новый сервер один раз — через процедуру в каталоге, а не в каждый конфиг отдельно. Обновился сервер — вы видите diff описаний до того, как его получат агенты. Подробнее про чек-лист подключения — в статье «Как подключать сторонние MCP-серверы без риска».
Короткий вывод
Каталог MCP-инструментов — это способ пережить рост с трех серверов до тридцати без зоопарка. Запись с версией, владельцем, scope и хешем описаний, версионирование без latest, ревью на каждое изменение и аудит использования превращают «ставим что угодно» в управляемый процесс.
Чем раньше каталог появится, тем дешевле будет каждый следующий сервер — и тем проще будет ответить, кто за него отвечает.