Как выбрать и проверить сервер

сверено с первичными источниками 4 октября 2026

1. Кто публикует. Найдите владельца: компания - хозяин сервиса, проект MCP или сторонний автор.
2. Что доказывает имя в реестре. Только владение пространством имён.
3. Локальный или удалённый. От этого зависит, где исполняется код и куда уходят данные.
4. Как авторизуется. OAuth, ключ или токен, облачная учётная запись - либо никак.
5. Какие права получает. Каталоги, репозитории, области доступа, изменяющие инструменты.
6. Какую редакцию заявляет. Если не заявляет никакой - так и считайте.

Ниже каждый шаг разобран отдельно.

Есть три разных случая, и их нельзя смешивать.

• Сервер компании - его ведёт владелец сервиса, к которому сервер даёт доступ. Подтверждение - документация на сайте самой компании. Список проверенных случаев - на странице Серверы компаний.
• Эталонный сервер проекта MCP - один из семи серверов репозитория modelcontextprotocol/servers. Проект называет их учебными примерами, а не готовыми решениями для промышленной эксплуатации; подробнее - на странице Эталонные серверы.
• Сторонний сервер - всё остальное: сервер другой компании или отдельного автора. Репозиторий на GitHub с названием сервиса в имени не делает сервер сервером этого сервиса.

Чего не достаточно для вывода о владельце: названия, значка в каталоге, слова «official» в описании. Достаточно одного - страницы на сайте владельца сервиса, где он сам называет этот сервер своим.

Имя сервера в официальном реестре MCP состоит из пространства имён и названия. По правилам авторизации реестра, пространство имён бывает двух видов:

Это всё, что доказывает имя: издатель управляет пространством имён. О коде имя ничего не говорит.

Что реестр о себе пишет сам (в переводе):

• о проверке кода, со страницы «О реестре»: реестр передаёт проверку безопасности реестрам пакетов и каталогам-агрегаторам; сам он занимается подтверждением пространства имён и хранением метаданных;
• о модерации, со страницы правил модерации: реестр не даёт гарантий о модерации, и потребителям следует исходить из того, что она минимальна или отсутствует;
• о том, что не удаляется, оттуда же: серверы низкого качества и серверы с уязвимостями из реестра не удаляют; удаляют незаконное содержимое, вредоносные программы, спам и полностью неработающие серверы;
• о том, что хранится, со страницы быстрого старта: реестр хранит только метаданные, а не сами пакеты.

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

Чтение реестра не требует входа. Имя сервера в адресе кодируется: косая черта превращается в %2F.

curl "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.github%2Fgithub-mcp-server/versions/latest"

{
  "server": {
    "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
    "name": "io.github.github/github-mcp-server",
    "title": "GitHub",
    "repository": { "url": "https://github.com/github/github-mcp-server", "source": "github" },
    "version": "1.13.0",
    "packages": [
      {
        "registryType": "oci",
        "identifier": "ghcr.io/github/github-mcp-server:1.13.0",
        "transport": { "type": "stdio" }
      }
    ],
    "remotes": [
      {
        "type": "streamable-http",
        "url": "https://api.githubcopilot.com/mcp/"
      }
    ]
  },
  "_meta": {
    "io.modelcontextprotocol.registry/official": {
      "status": "active",
      "publishedAt": "2026-10-01T19:11:57.013204Z",
      "isLatest": true
    }
  }
}

Запрос выполнен 4 октября 2026 года; ответ сокращён.

На что смотреть в ответе:

• name - пространство имён до косой черты. Здесь это io.github.github, то есть организация github на GitHub.
• repository.url - откуда взят код. Сверьте владельца репозитория с пространством имён.
• packages - что будет запущено локально и из какого реестра пакетов.
• remotes - адрес удалённого сервера. Сверьте домен с доменом владельца сервиса.
• status - active, deprecated или deleted.

Поиск в реестре идёт только по подстроке имени. Запрос по названию сервиса вернёт и записи других издателей с похожими именами, поэтому сверяйте имя целиком.

Локальный сервер. При транспорте stdio клиент сам запускает сервер как дочерний процесс - так описывает это спецификация. Значит, на вашей машине исполняется чужой код из npm, PyPI или образа контейнера. Реестр MCP этот код не проверял: по его же словам, проверка оставлена реестрам пакетов. Вопросы к локальному серверу:

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

Ограничение прав процесса средствами операционной системы или контейнера - практика, не правило MCP.

Удалённый сервер. Код исполняется у поставщика, а к нему уходят аргументы вызовов и то, что модель в них написала. Вопросы к удалённому серверу:

• совпадает ли домен с доменом владельца сервиса;
• какой транспорт: Streamable HTTP или старый HTTP+SSE, который реестр называет устаревшим;
• что поставщик пишет о хранении запросов.

Подробнее о транспортах - на странице Транспорты.

У серверов встречаются четыре случая:

Отсутствие авторизации само по себе не порок: так работают серверы с открытой документацией. Но сервер с изменяющими инструментами и без авторизации - повод остановиться; это совет этого сайта, а не правило протокола.

Способы регистрации клиента у разных поставщиков различаются; это разобрано на странице Регистрация клиента: CIMD и DCR. Общий порядок авторизации - на странице Авторизация.

Сервер получает ровно то, что вы ему дали, - и модель может всем этим воспользоваться.

• Область. Каталог для сервера файлов, репозиторий для сервера Git, области доступа токена. Давайте самую узкую.
• Изменяющие инструменты. Прочитайте список инструментов до подключения и отметьте те, что записывают, удаляют или отправляют.
• Аннотации. Пометки readOnlyHint и destructiveHint помогают клиенту, но доверять им без оглядки нельзя. Спецификация требует: клиент обязан считать аннотации инструментов недоверенными, если они получены не от доверенного сервера (раздел Tools).
• Подтверждение вызовов. Спрашивает ли клиент разрешение на каждый вызов - свойство клиента. Сведения по клиентам собраны в справочнике клиентов.

Угрозы, ради которых всё это делается, разобраны на странице Угрозы.

Редакция протокола - это утверждение, которое делает сам поставщик. Его нельзя вывести:

• из названия сервера или компании;
• из того, что сервер официальный или эталонный;
• из SDK, от которого зависит пакет;
• из даты выпуска.

Если в документации сервера редакция не названа, записывайте «не заявлена». Все семь эталонных серверов проекта MCP на дату проверки редакцию не заявляют.

Зачем это знать: клиенту и серверу нужна общая редакция, иначе они не договорятся. Что поддерживает ваш клиент, смотрите в справочнике клиентов; чем редакции различаются - на странице Версии протокола.

Каталоги серверов ставят метки «verified», «official» и похожие. У каждого каталога своё определение, и ни одно из прочитанных не означает проверку безопасности кода.

• Anthropic о метке Verified в своём каталоге (страница о проверке, в переводе): Anthropic проверила инструменты коннектора на качество и совместимость; это не аудит безопасности и не гарантия того, как коннектор будет работать.
• Docker о своём каталоге (документация, в переводе): проверенные серверы снабжены версиями, сведениями о происхождении и перечнем состава (SBOM). Это сведения о сборке образа, а не о поведении инструментов.
• У части каталогов определение метки на прочитанных страницах не найдено.

Чем каталоги отличаются друг от друга и от официального реестра - на странице Каталоги серверов.

Таблица - схема этого сайта, а не требование протокола.

• MCP Registry - что такое официальный реестр и что в нём хранится.
• Серверы компаний - серверы, владелец которых подтверждён документацией.
• Рекомендации по безопасности - что настроить после выбора сервера.
• Context7 - тот же порядок проверки на одном примере.