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

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

Это разделение задано документацией: реестр MCP хранит только метаданные, не сами пакеты. Поэтому пакет нужно выложить до публикации записи.

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

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

Ниже путь показан на пакете npm, как в официальном руководстве. Для других типов пакетов меняются только шаги 2 и 3.

Реестр проверяет, что пакет действительно относится к серверу с таким именем. Для npm в package.json добавляют поле mcpName. Пример со страницы «Package types»:

{
  "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».

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

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

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

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

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

# If necessary, authenticate to npm
npm adduser

# Publish the package
npm publish --access public

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

Правила самого npm - области имён, права, метки версий - описаны в документации npm. Правилами MCP они не являются.

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

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/

brew install mcp-publisher

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

Команда для Windows приведена в том же руководстве.

mcp-publisher init

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

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

Заготовку нужно проверить руками: имя, версию пакета, описание не длиннее 100 знаков. Поля и ограничения разобраны на странице «server.json, имена и проверка владения».

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

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

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

mcp-publisher login github

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

mcp-publisher publish

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

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

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.my-username/weather"

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

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

Документация называет вход по OIDC рекомендуемым способом для GitHub Actions: отдельный секрет для реестра MCP при нём не нужен. Сценарий с той же страницы:

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 с закрытым ключом в секрете.

По справке по командам публикация проходит так: программа сверяет файл со схемой, служба проверяет владение пакетом, затем право на пространство имён.

Проверку кода документация оставляет другим: реестрам пакетов и последующим агрегаторам. О модерации сказано, что потребителям следует исходить из того, что она минимальна или отсутствует.

Правила - со страницы «Versioning».

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

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

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

• Закрытые серверы. Документация прямо говорит, что реестр их не поддерживает. Удалённый сервер из раздела remotes обязан быть общедоступен по своему адресу.
• Закрытые реестры пакетов. Для каждого типа пакета принимается только названный общий реестр.
• Размещение у себя. Код реестра не рассчитан на собственную установку, и сопровождающие такую установку не поддерживают.

Для внутренних серверов организации используют закрытые реестры. Они перечислены на странице «Каталоги и хабы».

• server.json, имена и проверка владения - поля записи и правила имён.
• Официальный реестр MCP - статус службы и версии API.
• Каталоги и хабы - куда запись попадает дальше.
• Развёртывание в Docker - если сервер распространяется образом.