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

MCP Registry - официальный каталог метаданных о публично доступных MCP-серверах по адресу registry.modelcontextprotocol.io. Код он не хранит: каждая запись - документ server.json, который называет сервер, описывает его и указывает, где его взять: в реестре пакетов, например npm или PyPI, или по адресу удалённого сервера. Опубликовать сервер - значит отправить его server.json в реестр утилитой командной строки mcp-publisher, предварительно подтвердив право на имя сервера.

Реестр появился в феврале 2025 года как проект сообщества: авторы MCP David Soria Parra и Justin Spahr-Summers попросили команды PulseMCP и Goose помочь построить общий реестр. В режиме предварительной версии (preview) он запущен 8 сентября 2025 года. Реестр развивает рабочая группа Registry Working Group проекта MCP.

По состоянию на ноябрь 2026 года документация всё ещё помечает реестр как предварительную версию: до общей доступности возможны несовместимые изменения и сброс данных. Версия API v0.1 заморожена с 24 октября 2025 года, текущая опубликованная версия схемы server.json - 2025-12-11. Базовые понятия протокола описаны в статье Что такое MCP.

Кратко

Какую задачу решает

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

Анонс реестра описывает его цель как стандартизацию того, как серверы распространяются и находятся. Реестр задуман как первичный источник истины: единое место, где авторы сервера публикуют сведения о нём от своего имени. Другие каталоги, субреестры (subregistries), берут данные оттуда и добавляют свои: отбор, оценки, проверки безопасности.

Кроме того, реестр привязывает каждое имя к подтверждённой учётной записи GitHub или домену, поэтому сервер нельзя опубликовать под чужим именем. Пакет, на который указывает запись, должен сам называть этот сервер, поэтому метаданные не могут присвоить чужой пакет.

История

В таблице - запуск реестра и основные изменения его API и схемы server.json.

Место в экосистеме

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

Package registries (npm, PyPI, NuGet, crates.io, Docker Hub, GitHub Releases)
 |  code and binaries
 v
MCP Registry (registry.modelcontextprotocol.io)
 |  server.json metadata, REST API v0.1
 v
Subregistries and marketplaces (public or private)
 |  curation, ratings, security scans, same API
 v
Host applications (AI applications that install and connect servers)

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

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

Формат server.json

Поля

server.json - JSON-документ, который описывает JSON Schema. Адрес схемы содержит её версию, а документ ссылается на неё в поле $schema. Основные поля:

В записи пакета обязательны registryType, identifier и transport. Тип транспорта пакета - stdio, streamable-http или sse. Пакет может также описывать, как его запускать: runtimeHint, runtimeArguments, packageArguments и environmentVariables, где у каждой переменной есть name, description, isRequired и isSecret.

Пример

Пример описывает сервер, который распространяется npm-пакетом и одновременно доступен как удалённый сервер:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.example-user/weather",
  "title": "Weather",
  "description": "Current weather and forecasts for any city.",
  "version": "1.2.0",
  "repository": {
    "url": "https://github.com/example-user/mcp-weather-server",
    "source": "github"
  },
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@example-user/mcp-weather-server",
      "version": "1.2.0",
      "transport": {
        "type": "stdio"
      },
      "environmentVariables": [
        {
          "name": "WEATHER_API_KEY",
          "description": "API key of the weather data provider",
          "isRequired": true,
          "isSecret": true
        }
      ]
    }
  ],
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://weather.example.com/mcp"
    }
  ]
}

Метаданные публикующего

Поле _meta использует ключи в обратной DNS-нотации. Официальный реестр сохраняет только данные под ключом io.modelcontextprotocol.registry/publisher-provided, а остальные ключи молча отбрасывает. Объём этих данных ограничен 4096 байтами JSON; при большем объёме публикация не проходит.

Свои метаданные реестр добавляет в ответах API, вне server.json, под ключом io.modelcontextprotocol.registry/official: статус, даты публикации и обновления, флаг isLatest. Публикующий эти поля задать не может.

Пространства имён

Имя сервера состоит из пространства имён и имени сервера в нём, разделённых /. Пространство имён записывается в обратной DNS-нотации: части домена в обратном порядке. Способ аутентификации определяет, какие пространства имён доступны публикующему.

Аутентификация через GitHub всегда даёт личное пространство имён. Для пространства организации нужна роль Owner в этой организации; обычного членства недостаточно. По состоянию на ноябрь 2026 года документация отмечает, что вход через mcp-publisher login github не позволяет публиковать в пространство организации, а вход через OIDC или с персональным токеном доступа позволяет.

