get_resourceLABSCO SUMMARY
Kubernetes without a wrapper in the middle.
It goes through Kubernetes' own API machinery instead of shelling out to kubectl, so the object you get back for a custom resource is the object the cluster holds, and applying a manifest takes the same path an operator would. Two things decide how it behaves in your setup: read-only is the default and writes have to be enabled deliberately, and serving every cluster resource as context is useful on a small cluster and expensive on a big one.
What it is
A Kubernetes client for MCP clients, written in Go and talking to the API server directly. It uses the unstructured client rather than typed handlers, so every resource the cluster serves is reachable, including CRDs nobody wrote code for.
What you get
- The set of resource types the API server actually supports, clustered and namespaced
- Any resource listed, narrowed by label selector, with annotations filtered or dropped so a node list does not swamp the context window
- A single resource or one of its subresources — status, scale, pod logs — with log output capped by default rather than dumped whole
- Resources created or updated from a manifest you hand it
- Commands run inside a pod, with a timeout, returning stdout, stderr and the error if there was one
- Cluster resources served as MCP resources as well as tools, which can be switched off on large clusters
Requirements
A kubeconfig for the cluster you want reached, and a Go toolchain — it is built from the repo rather than installed as a package. Writes are off by default: apply_resource, delete_resource and post_resource are not registered at all until you start it in read-write mode.
Setup effort
Build from source — git clone https://github.com/StacklokLabs/mkp.git
USE CASES
01
Working out why a rollout is stuck
List the deployments in the namespace, then read the one that is unhappy together with its status subresource, without switching context to a terminal.
02
Reading logs out of a failing pod
Pull the log subresource for a named container, bounded by lines or by how far back you want to go, so the tail lands in the conversation instead of the whole file.
03
Taking stock of what a cluster runs
Ask what resource types exist — CRDs and all — then list any of them, dropping the annotation noise that makes node and pod listings unreadable.
04
Applying a change from the conversation
Hand it the manifest and it creates or updates the resource in place. Available only once the server is started with writes enabled.
05
Running a check inside a container
Execute a command in a chosen container and read stdout and stderr back, with a timeout so a hanging command does not hang the session.
5 tools
Listed in project docs. Your client may show a different list.
list_resourcesapply_resourcedelete_resourcepost_resourceBEFORE YOU INSTALL
What to know first
Tools you get
5 tools named in the project's documentation. Read-only mode is the default, so apply_resource, delete_resource and post_resource are unavailable until you pass --read-write=true.
Requires
- Go 1.24 or later
- Kubernetes cluster and kubeconfig
- Task for running tasks
INSTALLATION
Connect your client
Server setup
Clone the repository
TERMINAL
git clone https://github.com/StacklokLabs/mkp.git
cd mkpInstall dependencies
TERMINAL
task installBuild the server
TERMINAL
task buildRun the server
TERMINAL
task runPoint your MCP client at http://localhost:8080/mcp — the server listens on port 8080 over Streamable HTTP by default (set MCP_PORT to change the port)
MCP Clients
ToolHive
Install ToolHive: brew tap stacklok/tap && brew install thv (Windows: winget install stacklok.thv)
TOOLHIVE · TERMINAL
thv client setup
thv run --volume $HOME/.kube:/home/nonroot/.kube:ro k8sToolHive runs MKP from its registry image (ghcr.io/stackloklabs/mkp/server) with your kubeconfig mounted read-only, and registers it with the clients you picked in thv client setup. Writes stay off unless you add -- --read-write=true after k8s.
