MCP Registry: как выбирать сервер без риска для команды

Раздел

MCP-серверы

Сложность

средняя

Обновлено

2026-06-03

Короткий ответ

MCP Registry помогает найти публичный MCP-сервер и понять, кто его опубликовал, где лежит package или remote endpoint, как его запускать и какие metadata доступны клиентам. Но registry не делает сервер безопасным автоматически. Перед подключением к Cursor, Codex, Claude Desktop или локальному агенту команда должна проверить namespace, исходный package, команду запуска, tools, secrets, transport, журнал и способ отключения.

На 2026-06-03 официальный MCP Registry находится в preview: metadata и API полезны для discovery, но это не security-аудит кода и не рекомендация подключать любой найденный сервер. Поэтому правильный маршрут такой: сначала выбрать один reader job, затем найти кандидата в registry или downstream marketplace, потом проверить package/source, запустить в sandbox, включить только read-only tools и только после логов реальных задач расширять доступ.

Эта страница не повторяет MCP сервер: что это, локальный MCP-сервер и Cursor MCP. Здесь фокус уже на выборе готового public server-а: как не принять наличие в registry за гарантию качества.

Что дает Registry

Официальная документация описывает MCP Registry как централизованный metadata repository для публично доступных MCP-серверов. Он хранит не “проверенный продукт под ключ”, а сведения о сервере: имя, namespace, package или remote URL, инструкции запуска, capabilities и другие discovery-данные.

Практически это полезно в трех случаях:

Главный вывод: registry ускоряет discovery, но решение о подключении остается на команде. Если сервер просит токен CRM, доступ к файловой системе или запуск shell-команды, его надо проверять как обычную интеграцию с правами.

Почему metadata недостаточно

В registry есть namespace authentication: server name привязывается к проверенному GitHub-аккаунту или домену. Это помогает понять, что publisher контролирует заявленный namespace. Но это не означает, что сервер безопасен, подходит вашей задаче или не меняет поведение в следующей версии.

Проверьте минимум:

• namespace совпадает с ожидаемым разработчиком или доменом;
• package опубликован в нормальном registry, а не через случайный архив;
• repository, issue tracker и release history выглядят живыми;
• install command не скачивает произвольный script без review;
• server не требует admin-token на старте;
• transport понятен: stdio, Streamable HTTP или remote endpoint;
• tools можно включить частями, а не все сразу;
• есть способ pin-нуть версию и быстро отключить server.

Если этих ответов нет, не подключайте сервер в рабочий репозиторий. Сначала сделайте sandbox-проверку на тестовых данных.

Как читать server.json

Формат server.json описывает server name, package, transport, version, repository и environment variables. Для пользователя важны не поля сами по себе, а риски, которые они показывают.

Плохой сигнал: metadata говорит “read-only docs”, а package просит wide OAuth scope, доступ к home directory или token с записью. В таком случае доверяйте не описанию, а фактическим правам.

Security review перед подключением

MCP security best practices отдельно предупреждают про local server compromise, token passthrough, confused deputy и слишком широкие scopes. Для команды это превращается в простой preflight.

1. Запускайте новый server только в тестовой папке.
2. Покажите reviewer-у точную команду запуска, args и env names.
3. Не передавайте реальные .env, SSH keys, production tokens и private customer data.
4. Проверьте tools/list: нет ли run_shell, read_any_file, write_crm, deploy, query_any_sql.
5. Для remote/OAuth server-а проверьте scopes, redirect flow и audience.
6. Для local HTTP проверьте bind к 127.0.0.1, auth и Origin check.
7. Включите logs без tokens, headers и полных персональных данных.
8. Запишите owner, version, rollback и дату проверки.

Если server нужен только для документации библиотеки, не давайте ему доступ к repository source. Если server нужен для CRM, начните с read-only summary tools и черновиков действий, а не с записи в сделки.

Как выбирать tools

