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

> Порядок проверки сервера MCP перед подключением - кто публикует, что доказывает имя в реестре, где он исполняется, как авторизуется, какие права получает, какую редакцию заявляет

Страница: https://mcpdoc.ru/servers/choose/
Указатель сайта: https://mcpdoc.ru/llms.txt

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

Главное, что нужно помнить: запись в официальном реестре подтверждает только владение пространством имён. Код реестр не проверяет. Метка «проверено» в каталоге - не аудит безопасности.

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

## Порядок проверки

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

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

## 1. Кто публикует

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

- **Сервер компании** - его ведёт владелец сервиса, к которому сервер даёт доступ. Подтверждение - документация на сайте самой компании. Список проверенных случаев - на странице [Серверы компаний](https://mcpdoc.ru/servers/vendors/).
- **Эталонный сервер проекта MCP** - один из семи серверов репозитория `modelcontextprotocol/servers`. Проект называет их учебными примерами, а не готовыми решениями для промышленной эксплуатации; подробнее - на странице [Эталонные серверы](https://mcpdoc.ru/servers/overview/).
- **Сторонний сервер** - всё остальное: сервер другой компании или отдельного автора. Репозиторий на GitHub с названием сервиса в имени не делает сервер сервером этого сервиса.

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

Тринадцать прежних эталонных серверов перенесены в архивный репозиторий, но их имена до сих пор встречаются в образцах настроек - в том числе в корневом README самого проекта. Перед копированием образца сверьте имя пакета со списком на странице [Эталонные серверы](https://mcpdoc.ru/servers/overview/).

## 2. Что доказывает имя в реестре

Имя сервера в [официальном реестре MCP](https://mcpdoc.ru/registry/) состоит из пространства имён и названия. По [правилам авторизации реестра](https://modelcontextprotocol.io/registry/authentication), пространство имён бывает двух видов:

| Вид имени | Что подтверждено при публикации |
|---|---|
| `io.github.<имя>/...` | издатель вошёл под этой учётной записью или организацией GitHub |
| `com.example/...` (домен наоборот) | издатель управляет доменом: подтверждение записью DNS или файлом на сайте |

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

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

- о проверке кода, со страницы [«О реестре»](https://modelcontextprotocol.io/registry/about): реестр передаёт проверку безопасности реестрам пакетов и каталогам-агрегаторам; сам он занимается подтверждением пространства имён и хранением метаданных;
- о модерации, со страницы [правил модерации](https://modelcontextprotocol.io/registry/moderation-policy): реестр не даёт гарантий о модерации, и потребителям следует исходить из того, что она минимальна или отсутствует;
- о том, что не удаляется, оттуда же: серверы низкого качества и серверы с уязвимостями из реестра не удаляют; удаляют незаконное содержимое, вредоносные программы, спам и полностью неработающие серверы;
- о том, что хранится, со страницы [быстрого старта](https://modelcontextprotocol.io/registry/quickstart): реестр хранит только метаданные, а не сами пакеты.

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

### Как прочитать запись самому

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

```bash title="Последняя версия записи о сервере"
curl "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.github%2Fgithub-mcp-server/versions/latest"
```

```json title="Ответ (сокращён)"
{
  "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`.

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

## 3. Локальный или удалённый

**Локальный сервер.** При транспорте stdio клиент сам запускает сервер как дочерний процесс - так описывает это [спецификация](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports). Значит, на вашей машине исполняется чужой код из npm, PyPI или образа контейнера. Реестр MCP этот код не проверял: по его же словам, проверка оставлена реестрам пакетов. Вопросы к локальному серверу:

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

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

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

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

Подробнее о транспортах - на странице [Транспорты](https://mcpdoc.ru/protocol/transports/).

## 4. Как авторизуется

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

| Способ | Как выглядит | Что проверить |
|---|---|---|
| OAuth | вход через браузер, клиент получает токен | какие области доступа запрашиваются; умеет ли ваш клиент нужный способ регистрации |
| ключ API или личный токен | заголовок `Authorization` или переменная окружения | какие права у ключа; где он хранится |
| облачная учётная запись | права задаются средствами облака | какой роли выдан доступ |
| без авторизации | сервер открыт | что именно он отдаёт и принимает |

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

Способы регистрации клиента у разных поставщиков различаются; это разобрано на странице [Регистрация клиента: CIMD и DCR](https://mcpdoc.ru/auth/client-registration/). Общий порядок авторизации - на странице [Авторизация](https://mcpdoc.ru/auth/).

## 5. Какие права получает

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

- **Область.** Каталог для сервера файлов, репозиторий для сервера Git, области доступа токена. Давайте самую узкую.
- **Изменяющие инструменты.** Прочитайте список инструментов до подключения и отметьте те, что записывают, удаляют или отправляют.
- **Аннотации.** Пометки `readOnlyHint` и `destructiveHint` помогают клиенту, но доверять им без оглядки нельзя. Спецификация требует: клиент обязан считать аннотации инструментов недоверенными, если они получены не от доверенного сервера ([раздел Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)).
- **Подтверждение вызовов.** Спрашивает ли клиент разрешение на каждый вызов - свойство клиента. Сведения по клиентам собраны в [справочнике клиентов](https://mcpdoc.ru/reference/clients/).

Угрозы, ради которых всё это делается, разобраны на странице [Угрозы](https://mcpdoc.ru/security/threats/).

## 6. Какую редакцию заявляет

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

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

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

Зачем это знать: клиенту и серверу нужна общая редакция, иначе они не договорятся. Что поддерживает ваш клиент, смотрите в [справочнике клиентов](https://mcpdoc.ru/reference/clients/); чем редакции различаются - на странице [Версии протокола](https://mcpdoc.ru/protocol/versions/).

## Метка в каталоге - не аудит

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

- Anthropic о метке Verified в своём каталоге ([страница о проверке](https://claude.com/docs/connectors/verification), в переводе): Anthropic проверила инструменты коннектора на качество и совместимость; это не аудит безопасности и не гарантия того, как коннектор будет работать.
- Docker о своём каталоге ([документация](https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/), в переводе): проверенные серверы снабжены версиями, сведениями о происхождении и перечнем состава (SBOM). Это сведения о сборке образа, а не о поведении инструментов.
- У части каталогов определение метки на прочитанных страницах не найдено.

Чем каталоги отличаются друг от друга и от официального реестра - на странице [Каталоги серверов](https://mcpdoc.ru/registry/catalogs/).

## Короткая памятка

| Вопрос | Хороший ответ | Повод остановиться |
|---|---|---|
| Кто публикует | владелец сервиса, и он сам так пишет | владельца установить не удалось |
| Имя в реестре | пространство имён совпадает с владельцем | похожее имя от другого издателя |
| Где исполняется | понятно, какой пакет и какой версии | каждый запуск берёт последнюю версию неизвестного пакета |
| Авторизация | OAuth или ключ с узкими правами | ключ с полным доступом |
| Права | узкая область, изменяющие инструменты известны | доступ ко всему домашнему каталогу |
| Редакция | названа в документации | выведена из догадок |

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

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

- [MCP Registry](https://mcpdoc.ru/registry/) - что такое официальный реестр и что в нём хранится.
- [Серверы компаний](https://mcpdoc.ru/servers/vendors/) - серверы, владелец которых подтверждён документацией.
- [Рекомендации по безопасности](https://mcpdoc.ru/security/best-practices/) - что настроить после выбора сервера.
- [Context7](https://mcpdoc.ru/servers/context7/) - тот же порядок проверки на одном примере.