# Публикация сервера

> Как опубликовать сервер MCP - пакет в npm, PyPI, NuGet, Cargo, OCI или MCPB, метка владения, запись в официальном реестре через mcp-publisher или GitHub Actions

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

Публикация сервера MCP состоит из двух отдельных шагов. Сначала вы выкладываете сам пакет в реестр пакетов: npm, PyPI, NuGet, crates.io, реестр образов или выпуск с файлом MCPB. Затем отправляете описание сервера в официальный реестр MCP командой `mcp-publisher`.

Первый шаг не заменяет второй. Пакет в npm не появляется в реестре MCP сам: реестр MCP не обходит реестры пакетов и хранит только те записи, которые прислали издатели.

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

## Два разных реестра

| | Реестр пакетов | Официальный реестр MCP |
|---|---|---|
| Что хранит | код и двоичные файлы | метаданные: файл `server.json` |
| Примеры | npm, PyPI, NuGet, crates.io, Docker Hub | `registry.modelcontextprotocol.io` |
| Зачем нужен | чтобы сервер можно было установить и запустить | чтобы каталоги и приложения могли сервер найти |
| Как туда попасть | средствами этого реестра, например `npm publish` | командой `mcp-publisher publish` |

Это разделение задано документацией: [реестр MCP хранит только метаданные, не сами пакеты](https://modelcontextprotocol.io/registry/quickstart). Поэтому пакет нужно выложить до публикации записи.

Реестр MCP работает в режиме preview: документация предупреждает о возможных несовместимых изменениях и сбросе данных до общей доступности. Что это за служба, рассказано на странице [«Официальный реестр MCP»](https://mcpdoc.ru/registry/).

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

## Порядок действий

1. Выберите имя сервера и способ подтвердить его пространство имён.
2. Добавьте в пакет метку владения - для npm это поле `mcpName`.
3. Выложите пакет в реестр пакетов.
4. Создайте `server.json`.
5. Войдите в реестр MCP и опубликуйте запись.

Ниже путь показан на пакете npm, как в [официальном руководстве](https://modelcontextprotocol.io/registry/quickstart). Для других типов пакетов меняются только шаги 2 и 3.

## Шаг 1. Метка владения в пакете

Реестр проверяет, что пакет действительно относится к серверу с таким именем. Для npm в `package.json` добавляют поле `mcpName`. Пример со страницы [«Package types»](https://modelcontextprotocol.io/registry/package-types):

```json title="package.json"
{
  "name": "@username/email-integration-mcp",
  "version": "1.0.0",
  "mcpName": "io.github.username/email-integration-mcp"
}
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался.

Значение `mcpName` обязано совпадать с полем `name` в `server.json`. При входе через GitHub имя обязано начинаться с `io.github.` и вашего имени пользователя или организации.

### Метка для каждого типа пакета

Источник всех строк - страница [«Package types»](https://modelcontextprotocol.io/registry/package-types).

| `registryType` | Допустимый реестр | Метка владения |
|---|---|---|
| `npm` | только `https://registry.npmjs.org` | поле `mcpName` в `package.json` |
| `pypi` | только `https://pypi.org` | строка `mcp-name: имя-сервера` в README; может быть в скрытом комментарии |
| `nuget` | только `https://api.nuget.org/v3/index.json` | строка `mcp-name: имя-сервера` в README; может быть в скрытом комментарии |
| `cargo` | только `https://crates.io` | строка `mcp-name: имя-сервера` в README видимым текстом |
| `oci` | Docker Hub, GHCR, Google Artifact Registry, Azure Container Registry, Microsoft Container Registry | аннотация `io.modelcontextprotocol.server.name` в образе |
| `mcpb` | выпуски GitHub или GitLab | метки нет; адрес обязан содержать строку `mcp`, в записи обязано быть поле `fileSha256` |

Три замечания к таблице.

**Cargo.** crates.io вырезает комментарии HTML при показе README. Скрытая строка, которая годится для PyPI и NuGet, здесь не сработает: метку нужно писать видимым текстом.

**OCI.** Аннотацию задают в Dockerfile, например: `LABEL io.modelcontextprotocol.server.name="io.github.username/kubernetes-manager-mcp"`.

**MCPB.** Владение не проверяется. Хеш `fileSha256` реестр не сверяет - по документации его сверяют клиенты перед установкой.

Опубликованная страница [«Package types»](https://modelcontextprotocol.io/registry/package-types) называет пять реестров образов, и Quay среди них нет. Документ в репозитории реестра [«Official registry requirements»](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/official-registry-requirements.md) в ветке `main` добавляет к списку Quay.io. В коде службы на метке выпуска `v1.8.1` узел `quay.io` стоит в списке разрешённых ([`oci.go`](https://github.com/modelcontextprotocol/registry/blob/v1.8.1/internal/validators/registries/oci.go)), а работающая служба 4 октября 2026 отвечала версией `1.8.1`. То есть отстаёт опубликованная страница, а не служба.

## Шаг 2. Публикация пакета

Соберите пакет и выложите его средствами реестра пакетов. Для npm руководство приводит такие команды:

```bash title="Публикация в npm"
# If necessary, authenticate to npm
npm adduser

# Publish the package
npm publish --access public
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался.

Правила самого npm - области имён, права, метки версий - описаны в [документации npm](https://docs.npmjs.com/creating-and-publishing-scoped-public-packages). Правилами MCP они не являются.

## Шаг 3. Установка `mcp-publisher`

`mcp-publisher` - официальная программа командной строки для публикации в реестр. Руководство предлагает готовый двоичный файл или Homebrew:

```bash title="macOS и Linux"
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher && sudo mv mcp-publisher /usr/local/bin/
```

```bash title="Homebrew"
brew install mcp-publisher
```

Примеры взяты из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускались.

Команда для Windows приведена в [том же руководстве](https://modelcontextprotocol.io/registry/quickstart).

## Шаг 4. Файл `server.json`

```bash title="Создание заготовки"
mcp-publisher init
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался.

Команда создаёт заготовку `server.json` и подставляет то, что смогла определить по проекту. По [справке по командам](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/cli/commands.md) она не задаёт вопросов и не принимает параметров, а для полей, которые определить не удалось, пишет пометки `TODO:`.

Заготовку нужно проверить руками: имя, версию пакета, описание не длиннее 100 знаков. Поля и ограничения разобраны на странице [«server.json, имена и проверка владения»](https://mcpdoc.ru/registry/server-json/).

В той же справке есть команда `mcp-publisher validate`, которая проверяет файл без публикации. В выводе `--help` из руководства её нет.

## Шаг 5. Вход

Способ входа определяет, какое пространство имён вам доступно.

| Команда | Для чего | Пространство имён |
|---|---|---|
| `mcp-publisher login github` | вход с подтверждением в браузере | `io.github.*` |
| `mcp-publisher login github-oidc` | вход из GitHub Actions | `io.github.*` |
| `mcp-publisher login dns` | подтверждение записью TXT | домен в обратной записи |
| `mcp-publisher login http` | подтверждение файлом на домене | домен в обратной записи |
| `mcp-publisher login none` | без проверки, только для локальных испытаний | - |

При обычном входе через GitHub программа печатает код и просит ввести его на странице `github.com/login/device`:

```bash title="Вход через GitHub"
mcp-publisher login github
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался.

## Шаг 6. Публикация записи

```bash title="Публикация в реестре MCP"
mcp-publisher publish
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался.

Проверить результат руководство предлагает запросом к API:

```bash title="Проверка"
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.my-username/weather"
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался.

Типичные отказы из того же руководства:

| Сообщение | Что делать |
|---|---|
| `Registry validation failed for package` | в пакете нет метки владения, например `mcpName` |
| `Invalid or expired Registry JWT token` | войти заново |
| `You do not have permission to publish this server` | имя сервера не соответствует способу входа |

## Публикация из GitHub Actions

Документация называет вход по OIDC [рекомендуемым способом](https://modelcontextprotocol.io/registry/github-actions) для GitHub Actions: отдельный секрет для реестра MCP при нём не нужен. Сценарий с той же страницы:

```yaml title=".github/workflows/publish-mcp.yml"
name: Publish to MCP Registry

on:
  push:
    tags: ["v*"] # Triggers on version tags like v1.0.0

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # Required for OIDC authentication
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v5

      ### Publish underlying npm package:

      - name: Set up Node.js
        uses: actions/setup-node@v5
        with:
          node-version: "lts/*"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm run test --if-present

      - name: Build package
        run: npm run build --if-present

      - name: Publish package to npm
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

      ### Publish MCP server:

      - name: Install mcp-publisher
        run: |
          curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher

      - name: Authenticate to MCP Registry
        run: ./mcp-publisher login github-oidc

      - name: Publish server to MCP Registry
        run: ./mcp-publisher publish
```

Пример взят из официальной документации реестра (прочитана 4 октября 2026) и здесь не запускался. Необязательный закомментированный шаг с подстановкой версии опущен.

Что здесь важно:

- разрешение `id-token: write` обязательно для входа по OIDC;
- секрет `NPM_TOKEN` нужен для npm, к реестру MCP он не относится;
- порядок шагов тот же, что и вручную: сначала пакет, потом запись.

Там же описаны два других варианта: вход по личному токену GitHub с правами `read:org` и `read:user` и вход по DNS с закрытым ключом в секрете.

## Что реестр проверяет и чего не проверяет

По [справке по командам](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/cli/commands.md) публикация проходит так: программа сверяет файл со схемой, служба проверяет владение пакетом, затем право на пространство имён.

| Проверяется | Не проверяется |
|---|---|
| соответствие `server.json` схеме | безопасность кода сервера |
| право издателя на пространство имён | работает ли сервер и делает ли заявленное |
| метка владения в пакете (кроме `mcpb`) | хеш файла MCPB |
| новизна строки версии | качество: слабые и повторяющиеся серверы не удаляются |

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

## Версии

Правила - со страницы [«Versioning»](https://modelcontextprotocol.io/registry/versioning).

- Каждая публикация обязана иметь новую строку версии.
- Опубликованную версию изменить нельзя. Чтобы обновить метаданные, публикуют новую версию.
- Диапазоны вроде `^1.2.3` или `1.x` в строке версии запрещены.
- Семантические версии рекомендованы, но не обязательны.

## Удаление: документы говорят по-разному

Здесь официальные источники расходятся, поэтому приводим оба.

| Источник | Что сказано |
|---|---|
| [FAQ реестра](https://modelcontextprotocol.io/registry/faq) | на вопрос, можно ли удалить или отозвать сервер, ответ: «сейчас нет», идёт обсуждение |
| [Справка по командам](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/cli/commands.md) | есть команда `mcp-publisher status --status` со значениями `active`, `deprecated`, `deleted`; `deleted` означает, что сервер скрыт из обычных списков |
| [Описание общего API](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/generic-registry-api.md) | запрос `DELETE` для версии сервера назван необязательным и не реализованным в официальном реестре |
| [Страница для агрегаторов](https://modelcontextprotocol.io/registry/registry-aggregators) | метаданные в целом неизменяемы, кроме поля `status`, которое может стать `deprecated` или `deleted` |

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

Проверьте `server.json` до публикации. Не кладите в запись секреты и внутренние адреса. По [правилам модерации](https://modelcontextprotocol.io/registry/moderation-policy) даже удалённая модераторами запись получает статус `deleted`, но её метаданные остаются доступны через API.

## Чего реестр не поддерживает

- **Закрытые серверы.** Документация прямо говорит, что [реестр их не поддерживает](https://modelcontextprotocol.io/registry/about). Удалённый сервер из раздела `remotes` обязан быть общедоступен по своему адресу.
- **Закрытые реестры пакетов.** Для каждого типа пакета принимается только названный общий реестр.
- **Размещение у себя.** Код реестра не рассчитан на собственную установку, и сопровождающие такую установку не поддерживают.

Для внутренних серверов организации используют закрытые реестры. Они перечислены на странице [«Каталоги и хабы»](https://mcpdoc.ru/registry/catalogs/).

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

- [server.json, имена и проверка владения](https://mcpdoc.ru/registry/server-json/) - поля записи и правила имён.
- [Официальный реестр MCP](https://mcpdoc.ru/registry/) - статус службы и версии API.
- [Каталоги и хабы](https://mcpdoc.ru/registry/catalogs/) - куда запись попадает дальше.
- [Развёртывание в Docker](https://mcpdoc.ru/deployment/docker/) - если сервер распространяется образом.