describe_kubectlLABSCO SUMMARY
Whoever holds the kubeconfig holds the cluster.
Because credentials arrive per request rather than being mounted, the server has no notion of which clusters it may touch — the scope of a call is exactly the scope of the kubeconfig sent with it. Send a config for a service account limited to the namespace in question, not your admin config. The upside of the same design is real: one deployment serves many clusters, and switching between them is a header change rather than a restart.
What it is
A network-accessible server that lets a model run Kubernetes CLI tools. Its distinguishing choice is that the kubeconfig travels with each request as base64 rather than being mounted at startup — so one running server can address many clusters without reconfiguration.
What you get
- Four CLI tools, each on its own HTTP endpoint —
kubectl,helm,istioctlandargocd - A tool endpoint takes a
commandstring, soget pods -n defaultruns as written - Credentials per call: pass the base64 kubeconfig in the
X-Kubeconfigheader, which keeps it out of the request body and out of the model's token count, or in akubeconfigbody field - Any standards-compliant cluster works — EKS, GKE and AKS included — because the config is supplied rather than pre-baked
- Interactive API documentation at
/docsand a health check at/health - The container runs as a non-root user
Requirements
Docker is the documented path: docker run the docker.io/apecloud/k8s-mcp-server:latest image with port 9096 published, then point clients at http://localhost:9096/mcp. From source it needs Python with a virtual environment, pip install ., and uvicorn src.k8s_mcp_server.app:app --host 0.0.0.0 --port 9096. Published as k8s-mcp-server version 1.3.0. There are no credentials to configure on the server — the caller supplies a base64-encoded kubeconfig on every request, which is also the whole access control story.
Setup effort
One command plus a key — docker run -d --rm -p 9096:9096 --name mcp-server docker.io/apecloud/k8s-mcp-server:latest, then supply credentials
USE CASES
01
Asking why a pod is unhealthy
Run the get and describe commands against the right namespace and read the output in the conversation.
02
Working across several clusters from one place
Send a different kubeconfig per request rather than running a server per environment.
03
Checking what a Helm release actually deployed
Run helm commands through the same endpoint shape as kubectl.
04
Keeping cluster credentials out of the model's context
Pass the kubeconfig in a header so it never becomes part of the prompt.
8 tools
Listed in project docs. Your client may show a different list.
describe_helmdescribe_istioctldescribe_argocdexecute_kubectlexecute_helmexecute_istioctlexecute_argocdBEFORE YOU INSTALL
What to know first
Tools you get
8 tools named in the project's documentation.
Requires
A client that can reach a remote MCP server over HTTP
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
docker run -d --rm -p 9096:9096 --name mcp-server docker.io/apecloud/k8s-mcp-server:latestMCP Clients
Any MCP client — HTTP
ANY MCP CLIENT — HTTP · JSON
{
"mcpServers": {
"kubernetes": {
"url": "http://localhost:9096/mcp"
}
}
}
