Applies default to a dry run, contexts can be blocked by pattern, and the raw escape hatch is checked against a denylist. That is what makes handing an agent a cluster different from handing it a terminal.
A Go server for local Kubernetes development, exposing 63 tools across eight groups: k3d clusters, kubectl operations, Helm charts, Kustomize overlays, Tilt workflows, Artifact Hub lookups, documentation search and composite CI routines. Helm and Kustomize run through their Go SDKs rather than the command line; kubectl, k3d and Tilt's lifecycle commands shell out.
- K3d clusters and their nodes created, started, stopped, listed and deleted — nine tools
- Kubectl work — get, describe, apply, delete, logs, port-forward — plus a raw escape hatch for anything the sixteen typed tools do not cover (`kubectl_apply`, `kubectl_logs`, `kubectl_raw`)
- Helm installs, upgrades, uninstalls, templating, status, values and repository management through the Helm Go SDK — ten tools (`helm_install`, `helm_upgrade`)
- Kustomize overlays built, built and applied, and edited for image or namespace — five tools
- Tilt brought up and down, run in CI mode, and queried for status, logs, session and resource detail over its HTTP API — ten tools
- Artifact Hub searched for packages, values, schemas, readmes and templates, with an optional automatic lookup before an install — six tools
- Full-text search over a bundled Bleve index of the tilt, k3d, kubectl and Helm documentation — four tools over roughly 257 pages
- Composite routines that bootstrap an environment, tear it down, or collect diagnostics — three tools
- Eight prompts for the multi-step jobs — `bootstrap_dev_env`, `debug_pod`, `deploy_and_verify`, `cluster_health_check`, `ci_run` and more — and read-only resources for cluster info, namespaces, pods, services, deployments, events, Tilt status, kubeconfig, Helm releases and doc pages
Go 1.26 or newer to build, plus Docker, k3d, kubectl and tilt on the machine; Helm and Kustomize command-line tools are optional because their Go SDKs are embedded. It inherits your own kubeconfig and cluster credentials, and runs over stdio or with `--http`. Configuration is a JSON file with no comments allowed. Three safety behaviours are worth knowing before you wire it up: `kubectl_apply` defaults to `dry_run: "client"` so a real apply has to be asked for explicitly, `blocked_contexts` rejects operations against contexts matching patterns such as `production` or `staging-*`, and `kubectl_raw` is checked against a denylist that only `unsafe: true` overrides.
Run a container — pull the image and point your client at it