kmcp: a CLI and Kubernetes controller for MCP servers

The gap kmcp targets: MCP servers that outlive the prototype

The README frames the problem in its own words: prototyping MCP services in isolation is quick, but production adoption brings ad-hoc scaffolding, transport fragmentation, and disconnected context for security and observability. That is a fair description of how MCP servers usually get built. A developer writes a small server against the MCP Go SDK or FastMCP, runs it over stdio, and stops there. The moment a second client needs the same tools, or the server has to run somewhere other than a laptop, someone has to decide on a transport, wrap the process in a container, write a Deployment, and wire credentials. kmcp's claim is that those steps should be part of the tool rather than repeated per project.

The audience is narrower than the tagline suggests. The README lists three journeys: a first MCP service prototype, an AI/ML engineer packaging an existing prototype, and a DevOps engineer building MCP infrastructure in Kubernetes. The first two can use the CLI alone. The third is where the controller and transport adapter matter, and it assumes a working cluster and familiarity with kubectl. If your team has no Kubernetes footprint, most of kmcp is dead weight.

Three components, three different jobs

The repository describes three core components. The CLI scaffolds MCP projects, manages tools, builds container images, and runs an MCP server locally. The controller watches a Custom Resource Definition that represents MCP servers as Kubernetes objects, so lifecycle operations go through kubectl like any other resource. The transport adapter sits in front of the MCP server and handles external traffic routing across multiple transport protocols without code changes to the server itself.

That split is the interesting design decision. Transport handling lives outside the server process, which means a server written for one protocol can be fronted by the adapter and reached over another. The README names HTTP, WebSocket, and Server-Sent Events as supported transports. The trade-off is that the adapter becomes a component you must run, configure, and keep in sync with the server it fronts. For a single internal tool server, that is an extra hop and an extra thing to debug. For a fleet of MCP servers behind one ingress, it is the part that stops each team from reimplementing transport negotiation.

The controller uses a CRD, which is the standard Kubernetes extension mechanism. The practical consequence is that MCP server definitions become declarative objects you can diff, review, and apply from CI. The README does not show the CRD schema in the material available here, so the exact fields and defaults cannot be confirmed from this page alone.

Installing the CLI and what the first command returns

Installation is a single shell script, quoted verbatim from the README:

curl -fsSL https://raw.githubusercontent.com/kagent-dev/kmcp/refs/heads/main/scripts/get-kmcp.sh | bash

Verification is `kmcp --help`. The README includes a screenshot of that output rather than the text, so the exact subcommand list is not recoverable from the material supplied here. What the README does state is that the CLI covers project scaffolding, tool management, image builds, and local runs. Those are the four verbs to look for when you run `kmcp --help` yourself.

Two scaffolding targets are named: FastMCP for Python and the MCP Go SDK. If your MCP server is written in another language, the CLI's scaffolding path does not cover you, and you would be using kmcp only for the Kubernetes side. Deployment is documented in two options: deploying an existing server with npx or uvx, and building and deploying a server through the CLI. The README links both to kagent.dev/docs/kmcp rather than reproducing the manifests, so the YAML for the CRD and the adapter configuration lives in the docs site, not the README.

What the README does not settle

Several things a reader would want before adopting are absent from the material. The CRD's apiVersion, kind, and spec fields are not shown. The transport adapter's configuration keys are not shown. There is no statement about which MCP protocol revision the adapter implements, and no list of client-side transports it can terminate. Secrets management is described as integrated with Kubernetes secrets, which tells you the mechanism but not the scope: whether the controller injects secrets as environment variables, mounts them as volumes, or references them by name in the CRD.

The release cadence is visible from the tags: v0.2.7 in March 2026, v0.2.8 later that month, v0.3.0 in May 2026. The 0.x version numbers are the honest signal here. The project is still before 1.0, so CRD schema changes between minor versions are plausible. If you deploy the controller, pin the version and read the release notes before upgrading, because a CRD change can require a migration step that a plain image bump will not perform.

Where kmcp is the wrong tool

The clearest mismatch is a developer running a local MCP server for a desktop client over stdio. That setup needs no controller, no adapter, and no cluster. Pulling in kmcp means running a Kubernetes control plane to solve a problem you do not have. The CLI's scaffolding could still be useful in that scenario, but you would be installing a toolkit whose majority is inert.

A second mismatch is a team already standardized on a different deployment path, for example a serverless platform or a plain container runtime with no Kubernetes API. The controller is the center of the project's production story, and without a cluster it does nothing. The transport adapter is more portable in principle, but the README presents it as part of the Kubernetes deployment flow, so treating it as a standalone reverse proxy is not a use case the documentation supports.

A third case is any server that needs a transport the adapter does not terminate. The README names HTTP, WebSocket, and SSE. If your clients speak something else, the adapter is not a bridge for you, and you would be back to handling transport inside the server.

How this differs from hand-rolled manifests or a generic MCP framework

The obvious alternative is doing it yourself: write the MCP server, containerize it, and deploy a Deployment plus a Service plus an Ingress by hand. That gives you full control and no extra dependency. The cost is that every team repeats the transport work, and the resulting manifests have no shared schema, so a platform team cannot enforce anything across MCP servers. kmcp's answer is to make the MCP server a typed object in the cluster and put transport in a shared adapter. The difference is not capability but consistency: hand-rolled manifests can do everything kmcp does, they just do it differently in each repository.

A second alternative is a language-level MCP framework such as FastMCP or the MCP Go SDK on its own. Those give you the server and its transport handling in-process, with no cluster dependency. kmcp actually builds on both, so this is not a competitor so much as a layer below. If your transport needs are simple and your deployment target is a single host, the framework alone is the smaller commitment. kmcp earns its place when the number of servers, clients, or environments grows past what one person can track in their head.

Licence, maintenance, and what to check before you commit

kmcp is Apache-2.0, which permits commercial use, modification, and redistribution provided you keep the licence and notice files and state significant changes. It includes a patent grant. That is the same licence as Kubernetes itself, so it will not raise a new review with most legal teams. This is not legal advice; if you redistribute kmcp inside a product, have counsel read the NOTICE requirements.

Maintenance cost is dominated by the controller and adapter, not the CLI. A cluster component needs upgrades, RBAC review, and a rollback plan when a CRD changes shape. The CLI is a single binary you can reinstall from the script above, so its cost is near zero. Budget accordingly: the CLI is cheap to try, the controller is a long-term commitment. Check the CRD schema against the version you install, confirm the transport adapter covers your clients' protocols, and read the v0.3.0 release notes for any migration steps before you point it at a shared cluster.

Editorial conclusion

Adopt kmcp if your MCP servers will live in Kubernetes and you want a CRD, a transport adapter, and a scaffolding CLI from one project. Do not adopt it if you only need a local stdio MCP server for a desktop client, because the controller and adapter add cluster surface you will not use. Before committing, verify three things: that the transport adapter supports the protocol your clients speak, that the CRD schema in the docs matches the release you install, and that the FastMCP or MCP Go SDK scaffolding path covers your language.

Official sources

1. kagent-dev/kmcp on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases