Managing MCPs

MCP Hub supports multiple methods for registering MCP servers into the certification pipeline. Once registered, each MCP is automatically monitored for new commits, analyzed for security vulnerabilities, scored, and – if it passes – certified and published to the registry.

Adding MCP Servers

MCP Hub supports four ingestion source types, giving publishers flexibility in how they submit MCP servers for certification.

From a Git Repository (Default)

The most common method is registering a Git repository URL. The platform’s scheduler service automatically polls the repository for new commits on the configured branch.

From the dashboard, click Add MCP and provide:

• Name: A unique name for the MCP server (up to 255 characters).
• Repository URL: The full Git URL (e.g., https://github.com/org/mcp-server).
• Branch: The branch to monitor (defaults to main).
• Visibility: public (visible in the catalog) or private (PRO/Enterprise only).
• Area (optional): Assign the MCP to an organizational area (Enterprise only).

Once registered, the scheduler polls the repository according to its configured interval (daily by default, configurable for Enterprise). When a new commit is detected on the monitored branch, the platform automatically creates a new version and begins the certification pipeline.

Via Git Webhooks

For real-time ingestion without waiting for the next polling cycle, configure a Git webhook in your repository provider:

• GitHub: Point the webhook at POST /api/v1/webhooks/github
• GitLab: Point the webhook at POST /api/v1/webhooks/gitlab
• Bitbucket: Point the webhook at POST /api/v1/webhooks/bitbucket

Webhook payloads are verified using HMAC-SHA256 signatures (GitHub, Bitbucket) or token comparison (GitLab) to prevent spoofing. When a push event is received, the platform immediately triggers ingestion for the new commit.

Via Direct Upload

Publishers who do not use Git can upload source bundles directly using the CLI or API:

# Initialize upload session
curl -X POST https://hub.mcp-hub.info/api/v1/uploads/init \
  -H "Authorization: Bearer <token>" \
  -d '{"mcp_name":"my-mcp","mcp_version":"1.0.0","bundle_digest":"sha256:..."}'

# Upload bundle to the returned presigned URL
curl -X PUT "<presigned-url>" --upload-file bundle.tar.gz

# Finalize the upload
curl -X POST https://hub.mcp-hub.info/api/v1/uploads/<id>/finalize

The platform verifies the SHA-256 digest during finalization to ensure the uploaded bundle was not corrupted or tampered with.

Via Remote URL (Future)

A planned ingestion source for pre-built artifacts available at HTTPS URLs. Only HTTPS URLs are accepted, and requests to private networks are blocked.

Viewing MCP Details

Each registered MCP has a detail page showing:

• Metadata: Name, description, repository URL, branch, language, and detected license.
• Status: Current status (ACTIVE, INACTIVE, or PENDING).
• Visibility: Whether the MCP is public or private.
• Latest Version: The most recent certified version with its global score.
• Version History: A chronological list of all versions with their statuses and scores.
• Polling Status: When the repository was last polled and when the next poll is scheduled.
• Owner: The user or organization that owns this MCP.
• Area: The organizational area this MCP belongs to (if any).

MCP Status Values

Version History

Every time a new commit is detected on the monitored branch, MCP Hub creates a new version. Each version is identified by its commit hash and displayed with a human-readable identifier:

commit-a3f91c2-2026-01-12

This format combines the short commit hash with the date, giving each version a unique and recognizable name. If the repository has Git tags, they are shown as aliases mapped to the underlying commit hash.

Version Statuses

Versions progress through a lifecycle as they move through the certification pipeline:

Triggering Re-Analysis

There are scenarios where you may want to re-analyze an existing version:

• The analysis toolchain has been updated with new detection capabilities.
• The vulnerability feeds have been refreshed with new CVE data.
• The controls catalog or scoring methodology has been updated.

Re-analysis creates a new snapshot for the existing version without overwriting the previous one. This preserves the full audit trail of how the version’s security posture was assessed over time.

To trigger re-analysis from the dashboard, navigate to the version detail page and click Re-analyze. This creates a REEVALUATE_VERSION job in the processing queue.

Re-analysis uses the latest versions of:

• The analysis toolchain (MCP-Scan and optional Trivy for SBOM)
• The scoring algorithm
• The controls catalog mapping

The new snapshot references the previous one, creating a chain of assessments for auditability.

Viewing Security Snapshots

Each certified version has at least one immutable security snapshot. A snapshot captures the complete security assessment at a specific point in time and includes:

• Scores: Global Score, Security Score, Supply Chain Score, and Maturity Score (each 0-100).
• Findings Summary: Total count of findings broken down by severity (critical, high, medium, low).
• Control Results: The outcome of each security control check (passed or failed), with evidence references.
• Toolchain Metadata: The exact versions of all analysis tools used, ensuring reproducibility.
• Scoring and Catalog Versions: Which version of the scoring algorithm and controls catalog was applied.

Snapshots are immutable – they are never updated after creation. If a version needs to be re-assessed, a new snapshot is created and linked to the previous one via the previous_snapshot_id field.

Navigating Snapshots

From the version detail page, you can view the latest snapshot or browse the history of all snapshots for that version. Each snapshot shows:

• When it was created.
• Which toolchain versions were used.
• How scores compare to the previous snapshot.
• Which controls passed or failed, with detailed evidence.

This snapshot chain provides complete traceability for compliance audits and security reviews.