There is no shaped tool surface here — it runs the commands you would have run, which means the reach is whatever your kubeconfig grants, writes included. Piping support is what separates it from a one-command wrapper: the diagnostic commands people actually type usually have a pipe in them.
A server that runs kubectl on your behalf and interprets what comes back. It accepts a kubeconfig path, so you choose which cluster and context the commands land on, and it supports command-line piping rather than only single flat commands.
- Kubectl commands executed against your cluster, with the result interpreted rather than dumped raw
- Flexible command-line piping, so multi-stage commands work as they do in your shell
- A custom kubeconfig path, to pick the cluster and context the calls run against
- A startup check that kubectl is actually installed, and error messages that say what went wrong
Kubectl installed and on the path, and a kubeconfig for the cluster you want to reach. Node dependencies installed and the project built; the client points at `build/index.js`. No account or key beyond your existing cluster credentials. The package is `k8s-interactive` 0.1.0.
One command — npx -y github:TaichiHo/k8s-interactive-mcp
