apply-k8s-resource
Create or modify a Kubernetes resource from a YAML manifest
LABSCO SUMMARY
One session reads staging and production without re-pointing anything between calls.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
One command — npx @strowk/mcp-k8s
USE CASES
01
Chasing an error across two clusters
List the contexts, then read events in one and pod logs in the other without re-pointing anything between calls.
02
Reading a resource the way you want it
Take the whole object as JSON, or render just the fields you care about through a Go template.
03
Checking something from inside the pod
Run the command in the container — with stdin when it needs input — rather than guessing from the outside.
04
Applying a manifest you have agreed on
Create or modify the resource from YAML, against the context you name on the call.
05
Letting an agent investigate without touching anything
Start with --readonly — the apply and exec tools never appear, and secrets stay masked in what does.
9 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
get-k8s-pod-logs
Get logs for a Kubernetes pod using specific context in a specified namespace
get-k8s-resource
Get details of any Kubernetes resource like pod, node or service - completely as JSON or rendered using template
k8s-pod-exec
Execute command in Kubernetes pod
list-k8s-contexts
List Kubernetes contexts from configuration files such as kubeconfig
list-k8s-events
List Kubernetes events using specific context in a specified namespace
list-k8s-namespaces
List Kubernetes namespaces using specific context
list-k8s-nodes
List Kubernetes nodes using specific context
list-k8s-resources
List arbitrary Kubernetes resources
BEFORE YOU INSTALL
What to know first
Tools you get
9 tools when we connected.
Requires
npx on PATH
CONTEXT COST
Light Standing cost
Rated by the size of the 9 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Add the block to your client, or run the command directly.
Server setup
Configuration file
JSON
{
"mcpServers": {
"mcp-k8s": {
"command": "npx",
"args": [
"@strowk/mcp-k8s"
]
}
}
}npx
TERMINAL
npx @strowk/mcp-k8s
