It goes through Kubernetes' own API machinery instead of shelling out to kubectl, so the object you get back for a custom resource is the object the cluster holds, and applying a manifest takes the same path an operator would. Two things decide how it behaves in your setup: read-only is the default and writes have to be enabled deliberately, and serving every cluster resource as context is useful on a small cluster and expensive on a big one.
A Kubernetes client for MCP clients, written in Go and talking to the API server directly. It uses the unstructured client rather than typed handlers, so every resource the cluster serves is reachable, including CRDs nobody wrote code for.
- The set of resource types the API server actually supports, clustered and namespaced
- Any resource listed, narrowed by label selector, with annotations filtered or dropped so a node list does not swamp the context window
- A single resource or one of its subresources — status, scale, pod logs — with log output capped by default rather than dumped whole
- Resources created or updated from a manifest you hand it
- Commands run inside a pod, with a timeout, returning stdout, stderr and the error if there was one
- Cluster resources served as MCP resources as well as tools, which can be switched off on large clusters
A kubeconfig for the cluster you want reached, and a Go toolchain — it is built from the repo rather than installed as a package. Writes are off by default: apply_resource, delete_resource and post_resource are not registered at all until you start it in read-write mode.