LABSCO SUMMARY

API answers pinned to the version you actually run.

Field names and resource shapes move between Kubernetes releases and a model's recall of them carries no date. Loading v1.33 and v1.35 side by side turns "is this field still there" into a lookup with a version attached.

What it is

A container that serves Kubernetes API resource documentation over MCP. You tell it which versions to pre-load and it answers from those.

What you get

Kubernetes API resources listed for the versions you loaded
The full definition of a named resource, read back from that version's documentation
Several versions pre-loaded side by side, which is how you see what changed between them
Anonymous mode for local use, or an API key store with per-tier rate limits when the instance is shared

Requirements

A container runtime — podman or docker — publishing the server's HTTP port. An environment variable picks which Kubernetes versions load, and it defaults to v1.33. A GitHub token is optional and raises the GitHub API rate limit, which matters when loading several versions at once. Running it anywhere but locally means declaring the hostnames it will answer on.

Setup effort

Follow the published steps — echo '[{"key":"mykey","tier":"free"}]' > keys.json

See installation options

USE CASES

01

Checking a field exists in your version

Read the resource definition from the version you loaded, rather than from a general answer that may describe a release you are not on.

get_resource

02

Working out what a manifest can contain

List the resources available, then read the one you are writing against — the spec itself, not an example somebody posted.

list_resourcesget_resource

03

Planning an upgrade

Load two versions and read the same resource from each; what moved between them shows up in one comparison.

get_resource

04

Settling what kind of object you are looking at

List what exists in the loaded version and pull the resource back by name, which resolves the API group and kind without a browser.

list_resourcesget_resource

3 tools

Listed in project docs. Your client may show a different list.

list_resources

get_resource

get_type

BEFORE YOU INSTALL

What to know first

Tools you get

3 tools named in the project's documentation. K8S_VERSIONS and the ?version parameter choose which Kubernetes release the tools answer for. All three only read documentation; none touch a cluster.

Where it runs

The documented client runs the server on your machine.

INSTALLATION

Connect your client

Server setup

TERMINAL

# 1. Create a key store file
echo '[{"key":"mykey","tier":"free"}]' > keys.json

# 2. Start the server
podman run -d \
  -p 3000:3000 \
  -v "$(pwd)/keys.json:/keys.json:ro" \
  -e K8S_VERSIONS=v1.33,v1.34,v1.35,v1.36 \
  -e KEY_STORE_PATH=/keys.json \
  ghcr.io/kubernetools/mcp-server:latest

MCP Clients

Any MCP client

ANY MCP CLIENT · JSON

{
  "mcpServers": {
    "kubernetools": {
      "url": "http://localhost:3000/?version=v1.36",
      "headers": {
        "Authorization": "Bearer mykey"
      }
    }
  }
}

mykey in the Authorization header is the key you wrote into keys.json in step 1, and ?version=v1.36 has to be one of the versions in K8S_VERSIONS. Started without KEY_STORE_PATH (anonymous mode), the server needs no header.

kubernetools MCP