Перед подключением опишите один reader job. Например: “агент должен найти актуальный фрагмент документации библиотеки”, “показать status CI”, “прочитать карточку задачи”, “получить summary сделки без персональных данных”.

Затем сравните tools server-а с этой задачей:

MCP client best practices рекомендуют progressive discovery, когда серверов и tools много: host не должен грузить в model context все tool definitions сразу. Для внедрения это означает: не подключайте десятки server-ов “на будущее”. Чем меньше visible tools, тем проще агенту выбрать правильный вызов и тем легче проводить review.

Пилот в Cursor, Codex или локальном агенте

Для Cursor сначала решите, нужен project config или global config. Готовый public server из registry не обязан попадать в каждый репозиторий. Если он нужен только одному проекту, держите включение рядом с этим проектом и фиксируйте owner.

Для Codex и других terminal agents важнее command boundary: что именно запускается, в какой директории, с какими env, есть ли network, какие файлы можно читать и какие команды запрещены.

Для локального server-а используйте маршрут из статьи Локальный MCP-сервер: test command, Inspector, expected tools, forbidden paths и logs. Для Cursor-specific rollout откройте Cursor MCP. Если server нужен нескольким AI-клиентам в репозитории, полезен разбор MCP для Cursor и Codex.

Минимальный pilot:

1. Один server.
2. Одна тестовая папка или sandbox workspace.
3. Один read-only tool.
4. Десять реальных вопросов.
5. Пять запретных вопросов.
6. Review логов.
7. Go/no-go и список удаленных tools.

Когда лучше не брать public server

Public server из registry не подходит, если:

• данные компании нельзя отправлять внешнему service;
• server требует слишком широкий token;
• source или package нельзя проверить;
• нужны private endpoints или internal package registry;
• регуляторные требования запрещают public metadata;
• server должен работать с production-записью с первого дня;
• команда не может pin-нуть версию или отключить server быстро.

В этих случаях лучше сделать private MCP server или вообще обычный backend API. Registry полезен как reference для metadata и discovery, но private процессы не обязаны становиться публичными.

Чеклист

• Reader job сформулирован до поиска server-а.
• Namespace и publisher проверены.
• Package/source/repository просмотрены отдельно от registry metadata.
• Версия зафиксирована.
• Install command и env names понятны reviewer-у.
• Реальные secrets не попадают в config, logs, screenshots и task history.
• Первый запуск идет в sandbox.
• Tools read-only или draft-only.
• OAuth scopes и token audience ограничены.
• Local HTTP не слушает 0.0.0.0.
• Logs пишут tool, user, status и trace id без чувствительных данных.
• Есть owner, rollback и дата source check.

FAQ

Если сервер есть в Official MCP Registry, он безопасен?

Нет. Registry помогает найти metadata и проверить namespace, но безопасность package, scopes, tools и runtime поведения нужно оценивать отдельно. Terms of Service прямо перекладывают решение о пригодности server-а на пользователя.

Можно ли подключать public MCP server к production CRM?

Не на первом шаге. Сначала sandbox, read-only scope, masked summary tools, audit log и human approval. Запись в CRM требует отдельного проектирования.

Что лучше: public server из Registry или свой private server?

Public server хорош для открытых docs, библиотек, демо и типовых SaaS-сценариев. Private server лучше для внутренних систем, персональных данных, закрытых API и процессов, где права должны совпадать с корпоративной моделью доступа.

Нужно ли публиковать внутренний сервер в Registry?

Нет. Официальный registry рассчитан на publicly accessible servers. Для internal tools используйте private catalog или private registry/API, а не публичную metadata-запись.

Что читать дальше?

Начните с MCP сервер: что это, если нужна архитектура. Для безопасного локального запуска откройте локальный MCP-сервер. Для подключения в Cursor смотрите Cursor MCP, а для командного репозитория - MCP для Cursor и Codex. Если нужен внешний audit перед включением server-а, отправьте brief на разбор Woghan.