MCP server registry & lifecycle

The registry is the control plane’s record of every MCP server the gateway knows about. A server isn’t callable because it’s registered — it’s callable because it’s approved and projected to the data plane, subject to policy.

The lifecycle

1. Submitted. An owner registers a manifest (transport, tools, metadata). Submissions are immutable — a change is a new submission, not an edit.
2. Under review. A reviewer compares the pending submission to what’s live and approves or rejects it. See Review & approve a submission.
3. Approved → published. On approval the server is compiled into the runtime projection and becomes callable per policy.
4. Versioned. Each approved state is an immutable snapshot; you can list versions and compare any two.
5. Deprecated / disabled / archived. Lifecycle transitions retire a server without deleting its history.

Transports are explicit

An approved server declares exactly one transport — streamable_http, legacy_sse, or stdio (trusted self‑hosted only). The gateway never infers behavior from a URL shape, and the projection preserves sanitized tool input schemas plus lifecycle metadata (projectionVersion, active/desired versions, reload state).

Health is read‑only

Health reflects stored probe state — refreshing it reads what the gateway already knows; it does not re‑probe the upstream on demand. To actively probe a server before registering it, use the dedicated probe endpoint (POST /v1/registry/probe-mcp-server), which performs an MCP initialize + tools/list without registering anything.

Note

Because submissions are immutable and every approval is a snapshot, an audit event can always be tied to the exact server version that served a call.