Пространство имён домена подтверждается через DNS или HTTP. В коде реестра проверка через DNS даёт права на домен и все его поддомены, а проверка через HTTP - только на сам домен. Домен github.io и его поддомены нельзя использовать с проверкой через DNS или HTTP: пространства io.github.* доступны только через аутентификацию GitHub.

Подтверждение владения

Перед публикацией публикующий входит в реестр командой mcp-publisher login и получает токен реестра. Способ входа подтверждает право на пространство имён.

• GitHub OAuth. mcp-publisher login github запускает вход с кодом устройства (device flow): пользователь открывает https://github.com/login/device и вводит код, который напечатан в терминале. С параметром --token вместо этого используется персональный токен доступа.
• GitHub OIDC. mcp-publisher login github-oidc используется в GitHub Actions. Рабочему процессу нужно право id-token: write, отдельный секрет не нужен.
• DNS. Публикующий создаёт пару ключей (Ed25519 или ECDSA P-384) и публикует открытый ключ в TXT-записи на вершине домена (apex), а не под селектором вроде _mcp-auth. Команда входа подписывает метку времени закрытым ключом.
• HTTP. Та же запись, v=MCPv1; k=ed25519; p=<public key>, отдаётся файлом по адресу https://<domain>/.well-known/mcp-registry-auth. Реестр забирает его со своей инфраструктуры, не следует перенаправлениям и ждёт статус 200 не дольше 10 секунд.

Проверка через DNS с ключом Ed25519 по документации реестра:

MY_DOMAIN="example.com"

# Generate an Ed25519 key pair
openssl genpkey -algorithm Ed25519 -out key.pem

# Print the TXT record to add at the apex of the domain
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "${MY_DOMAIN}. IN TXT \"v=MCPv1; k=ed25519; p=${PUBLIC_KEY}\""

# After the record has propagated, log in with the private key
PRIVATE_KEY="$(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login dns --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"

Закрытый ключ может храниться и в Google Cloud KMS или Azure Key Vault; для обоих у mcp-publisher есть свои варианты входа.

Проверка пакетов

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

Для npm-пакета маркер выглядит так:

{
  "name": "@example-user/mcp-weather-server",
  "version": "1.2.0",
  "mcpName": "io.github.example-user/weather"
}

Для образа OCI аннотация задаётся инструкцией LABEL в Dockerfile, например LABEL io.modelcontextprotocol.server.name="io.github.example-user/weather". Хеш файла MCPB реестр не проверяет; по документации, его проверяют MCP-клиенты перед установкой.

Принимаются только эти публичные реестры. Закрытые реестры пакетов и зеркала официальный реестр не поддерживает.

Удалённые серверы

Удалённый сервер описывается в массиве remotes. Такой записи не нужен packages, и проверка пакетов к ней не применяется. URL должен быть публично доступен.

• Транспорт. type - streamable-http или sse. Документация рекомендует Streamable HTTP, а SSE называет устаревшим и советует публиковать только для существующих клиентов.
• Переменные URL. URL может содержать переменные в фигурных скобках, например https://{tenant_id}.analytics.example.com/mcp, с описанием, значением по умолчанию и списком вариантов в variables. Значения пользователь задаёт при настройке сервера.
• Заголовки. headers перечисляет HTTP-заголовки, которые клиент должен отправлять, например ключ API, с флагами isRequired и isSecret.

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

Публикация через mcp-publisher

mcp-publisher устанавливается готовым бинарным файлом из релизов репозитория modelcontextprotocol/registry или через Homebrew. Его команды:

Обычная публикация сервера на основе npm-пакета состоит из публикации пакета, а затем его метаданных:

# The package goes to npm first: the registry stores only metadata
npm publish --access public

# Create and check server.json
mcp-publisher init
mcp-publisher validate

# Log in with GitHub and publish
mcp-publisher login github
mcp-publisher publish

При публикации реестр проверяет документ, сверяет пространство имён с токеном и проверяет владение каждым пакетом.

Публикацию можно автоматизировать в GitHub Actions. Документация рекомендует OIDC, фиксацию конкретного релиза mcp-publisher и проверку его подписи Sigstore перед использованием. Запуск тестов в таких процессах описан в статье Автотесты в CI.

Версии и статусы

У каждой публикации своя version, уникальная для сервера. Опубликованную версию изменить нельзя: чтобы исправить метаданные, публикуется новая версия. Реестр рекомендует семантическое версионирование, но принимает любую строку, кроме похожих на диапазоны, например ^1.2.3, ~1.2.3, >=1.2.3 или 1.x.

