Skip to content
Brutor AI Docs

Console administration

The registry is administered from the MCP Registry section of the Gateway Admin Console. The section appears when the deployment runs a registry service and the tenant’s MCP Registry feature is enabled; the former standalone registry admin UI was consolidated into the Console.

The Console talks to the registry through the control plane’s authenticated passthrough (/v1/admin/mcp-registry/*), which mints a short-lived service token per request from the shared platform JWT_SECRET — you never configure registry credentials in the browser.

Dashboard

Section titled “Dashboard”

The landing tab shows totals (servers registered, verified, with icons), connection health, aggregator status and last-sync outcomes, and recent activity from the registry’s log buffer.

Registry connections

Section titled “Registry connections”

Connections are the upstream registries the aggregator pulls from. Three are seeded on first boot: the Official MCP Registry (registry.modelcontextprotocol.io, enabled), Smithery (disabled — enable it to federate the community catalog, see federation), and a disabled Local Development Registry placeholder.

  1. Add — name + base URL, optional bearer/API-key credential. The URL is SSRF-checked server-side: it must be http(s) and resolve to a public address.
  2. Test — probes {url}/v0/servers?limit=1 and reports reachability, response time and how many servers the upstream exposes.
  3. Enable — enabled connections are included in the scheduled sync and in cross-registry search.

Stored credentials are write-only: the API and Console always show ***. The seeded default connection cannot be deleted (disable it instead).

Browse & publish

Section titled “Browse & publish”

The Servers tab lists everything the registry serves — your own publications and aggregator imports, each labeled with its verification state and its provenance (via <registry> on federated servers; locally published servers read Published in this registry in the detail view). A Show deleted toggle reveals tombstoned servers (hidden by default). The detail view adds the server’s governance posture badge (governed / ungoverned / unknown, from the ai.brutor.registry _meta block) and its lifecycle metadata — a deprecated server shows the status note and when it changed.

Deprecating or deleting a server from the Console prompts for an optional status note (e.g. “Superseded by widget2 — migrate by Q4”), which the registry serves back to every consumer as statusMessage.

Publishing from the Console walks the same validation as the API: server.json compliance, namespace format, semver, and duplicate-version rejection.

Namespace verification

Section titled “Namespace verification”

Unverified namespaces carry a verify action that opens the verification dialog:

  • io.github.* — a Continue with GitHub hand-off; the OAuth flow completes in the browser against the registry’s public URL.
  • Domain namespaces — the dialog shows the DNS TXT record (or, switched to the HTTPS-file method, the well-known URL and expected content) and a Check now button that asks the registry to confirm the challenge. Challenges stay valid for 24 hours.

Monitoring & configuration

Section titled “Monitoring & configuration”
  • Logs — the registry keeps an in-process ring buffer of its last 500 log entries, filterable by level; no log-shipping stack required for a quick look.
  • Metrics — request counts and response-time percentiles, plus publish/download/search counters.
  • Config — the effective runtime configuration (auth mode, aggregator interval, governance integration state), read-only.