Publishing to Registry

After an MCP server passes through the certification pipeline and receives a score, MCP Hub publishes the certified artifact to mcp-registry. The registry is the distribution layer that makes certified MCPs available for download by end users via mcp-client or standard package managers.

What Gets Published

When an MCP version is certified, two components are published to the registry:

1. Manifest

The manifest is a JSON document that describes the certified MCP version. It contains:

• MCP metadata: Name, description, version identifier, repository URL, language, and license.
• Certification data: Certification level (0-3), global score, and origin type (Official, Verified, Community).
• Snapshot summary: Security Score, Supply Chain Score, Maturity Score, and findings counts by severity.
• Bundle reference: The SHA-256 digest of the source bundle, used for content-addressed retrieval.
• Toolchain metadata: Versions of all analysis tools, scoring algorithm, and controls catalog used during certification.

The manifest acts as the “label” for the package – it tells consumers everything they need to know about the MCP’s certification status before downloading the actual source.

2. Bundle

The bundle is a compressed tarball (.tar.gz) containing the MCP server’s source code at the exact commit that was certified. The bundle is the same tarball that was analyzed during the certification pipeline, ensuring that what was analyzed is exactly what gets distributed.

Each bundle is identified by its SHA-256 digest, providing content-addressed storage and integrity verification.

Content Addressing

MCP Hub uses SHA-256 content addressing throughout the publication and distribution pipeline:

How It Works

1. During ingestion, the source tarball is created and its SHA-256 digest is computed.
2. The digest is stored alongside the version record as tarball_sha256.
3. When the artifact is published to the registry, the same digest is included in the manifest.
4. When a client downloads the bundle, it can verify the digest to confirm the bundle has not been tampered with.

Why Content Addressing Matters

• Integrity: Any modification to the bundle – intentional or accidental – changes the digest, making tampering detectable.
• Immutability: Once published, a bundle with a specific digest cannot be replaced with different content. A new version must be created instead.
• Reproducibility: The same commit hash will always produce the same source tarball with the same digest (given deterministic archiving).
• Trust chain: The digest links the analysis results (snapshot) to the exact source code that was analyzed, and to the exact bundle that is distributed.

The Publishing Process

Publishing happens automatically as the final phase of the certification pipeline, executed by the PUBLISH_TO_REGISTRY job.

Step-by-Step

1. Load certification data: The hub-worker loads the snapshot, version, and MCP records from the database.

2. Map score to certification level: The global score is mapped to a certification level:

   Global Score	Certification Level
   0-59	Level 0 (Integrity Verified)
   60-79	Level 1 (Static Verified)
   80-89	Level 2 (Security Certified)
   90-100	Level 3 (Runtime Certified)

3. Generate manifest: A manifest document is constructed from the snapshot data, including all scores, findings counts, toolchain versions, and the bundle digest.

4. Call registry API: The hub-worker makes an authenticated API call to the registry’s publish endpoint using a service token (REGISTRY_SERVICE_TOKEN). The service token is a JWT with the admin:publish scope.

5. Upload bundle: If the bundle is not already present in the registry’s storage (checked by digest), it is uploaded.

6. Update version record: The version record in the hub database is updated with the registry URL and publication status.

Registry Namespaces

Published MCPs are organized into namespaces that determine access control:

Public Namespace

Public MCPs are published to the public namespace and are available to all users:

registry.mcp-hub.info/npm/public/mcp-database-tools

Public MCPs are rate-limited by IP for anonymous users and by token/user for authenticated users.

Organization Namespace

MCPs belonging to Enterprise organizations are published under the organization’s namespace:

acme.registry.mcp-hub.info/npm/org/acme/mcp-internal-tools

Organization MCPs require authentication and are subject to the organization’s governance policies (allow/deny lists, score thresholds).

Hub-to-Registry Authentication

Communication between MCP Hub and mcp-registry is authenticated using service tokens:

• Token type: JWT (JSON Web Token) with specific scopes.
• Configuration: The REGISTRY_SERVICE_TOKEN environment variable holds the pre-shared token.
• Scopes: The service token requires admin:publish scope to publish artifacts.
• Security: The token is never logged or exposed in API responses. It is used only for server-to-server communication.

Version Naming in the Registry

MCPs in the registry use the same version naming convention as MCP Hub:

mcp-database-tools@commit-a3f91c2-2026-01-12

If the repository has Git tags, those tags are recorded as aliases. The registry supports resolution by both the visible version string and the underlying commit hash.

What Does Not Get Published

The following data remains in MCP Hub and is not published to the registry:

• Detailed findings: The full findings JSON with individual vulnerability details stays in S3, accessible only through the hub dashboard and API.
• Control results: Detailed control pass/fail results and evidence references stay in the hub database.
• Job history: Ingestion and analysis job records are internal to the hub.
• Organization policies: Governance policies are evaluated at download time but are not published as part of the artifact.
• Audit events: Download and access logs are recorded by the registry independently.

The registry receives only the summary data needed for distribution: the manifest (with scores and certification level) and the bundle (the source tarball).

Re-Publication

When a version is re-evaluated and receives a new snapshot, the re-evaluation may produce a different score and certification level. In this case:

• The bundle does not change – it is the same source code at the same commit.
• The manifest is updated with the new scores, certification level, and snapshot reference.
• The previous manifest data is preserved in the hub’s snapshot history for auditability.

This ensures that the registry always reflects the most current assessment while the hub maintains the full history of all assessments.