MCP Runtime is a self-hosted Kubernetes control plane for internal Model Context Protocol servers. It provides declarative MCP server deployment, registry workflows, operator reconciliation, request-path governance, access/session resources, audit, analytics, dashboards, and a platform control surface for browsing and operating MCP servers.

The public platform at platform.mcpruntime.org is a live preview of the deployable platform experience. It runs the public preview catalog mode, where visitors can browse public preview MCP servers and signed-in preview users can publish into the public catalog namespace. It is still not a general-purpose public MCP marketplace. Companies can deploy the same model in their own Kubernetes clusters, then host, manage, govern, and audit MCP servers through both the CLI and the platform control surface for agents, IDEs, and direct human workflows.

• Website
• Platform preview for the platform control surface; companies can deploy the same model in their own clusters
• Docs and docs/
• API reference and docs/api.md
• Articles and articles/
• Early adopters: MCP Runtime is looking for teams running or evaluating internal MCP platforms. Open a GitHub issue with your use case, cluster shape, or integration feedback.

• Operate MCP servers where company data already lives. Deploy into an existing Kubernetes cluster instead of sending internal tools, tokens, or traffic through a third-party catalog or hosted proxy.
• Use Kubernetes as the source of truth. MCPServer, MCPAccessGrant, and MCPAgentSession resources make server delivery, access grants, agent sessions, policy, rollout, and status inspectable with normal Kubernetes workflows.
• Move beyond "connect an agent to a URL." The gateway can enforce identity, deny-by-default tool policy, trust ceilings, side-effect limits, session expiry, revocation, and audit emission on the live MCP request path.
• Give agents a clean integration path. The stdio and Streamable HTTP adapters let IDEs, agent frameworks, and scripts attach platform-issued governance identity without each client reimplementing grants or session handling.
• Support internal catalog models. Run private tenant namespaces, an org-wide catalog, or a public preview-style catalog while keeping the same CLI, CRDs, platform UI, and operator model.
• Separate teams without separate platforms. Team namespaces, RBAC, teamID, subject matching, and namespace-scoped grants/sessions let multiple teams publish and govern MCP servers on one cluster.
• Own the day-two path. Setup, registry workflows, image pull wiring, ingress, rollout readiness, cluster doctor, status commands, dashboards, audit, analytics, and Sentinel services are part of the platform rather than afterthoughts.
• Fit different cluster shapes. The documented paths cover disposable Kind development, laptop evaluation, k3s labs, self-managed production clusters, and managed Kubernetes with external registries.

• mcp-runtime CLI for setup, status, registry, server, cluster, access, and sentinel
• mcp-runtime adapter proxy and mcp-runtime adapter stdio subcommands for governed HTTP and stdio agent integrations. Both can fetch identity from the platform with --server <name> --agent <id> [--auto-refresh], or accept explicit MCP_RUNTIME_* env vars (see Agent Adapters)
• Platform UI for authenticated MCP catalog browsing, platform state, and web operations
• MCPServer, MCPAccessGrant, and MCPAgentSession CRDs
• Kubernetes operator for Deployment, Service, Ingress, and policy materialization
• Internal or provisioned registry workflows
• Optional gateway enforcement for identity, tool policy, trust, and audit emission
• Bundled Sentinel stack for ingest, processing, API, UI, and observability

The Official MCP Registry and public MCP directories such as Glama, Smithery, Docker MCP Catalog on Docker Hub, PulseMCP, mcp.so, and client-specific catalogs are useful discovery and installation surfaces. MCP Runtime is different: it is a deployable operating layer for running MCP servers inside a company's own environment. It can provide an internal catalog-like view, but the main product is deployment, governance, brokered access, audit, compliance evidence, and day-two operations.

Open-source MCP gateways such as agentgateway, Microsoft MCP Gateway, IBM ContextForge, MCPJungle, Unla, OpenZiti MCP Gateway, Docker MCP Gateway, Obot, Preloop, and Agentic Community MCP Gateway & Registry are useful references, and several are more than thin proxies. The real difference is not "gateway versus platform" in the abstract; it is where the source of truth lives.

MCP Runtime's main distinction is simplicity around Kubernetes-native control-plane management. MCPServer, MCPAccessGrant, and MCPAgentSession are managed as first-class Kubernetes state instead of only gateway configuration; the operator reconciles workloads, services, ingress, registry image references, gateway policy ConfigMaps, and readiness status; the gateway enforces the rendered grant/session policy and emits audit/analytics events into the Sentinel stack.

This comparison was reviewed on June 4, 2026 with AI assistance against the referenced open-source repositories and local clones in inspirations/.

Host tools:

• Go 1.25+
• Make
• Docker or a Docker-compatible client, with the daemon running
• kubectl on PATH, configured for the target cluster
• curl, jq, and python3 for documented dev and traffic-generation flows
• kind for local Kind-based clusters

Cluster prerequisites:

• A running Kubernetes cluster: kind, k3s, minikube, Docker Desktop Kubernetes, EKS, GKE, AKS, or equivalent
• Working DNS, default storage class, ingress, and load-balancing path for your distribution
• See docs/deployment-targets.md to choose the install shape, then docs/cluster-readiness.md before running production-like installs

mcp-runtime setup installs the platform stack, including Sentinel services such as ClickHouse and Kafka. You do not install those separately for the default flow.

make deps-install              # best-effort host install where supported
STRICT_DEPS_CHECK=1 make deps-check
make deps
make build

./bin/mcp-runtime bootstrap
./bin/mcp-runtime setup
./bin/mcp-runtime status

Notes:

• make deps-install is best-effort. It cannot start Docker Desktop, create cloud credentials, or configure kubeconfig for you.
• make deps checks host tools and downloads Go modules. It does not create a Kubernetes cluster.
• make build produces ./bin/mcp-runtime with version metadata from git describe --tags --match 'v*', the current commit, and UTC build time. Release binaries use the release tag exactly. Override with VERSION=<tag> make build when needed.
• Contributors who want a disposable local Kind install should start with the maintained docs/contributor/ guide. The shorter entry summary remains in docs/getting-started.md.
• To exercise agent-side governance against a real MCP route, use the examples/governed-agent demo.

./bin/mcp-runtime bootstrap              # preflight cluster prerequisites
./bin/mcp-runtime setup                  # install platform stack
./bin/mcp-runtime status                 # show platform health
./bin/mcp-runtime registry status        # inspect registry
./bin/mcp-runtime server status          # inspect MCP servers
./bin/mcp-runtime access grant list      # inspect access grants
./bin/mcp-runtime sentinel status        # inspect Sentinel stack

gofmt -s -l .
go build -o bin/mcp-runtime ./cmd/mcp-runtime
go test ./... -count=1 -race
go vet ./...

For targeted tests, e2e setup, and debugging runbooks, use AGENTS.md and the docs site.

The repo keeps Claude-specific local configuration in .claude/. Its skills entry is expected to be a symlink to ../.codex/skills, so Claude Desktop and the Codex CLI discover the same repository skills during local development.

Apache License 2.0. See LICENSE.