ToolHive: A Secure MCP Platform for AI Tools
stacklok/toolhive
ToolHive is a self-hosted platform for running Model Context Protocol servers in isolated containers, built by Stacklok under Apache-2.0 with 1,992 GitHub stars. Reach for it if you need per-request identity checks and audit logs before letting developers wire MCP servers into Claude Code, Cursor, or Copilot; skip it if you just want one MCP server running locally and have no use for a gateway or a Kubernetes operator on top.
What is ToolHive?
ToolHive is an open-source platform from Stacklok that runs each Model Context Protocol (MCP) server inside its own isolated container instead of a bare local process. It sits between AI clients like Claude Desktop, Cursor, or VS Code and the MCP servers they call, enforcing identity and access policy per request once you configure an authentication source, and giving platform teams the observability to see what's actually running.
The Challenge of Managing AI Tools
Most teams pick up MCP servers one at a time: a developer finds one on GitHub, runs it locally with whatever credentials are sitting around, and nobody on the security team knows it exists. That's the gap ToolHive targets — there's no built-in enforcement point to require identity checks before a server runs, log what it touched, or stop someone running a server with a wide-open permission set. Platform teams on Kubernetes have the mirror problem: they already run everything through CRDs, OIDC, and Prometheus, and want MCP servers to follow that same pattern instead of becoming a one-off exception.
Who Benefits from ToolHive?
ToolHive is built for three groups the README names directly: individual developers who want to run MCP servers without scattering credentials across their laptop, platform engineers who need MCP to run on Kubernetes infrastructure they already operate, and enterprises whose compliance rules block sending sensitive data to SaaS-hosted MCP providers and need to self-host the registry and gateway instead. If you're just experimenting with one MCP server on your own machine, the desktop app or CLI covers that without needing the Kubernetes side at all.
Core Architecture and Capabilities
- ✓Gateway — a policy control point that centralizes authentication and authorization, integrates with an identity provider over OIDC/OAuth for SSO, and filters or rewrites tool descriptions before requests reach an MCP server.
- ✓Registry Server — a curated catalog that pulls from the official MCP registry, lets you add custom servers, and verifies provenance with signing before a server is exposed to users.
- ✓Runtime — runs MCP servers locally via Docker or Podman, or in a Kubernetes cluster through the operator, and can proxy remote MCP servers so local and hosted servers go through the same access path.
- ✓Portal — a cross-platform desktop app (toolhive-studio) plus a browser-based cloud UI (toolhive-cloud-ui) so admins curate servers and end users install one with a single click.
- ✓Kubernetes Operator with Custom Resource Definitions for MCP servers and registries, multi-namespace isolation, and automated service creation with ingress integration.
- ✓Container isolation by default — every MCP server runs in its own container with a minimal permission file instead of a local process holding your credentials.
- ✓OpenTelemetry traces and Prometheus metrics wired into the Runtime and Operator, plus audit logging, for teams that need to prove what an MCP server did.
- ✓Semantic tool search and an MCP Optimizer that the README credits with cutting token usage by up to 85% by filtering which tools and descriptions reach the model.
Getting Started with ToolHive
The README doesn't hand you a single install command — it links out to three separate quickstart guides on docs.stacklok.com: one for the desktop app, one for the CLI, and one for the Kubernetes Operator, plus a command reference for the `thv` CLI tool. Beyond those links, the actual install steps (package names, minimum Docker/Podman version, and so on) aren't spelled out in what's provided here, so treat this as 'go to the quickstart for your deployment path' rather than one onboarding flow.
Deployment Options and Workflows
Deployment breaks into three modes per the README. Desktop: install the UI or CLI on your own machine, run MCP servers from a container image or build one on the fly from a common package manager, and test them with the built-in MCP Inspector. Kubernetes Operator: install the CRDs for MCP servers and registries, and the operator handles namespace isolation, service creation, and ingress — teams get OIDC/OAuth SSO, audit logging, OpenTelemetry, and Prometheus metrics the same way they'd configure any other cluster workload. Hybrid: the setup the README pitches for larger orgs, where end users hit approved servers through the cloud UI while developers still connect directly via CLI or desktop for testing, and every server — local, cluster, or externally hosted — routes through the same Gateway and access controls.
Strengths
- ✓Every MCP server runs in its own container with a minimal permission file instead of a bare local process holding your credentials — a real security boundary, not just a config flag.
- ✓One access-control layer (OIDC/OAuth SSO, audit logging, per-request policy) covers desktop, Kubernetes, and hybrid deployments instead of three separate auth setups.
- ✓The Kubernetes Operator uses CRDs and plugs into your existing IdP, OpenTelemetry, and Prometheus stack, so platform teams don't have to bolt on a separate monitoring pipeline just for MCP.
- ✓Apache-2.0 licensing on the CLI, API, and Operator means you can self-host the whole core without a SaaS dependency — the specific compliance problem the README says it's built to solve.
Addressing Common AI Tool Management Gaps
- △The README doesn't give install commands or a version number in what's provided here — you leave the repo and go to docs.stacklok.com to actually get started, which is friction if you just want to try one MCP server in five minutes.
- △Most of the differentiated capability — the Kubernetes Operator, the cloud UI, the full Registry Server — lives in separate repos (toolhive-studio, toolhive-cloud-ui, toolhive-registry-server), so this repo alone is really the CLI, API, and Operator core, not the whole product.
- △The README frames the open-source project as a stepping stone to Stacklok Enterprise once you need to scale — worth knowing if you're evaluating this specifically to avoid vendor lock-in.
- △1,992 stars and 269 forks is a modest, early-stage community by the numbers given — there's nothing here on release cadence, contributor count, or how battle-tested the Operator is under production load.
ToolHive vs. Other Solutions
Frequently Asked Questions
Model Context Protocol (MCP) is a standard that lets AI clients like Claude Desktop or Cursor connect to external tools and data sources through a common interface, instead of a custom integration for every tool.
ToolHive integrates with identity providers over OIDC and OAuth for single sign-on, and both the Gateway and the Kubernetes Operator enforce identity and access policy per request once an authentication source is configured.
ToolHive supports three deployment paths: a desktop app or CLI for an individual developer's machine, a Kubernetes Operator for cluster-wide management with CRDs, and a hybrid mode where local, cluster, and externally hosted MCP servers all route through the same Gateway.
ToolHive targets enterprise use directly: the README pitches self-hosting for teams whose compliance rules block SaaS-hosted MCP providers, with audit logging, OIDC/OAuth SSO, and a paid Stacklok Enterprise tier for teams that outgrow the open-source setup.
ToolHive is licensed under Apache-2.0, the same permissive license covering the CLI, API, and Kubernetes Operator in this repository.
ToolHive's Gateway filters and rewrites which tools and tool descriptions get sent to the model, and its semantic tool search plus MCP Optimizer are what the README credits with cutting token usage by up to 85%.
Best use cases
- •A platform team standardizing how every service team runs MCP servers on the company's existing Kubernetes clusters, using the Operator's CRDs instead of ad hoc Deployments.
- •A security team that needs an audit trail of which MCP servers ran, who accessed them, and what tools they called, without asking developers to change how they work in Claude Code or Cursor.
- •An enterprise that can't send internal data through a SaaS MCP provider and self-hosts the registry and gateway instead, matching the compliance use case the README describes.
- •A developer running several MCP servers locally who wants each one sandboxed in its own container with a minimal permission file rather than trusting a script with full filesystem access.