Run kubectl-style operations against a Kubernetes cluster — list pods, inspect deployments, read logs, apply manifests. Cluster API server must be reachable from the public internet (sandbox cannot reach private VPCs without a tunnel).
1 field · 1 secret
Credentials are injected into an ephemeral sandbox at boot and destroyed with it.
Standard
Sessions run up to 60 minutes before the sandbox is reclaimed.
60+ AI models
Chat with 60+ AI models on the same workflow — switch to a different model mid-conversation and re-run the same prompt, or use Compare mode to put several side-by-side.
How models use it and what it is built for.
The Kubernetes MCP server gives a model kubectl-style access to a cluster — list pods, describe deployments, read logs, inspect events and apply manifests.
Debugging Kubernetes is mostly correlation work: a pod is crash-looping, so you check its events, then its logs, then the deployment spec, then the resource limits. That is a sequence of ten commands where each one depends on the last, which is precisely the kind of loop a model handles well when given real cluster access.
It authenticates with a kubeconfig you paste in. That file embeds real credentials and grants whatever access the user inside it has — so the setup step matters more here than on any other server in the catalog.
Concrete operations exposed as tools.
In order. Each step assumes the previous one worked.
Create a service account bound to a read-only ClusterRole (or a namespace-scoped Role), then generate a kubeconfig for it. Whatever you paste is exactly what the agent can do, and a cluster-admin kubeconfig in an AI session is a bad trade.
The sandbox connects over the public internet. Managed clusters with a public endpoint (EKS, GKE, AKS with public access enabled) work directly. A private control plane needs a tunnel or a bastion — the sandbox cannot reach a private VPC.
The entire YAML contents of the file, not a path. It is handled as a secret and injected at sandbox boot.
Ask the model to list namespaces. If that succeeds, connectivity and credentials are both correct.
What you provide before the sandbox starts.
Kubeconfig (YAML)RequiredSecretPaste the full contents of your kubeconfig file (~/.kube/config). Treat like a credential — it grants the access of whatever user it embeds. Prefer a service-account-scoped kubeconfig over your full admin one.
Paste any of these into Agent Studio once the server is connected.
List every pod that is not in Running state and explain why each one is failing.
The checkout deployment is crash-looping. Read the logs and events and tell me the root cause.
Which pods are closest to their memory limits right now?
Compare the resource requests of the api deployment against what its pods actually use.
Known constraints, stated plainly.
Deploy the server hosted, then watch which tools a model actually reaches for — with full JSON input and output on every call. Switch models mid-conversation to compare how each one uses the same server.
About the Kubernetes (kubectl) MCP server.
Only with a scoped one. Generate a kubeconfig for a service account bound to a read-only ClusterRole and the worst case is that the model reads things it should not. A cluster-admin kubeconfig means a bad tool call can delete workloads, so do not paste one.
Only if the kubeconfig you supply has write permissions. The server surfaces apply and edit operations, but RBAC is the real boundary — a read-only service account cannot be talked into a write by any prompt.
Not directly. The sandbox reaches the cluster over the public internet, so a private-only control plane needs a tunnel or a proxy with a public endpoint. Clusters with public API access enabled work as-is.
For a single command it is not. It pays off in the correlation loop — reading events, then logs, then the spec, then usage, and holding all four in context to explain a failure. That is a lot of terminal round-trips compressed into one question.