Skip to content
MCP Gateway

Register an MCP Server

Govern

Register an MCP Server

Section titled “Register an MCP Server”

MCP server governance starts with a submitted manifest and ends only when an approved snapshot is projected to runtime. Pending and rejected submissions are review history. Approved snapshots are immutable runnable records. Discovery is still policy-filtered after approval.

Audience

Section titled “Audience”
  • MCP server owners submitting a private server for governance.
  • Platform reviewers approving or rejecting submissions.
  • Security reviewers checking hidden tools, self-approval denial, and metadata-only review state.

What is this?

Section titled “What is this?”

This is the public workflow for the MCP server registry. V1 registers remote governed MCP servers. It does not host MCP servers, govern arbitrary local stdio endpoints, publish a public marketplace, or expose unauthorized tools by default.

The registry separates three objects:

  • Submission: immutable owner-submitted manifest addressed by submission_id and manifest_hash.
  • Approved snapshot: immutable runnable manifest addressed by snapshot_id.
  • Current registry row: mutable pointer with live snapshot, latest submission, pending submission, health, registration status, and catalog visibility.

When do I use it?

Section titled “When do I use it?”

Use this when a team wants an existing MCP server to become an approved enterprise capability. The server owner submits the manifest. A platform or security reviewer validates owner, risk, transport, credential mode, policy refs, tools, health, and audit posture before approving.

Choose No credential only for a public MCP endpoint that accepts anonymous requests. The gateway still requires source approval and an explicit allow policy, but it skips credential binding and sends no credential upstream.

What happens?

Section titled “What happens?”
  1. Initial POST /v1/mcp-servers creates the first immutable submission and pending review state.
  2. Later revisions use POST /v1/mcp-servers/{server_id}/submissions.
  3. A reviewer approves or rejects the exact submission_id plus manifest_hash.
  4. Approval creates a new approved snapshot and may update the live pointer.
  5. Rejection preserves the live snapshot when one exists. Initial rejection leaves no callable live snapshot.
  6. Versions list approved snapshots only.
  7. Compare endpoints compare backend-owned snapshots or pending submission against the live snapshot. UI clients do not diff manifests locally.
  8. Catalog-lite discovery returns only approved, healthy enough, policy-authorized capabilities.

Review permissions are explicit. platform_admin, security_admin, break_glass_admin, or scoped registry_reviewer can review. Owners cannot approve or reject their own submissions. Batch approval is approve-only and skips ineligible records.

What can go wrong?

Section titled “What can go wrong?”
  • A newer pending submission makes an older review request stale with 409 stale_submission.
  • Changed review content returns 409 manifest_hash_mismatch.
  • Self-approval returns a denied result.
  • Disabled, archived, rejected, unhealthy route-blocked, unapproved, or policy-denied servers do not become discoverable tools.
  • Denied mutations return 403 permission_denied with a sanitized message and metadata-only admin audit.
  • Manifest bodies, validation errors, change pointers, and UI logs must not carry tokens, headers, credentials, or secret material.

Source truth

Section titled “Source truth”

Next

Section titled “Next”

Type set in Geist, Source Serif 4, and Departure Mono.