Последней (isLatest) реестр отмечает версию, сравнивая семантические версии. Версия, которую нельзя разобрать как семантическую, всегда отмечается последней. Чтобы изменить только метаданные без нового пакета, она советует предварительную версию вида 1.2.3-1; такая версия при сортировке стоит раньше 1.2.3 и не становится последней, если опубликована после неё.

Статус версии - единственное поле, которое меняется после публикации:

Метаданные никогда не удаляются полностью. Сервер со статусом deleted можно восстановить, вернув статус active.

API реестра

API официального реестра открыт для чтения без аутентификации. Основные эндпоинты:

Имена серверов в пути кодируются для URL: io.github.example-user%2Fweather. Список выдаётся постранично по курсору: ответ содержит metadata.nextCursor, который передаётся как cursor в следующем запросе. version=latest возвращает только последнюю версию каждого сервера. updated_since с меткой времени в формате RFC 3339 возвращает серверы, изменённые с этого момента, и служит для инкрементальной синхронизации.

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

Субреестры и закрытые реестры

Реестр определяет спецификацию OpenAPI своего API. Субреестр - агрегатор, который реализует эту спецификацию, поэтому хост-приложения читают его так же, как официальный реестр. Субреестр может добавлять свои метаданные, например оценки, число загрузок или результаты сканирования, под собственным ключом в _meta, например com.example.subregistry/custom.

Закрытые реестры компаний реализуют ту же спецификацию для своих внутренних серверов. В спецификации эндпоинты публикации необязательны, и реестр может быть только для чтения. Реестр, которому нужна аутентификация, следует спецификации авторизации MCP и выступает сервером ресурсов OAuth 2.1; рекомендуемые права - mcp-registry:read и mcp-registry:write. Сам официальный реестр для публикации использует собственные токены на основе JWT.

Код официального реестра открыт, но, по его документации, не рассчитан на самостоятельное развёртывание, и сопровождающие такой вариант не поддерживают. Организация, которая делает форк, сопровождает и эксплуатирует его сама.

Модерация

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

Реестр не удаляет низкокачественные серверы и серверы с ошибками, серверы с уязвимостями, дубли других серверов и серверы с контентом для взрослых. Политика указывает, что реестр не даёт гарантий модерации и полагается на реестры пакетов и субреестры для более глубоких проверок. Снятый с публикации сервер получает статус deleted, а его метаданные остаются доступны через API; в исключительных случаях, например при незаконных метаданных, их могут перезаписать или стереть. О злоупотреблениях сообщают в реестр пакетов и в issue репозитория реестра с заголовком, который начинается с «Abuse report:».

Реестр, реестры пакетов и субреестры

Таблица сравнивает MCP Registry с двумя видами систем, с которыми он работает.

MCP Registry не заменяет реестр пакетов. Пакет сначала публикуется в своём реестре, и MCP Registry на него ссылается. Маркеры владения связывают их: пакет называет сервер, а сервер называет пакет.

Субреестр не заменяет и MCP Registry: он берёт оттуда данные и применяет свой отбор. Тестирование сервера перед публикацией описано в статье Тестирование MCP-серверов, а регрессионные проверки между версиями - в статье Регрессионное тестирование MCP-сервера.

Термины

Источники

• The MCP Registry, modelcontextprotocol.io(откроется в новой вкладке) (на английском)
• Quickstart: Publish an MCP Server to the MCP Registry(откроется в новой вкладке) (на английском)
• How to Authenticate When Publishing to the Official MCP Registry(откроется в новой вкладке) (на английском)
• MCP Registry Supported Package Types(откроется в новой вкладке) (на английском)
• Publishing Remote Servers(откроется в новой вкладке) (на английском)
• Versioning Published MCP Servers(откроется в новой вкладке) (на английском)
• How to Automate Publishing with GitHub Actions(откроется в новой вкладке) (на английском)
• MCP Registry Aggregators(откроется в новой вкладке) (на английском)
• The MCP Registry Moderation Policy(откроется в новой вкладке) (на английском)
• Frequently Asked Questions, MCP Registry(откроется в новой вкладке) (на английском)
• Репозиторий MCP Registry, GitHub(откроется в новой вкладке) (на английском)
• Server JSON Schema Changelog, GitHub(откроется в новой вкладке) (на английском)
• Official Registry server.json Requirements, GitHub(откроется в новой вкладке) (на английском)
• Publisher CLI Commands Reference, GitHub(откроется в новой вкладке) (на английском)
• Generic Registry API Specification, GitHub(откроется в новой вкладке) (на английском)
• Registry Authorization, GitHub(откроется в новой вкладке) (на английском)
• Introducing the MCP Registry, блог MCP, 8 сентября 2025(откроется в новой вкладке) (на английском)