Because context is an argument rather than global state, an agent can compare events in one cluster against logs in another inside a single conversation, and a mistake shows up as a wrong argument instead of a wrong session. That is also the reason to set the two flags: an allowed-context list and read-only mode decide how far a wrong argument can go.
A Kubernetes client exposed as tools, working across the contexts in your kubeconfig, where context is a parameter on the call rather than session state. A single Go binary, also published to npm and Docker Hub.
- Any resource fetched by group, version, kind, name and namespace, returned whole as JSON or rendered through a Go template
- Arbitrary resource kinds listed, rather than a fixed set of built-in ones
- Pod logs scoped by container, byte limit and either a duration or a start timestamp, including the previous container after a restart
- Cluster events, namespaces and nodes listed per context
- Commands run inside a pod, with stdin
- Resources created or modified from a YAML manifest
- The context list itself, read out of kubeconfig, so one session can move between clusters
- Secrets masked in output by default, and a --readonly flag that removes every tool that could change the cluster
- --allowed-contexts, which limits the session to the clusters you name however many the kubeconfig holds
A kubeconfig holding the contexts you intend to name — KUBECONFIG points at it, defaulting to ~/.kube/config, and the Docker image needs it mounted in. Every tool takes context as an argument, so the cluster a call lands on is chosen per call; --allowed-contexts is what stops that being every cluster you have credentials for. Prebuilt binaries need nothing else, the npm package needs Node.js, and building from source needs Go.
One command — npx @strowk/mcp-k8s