MCP Registry overview

The Brutor MCP Registry is a standalone registry server for Model Context Protocol servers — the answer to “which MCP servers exist, which are ours, and which are actually governed?” It implements the official MCP Registry specification (server.json 2025-12-11, served under the /v0.1 API), so any spec-compliant MCP client or tool can consume it directly.

It plays a different role from the gateway: the gateway enforces what a governed client may call; the registry is the catalog — discovery, publication and inventory. Together they close the loop: find a server in the registry, register it in the gateway, and its record flips to governed.

A governed enterprise subregistry

Three things distinguish it from pointing your tooling at the public registry:

• Federation. A scheduled aggregator pulls upstream registries — the official MCP Registry and any others you connect — and serves their records alongside your own, incrementally, with tombstone propagation and opaque-cursor pagination. One registry endpoint covers both the world’s servers and the internal ones that must never leave the building.
• Publication. Teams publish internal MCP servers with JWT-authenticated publishing, automatic server.json validation, version immutability, and namespace verification — GitHub OAuth for io.github.* namespaces, DNS TXT or HTTPS well-known challenges for domain namespaces.
• Governance posture. Every served record carries an ai.brutor.registry _meta block with registry-native analytics and the server’s gateway-governance posture: governed (registered and fronted by the gateway), ungoverned (known to exist, not under enforcement) or unknown. A developer browsing for a tool sees at a glance whether using it is sanctioned.

The registry always serves

Governance enrichment is fail-open by design: if the control plane is unreachable or the integration is disabled, records are served with governanceStatus: "unknown" rather than the registry going down. A catalog that fails closed is a catalog people stop using.

What’s in the box

Piece	What it is
Registry server	Rust/Axum, PostgreSQL storage, on-boot idempotent migrations under an advisory lock, port 5001
API	/v0.1 per the official spec — browse, keyword/namespace search, updated_since incremental consumption, include_deleted tombstones — plus the legacy /v0 surface
Aggregator	Scheduled upstream sync (AGGREGATOR_INTERVAL_SECONDS, default hourly), SSRF-guarded connections
Auth	Platform JWTs (shared JWT_SECRET); optional additive mcp-registry:write scopes; GitHub OAuth for namespace verification
Console	The MCP Registry section of the Gateway Admin Console — connections, browsing, publishing, monitoring
CLI	list, show, remove, stats, sync — deployment & operations

Ported to Rust

As of the 0.11 series the registry service is implemented in Rust (previously Python/FastAPI). The wire surface, database schema and Console integration are unchanged — existing clients, tokens and connections keep working. See the deployment page for what operators should know.

How it fits the platform

• The Asset Register inventories the AI estate inside your gateway; the MCP Registry catalogs MCP servers for it — including ones not yet under governance.
• Registering an MCP server in the gateway is what makes it governed: access-controlled, policy-checked and audited. The registry reflects that status; it does not grant it.
• Shadow AI Discovery finds MCP servers nobody registered — the registry is where the sanctioned alternative is published.

In this section

Console administrationManage connections, browse and publish, monitor the registry from the Admin Console.

Publishing serversPublish server.json records, verify namespaces, understand version immutability.

Federation & the aggregatorConnect upstream registries and serve their catalogs as your own.

API referenceThe /v0.1 and /v0 surfaces, auth, pagination, _meta blocks and extensions.

Deployment & operationsEnvironment variables, migrations, seeds, CLI, health and telemetry.