What can you do with this server?

A read-only kubectl helper that exposes Kubernetes cluster inspection to Claude Code via MCP, returning structured JSON instead of raw text tables. Tools: * k8s_triage ⭐ — One-shot cluster health diagnostic: fans out concurrent kubectl calls to surface problem pods, recent warning events, unhealthy nodes, and stale deployments. Best starting point for "what's broken?" questions. * k8s_inventory ⭐ — One-shot comprehensive cluster snapshot replacing ~50 individual k8s_get calls. Returns nodes, namespaces, workloads, services, ingresses, HPAs, PVCs, jobs, cronjobs, and optionally Istio CRDs and config resources. Supports full (expanded) or overview (counts only) modes. * k8s_get — List or fetch Kubernetes resources (pods, services, deployments, statefulsets, daemonsets, configmaps, secrets, nodes, ingresses, HPAs, PVCs, jobs, cronjobs, Istio CRDs) with summarized key fields; supports filtering by namespace, name, or label selector. * k8s_describe — Detailed kubectl describe output for a single resource — events, conditions, container details, volume mounts, image pull state (truncated to ~30 KB). * k8s_logs — Fetch pod logs with configurable tail lines (up to 1000), time-based filtering (since), specific container targeting, and previous crashed instance retrieval; capped at ~50 KB. * k8s_events — List recent cluster events (most recent first), filterable by namespace, involved object kind/name, and recency window; useful for scheduling failures, image pull errors, OOMKills, etc. Safety boundaries: * Strictly read-only — only get, describe, and logs verbs; no create, delete, apply, patch, scale, or exec. * Input validation via regex for names, namespaces, and selectors; shell=False to prevent injection. * ConfigMap data and Secret values are never returned — metadata only. * 30-second kubectl timeout; output size caps (30 KB describe, 50 KB logs). * Multi-cluster support via per-server KUBECONFIG environment variables.

Which integrations are available for this server?

Provides read-only access to Istio resources (gateways, virtual services, destination rules) within a Kubernetes cluster for diagnostics and monitoring.

kops

by kaka-milan-22

Overview Schema Related Servers Score Discussions

Python

Local

kops

Read-only kubectl helper exposed to Claude Code via MCP. Six tools, all strictly read-only — verbs (get, describe, logs) are hardcoded; user input only fills argument values, never the verb itself.

kops quickstart

Tool	What it does
`k8s_get`	List/fetch resources, returns summarized key fields per kind
`k8s_describe`	`kubectl describe` text output for one resource
`k8s_logs`	Pod logs with `tail` / `since` / `previous` flags
`k8s_events`	Recent events filtered by namespace / kind / name
`k8s_triage`	⭐ One-shot cluster health scan — start here for diagnostics
`k8s_inventory`	⭐ One-shot comprehensive snapshot — start here for documentation / audits

Why

kubectl over Bash gives Claude text tables that need re-parsing every turn. Wrapping it as MCP returns structured JSON Claude can reason over directly — fewer tokens, fewer parse errors, and built-in safety boundaries (read-only verbs, name validation, output size caps).

Two aggregator tools (k8s_triage, k8s_inventory) compress common multi-step queries into single round-trips:

k8s_triage — "what's broken?" → 4 concurrent kubectl calls, returns problem pods + warning events + unhealthy nodes + stale deployments
k8s_inventory — "show me everything" → 14+ concurrent kubectl calls, returns cluster-wide snapshot grouped by namespace. Replaces ~50 individual k8s_get calls (~6× faster end-to-end for cluster docs).

Related MCP server: Kubernetes Tools MCP Server

Install

Requires uv and kubectl in your PATH.

git clone https://github.com/kaka-milan-22/kops.git
cd kops
uv sync

The commands below use /path/to/kops for the absolute path of this clone — replace it with your actual path (e.g. the output of pwd run from inside the cloned directory). uv --directory needs an absolute path.

Smoke test (no cluster needed)

MCP requires a handshake (initialize → notifications/initialized) before any business request, so a bare tools/list over stdin is rejected with Received request before initialization was complete. Feed all three messages in order:

{
  printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"smoke","version":"0"}}}'
  printf '%s\n' '{"jsonrpc":"2.0","method":"notifications/initialized"}'
  printf '%s\n' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
} | uv run kops

Expect: an initialize response, then a tools/list response listing the 6 tools with input schemas. (The notification has no id and produces no reply.)

Visual debug with MCP Inspector

For interactive debugging, skip the raw stdio dance and use the official tools — they handle the handshake for you:

# Option A: MCP Inspector (browser UI)
npx @modelcontextprotocol/inspector uv --directory /path/to/kops run kops

# Option B: mcp dev (bundled with the mcp[cli] extra already in deps)
uv run mcp dev src/kops/server.py

Open the URL each prints, click a tool, exercise its parameters.

Register with Claude Code

claude mcp add -s user kops -- uv --directory /path/to/kops run kops

Or manually in ~/.claude.json under mcpServers:

{
  "mcpServers": {
    "kops": {
      "command": "uv",
      "args": ["--directory", "/path/to/kops", "run", "kops"]
    }
  }
}

Reload Claude Code (or open a new session). Tools surface as mcp__kops__k8s_get, mcp__kops__k8s_triage, mcp__kops__k8s_inventory, etc.

Multi-cluster (kubeconfig isolation)

To talk to a foreign cluster without polluting ~/.kube/config, register a separate server entry with its own KUBECONFIG:

claude mcp add -s user -e KUBECONFIG=/path/to/qa-cluster.yaml \
  kops-qa -- uv --directory /path/to/kops run kops

Tools then surface as mcp__kops_qa__k8s_triage etc, fully isolated.

End-to-end smoke (with a kind cluster)

kind create cluster --name kops-test
kubectl run broken --image=nonexistent:fake --restart=Never
sleep 30

Then in Claude Code, ask: "this cluster has problems, what's wrong?"

Expected: Claude calls mcp__kops__k8s_triage first, sees the broken pod in ImagePullBackOff, then k8s_describe for root cause.

For a documentation example, ask: "give me a full report of this cluster".

Expected: Claude calls mcp__kops__k8s_inventory once and assembles a structured markdown report covering nodes, namespaces, workloads, services, exposure surface, and configuration counts.

What `k8s_get` returns per kind

_summarize_resource extracts only the fields most useful for diagnostics and documentation. Avoids dumping full spec to keep token usage sane.

Kind	Summarized fields
Pod	`phase`, `ready`, `restarts`, `node`, `podIP`, `images`, `containerCount`, `resources` (when declared), `reason` (when stuck)
Service	`type`, `clusterIP`, `externalIPs`, `loadBalancer`, `ports[]` (incl. `nodePort`)
Deployment	`desired`, `available`, `updated`, `ready`, `images`, `containerCount`, `resources`
StatefulSet / DaemonSet / ReplicaSet	`desired`, `ready`, `images`, `containerCount`, `resources`
Node	`ready`, `kubeletVersion`, `internalIP`, `pressures` (only if any are True)
Ingress	`hosts[]`
Namespace / generic	`name`, `namespace`, `kind`, `age`, `labels` (top 5)

Where resources is the sum across all main containers of requests and limits (init containers excluded — they don't run concurrently with steady state, so don't add to scheduling footprint). CPU normalized to millicores, memory normalized to binary units (Ki/Mi/Gi). Init containers still appear in images[] with an init: True flag.

What `k8s_inventory` returns

{
  "summary": {
    "scope": "cluster-wide" | "namespace=<name>",
    "namespaces": int, "nodes": int, "pods_total": int,
    "by_kind_counts": {"deployments": N, "services": N, ...},
    "istio_present": bool,
    "include_istio": bool,
  },
  "nodes": [<summarized node>, ...],         # cluster-scoped only
  "namespaces": [
    {
      "name": "...", "age": "...", "labels": {...},
      "pods": int,                            # count only (full pod list not included)
      "deployments": [<summarized>, ...],
      "statefulsets": [...], "daemonsets": [...],
      "services": [...], "ingresses": [...], "hpa": [...],
      "pvcs": [...], "configmaps": [...], "secrets": [...],
      "jobs": [...], "cronjobs": [...],
      "istio_gateways": [...], "istio_virtualservices": [...], "istio_destinationrules": [...],
    },
    ...
  ]
}

ConfigMap data and Secret values are never returned — only metadata (names, key lists, age). This is a hard safety boundary; if you need actual config content, go through Bash + kubectl under explicit permission.

Pods are not included as a list (potentially huge). Use k8s_triage for pod health, k8s_get pod for specific pods.

Safety

Mutation defense: verb is hardcoded inside each tool function. User input only fills argument values, never the verb. There is no path to delete / apply / patch / scale / exec from any input.
Injection defense: subprocess.run([...], shell=False) everywhere. Names/namespaces/containers validated against ^[a-zA-Z0-9._-]{1,253}$. Selectors validated against a K8s label-selector character set.
Resource limits: kubectl invoked with 30s timeout. Log tail clamped to 1000 lines. Output size capped (30KB describe, 50KB logs).
Context isolation: default uses kubectl config current-context. The optional context argument can override but cannot inject a KUBECONFIG path. For full isolation across clusters, register a separate MCP server entry with its own KUBECONFIG env var.

Extending

Add another tool by writing a new @mcp.tool() function in src/kops/server.py:

Hardcode the verb.
Validate inputs with the existing helpers (_validate_kind, _validate_name, _validate_selector, _validate_since).
Call kubectl via _run_kubectl([...]).
Reuse _summarize_resource for output shaping if your tool returns resources.
Type hints on the function signature become the JSON-RPC input schema automatically (FastMCP handles this).

For aggregator tools (triage / inventory style), follow the pattern: build a list of kubectl get -A -o json arg vectors, fan out via ThreadPoolExecutor(max_workers=8), post-process and group locally. CRD detection is graceful — wrap the per-kind kubectl call in a try/except RuntimeError and skip absent kinds silently.

Available Tools

6 tools

k8s_describeA

Describe a single K8s resource (text output from kubectl describe).

Read-only: runs kubectl describe only — never mutates the cluster, idempotent. Requires read access to the resource; raises on kubectl failure (e.g. NotFound, Forbidden). Returns human-readable TEXT (not JSON), truncated to ~30 KB. Use when k8s_get isn't enough — describe shows events, conditions, container details, volume mounts, image pull state, etc.

Args: kind: Resource kind. name: Resource name (required). namespace: Target namespace. context: kubeconfig context.

ParametersJSON Schema

Name	Required	Description
`kind`	Yes	Resource kind (singular, plural, or short alias), same set as k8s_get (e.g. pod, deploy, svc, node, ingress). Required.
`name`	Yes	Exact resource name. Required, no glob/partial matching. Must match ^[a-zA-Z0-9._-]{1,253}$.
`context`	No	kubeconfig context name; omit to use the current context.
`namespace`	No	Target namespace. Omit for cluster-scoped kinds (e.g. node) or to use the default namespace. Must match ^[a-zA-Z0-9._-]{1,253}$.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It clearly states the tool is read-only, idempotent, runs kubectl describe, never mutates the cluster, requires read access, and raises on kubectl failure (e.g., NotFound, Forbidden). It also notes the output is truncated text (~30 KB).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. The first two lines state purpose and key characteristics, followed by a bullet list of arguments. Every sentence adds value, with no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, output schema exists, sibling tools present), the description is complete. It covers when to use, behavioral traits, parameter semantics, and output format. No gaps are evident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining the kind parameter is the same set as k8s_get, the name is required with no glob/partial matching, and context/namespace can be omitted for current context or cluster-scoped kinds. This provides helpful usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description begins with a clear statement of purpose: 'Describe a single K8s resource (text output from kubectl describe).' It then notes it is read-only and idempotent, distinguishing it from mutation tools. The sibling tools include k8s_get, and the description explicitly says 'Use when k8s_get isn't enough,' providing clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Use when k8s_get isn't enough — describe shows events, conditions, container details, volume mounts, image pull state, etc.' It also notes it requires read access and raises on failure, guiding the agent on preconditions and errors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

k8s_eventsA

List recent K8s events, most recent first.

Read-only: lists events only — never mutates the cluster, idempotent. Requires read access to events; raises on kubectl failure. Use this to surface scheduling failures, image pull problems, OOMKilled, network issues, etc. Filter by namespace and/or involved object.

Args: namespace: Target namespace; omit for cluster-wide. kind: Filter by involvedObject.kind (e.g. "Pod"). name: Filter by involvedObject.name (use with kind). since: Look-back window (default "30m"). Format: "Ns", "Nm", "Nh", "Nd". context: kubeconfig context.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No	Filter by involvedObject.kind, capitalized as K8s reports it (e.g. "Pod", "Node", "Deployment"). Omit for all kinds.
`name`	No	Filter by involvedObject.name. Use together with `kind` to target one object's events.
`since`	No	Recency window, format ^\d+[smhd]$ (e.g. "30m", "1h", "2d"). Default "30m".	30m
`context`	No	kubeconfig context name; omit to use the current context.
`namespace`	No	Target namespace. Omit for cluster-wide events.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states it is read-only, idempotent, and never mutates the cluster. It also notes requires read access and raises on kubectl failure. With no annotations provided, the description fully covers behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It starts with the main purpose, then provides key traits, use cases, and a clear argument list. Every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters (all optional), 100% schema coverage, and an output schema, the description provides sufficient guidance to use the tool effectively. It covers purpose, behavior, error conditions, and parameter usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context: namespace ('omit for cluster-wide'), kind ('capitalized as K8s reports it'), name ('use with kind'), since (format and default), context ('omit to use current context'). This enriches understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists recent K8s events, most recent first. It specifies it is read-only and lists events only, effectively distinguishing it from sibling tools like k8s_get or k8s_describe. The purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear use cases (scheduling failures, image pull problems, etc.) and explains that events can be filtered by namespace and involved object. However, it does not explicitly mention when not to use this tool versus alternatives, which would strengthen guidance further.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

k8s_getA

List or fetch K8s resources, returning summarized key fields per resource.

Read-only: runs kubectl get -o json only — never creates, mutates, or deletes anything, and is safe to call repeatedly (idempotent). Requires a kubeconfig with read/list access to the target kind/namespace; raises on kubectl failure (e.g. NotFound, Forbidden, unreachable cluster). Output is summarized (not raw spec) to keep tokens low; Secret/ConfigMap values are never included. For deeper detail (events, conditions, container info), use k8s_describe.

Args: kind: Resource kind. Common: pod, svc, deploy, sts, ds, cm, secret, ns, node, ingress, gateway, virtualservice, destinationrule, hpa, pvc. namespace: Target namespace; omit to scan all namespaces. name: Specific resource name; omit to list multiple. selector: K8s label selector, e.g. "app=foo,env=prod". context: kubeconfig context to use; defaults to current context.

ParametersJSON Schema

Name	Required	Description
`kind`	Yes	Resource kind (singular, plural, or short alias). Accepted: pod/po, svc/service, deploy/deployment, sts/statefulset, ds/daemonset, rs/replicaset, cm/configmap, secret, ns/namespace, node, ingress, hpa, pvc, job, cronjob, sa/serviceaccount, and the Istio kinds gateway/virtualservice/destinationrule. Other lowercase kinds are passed through. Secret/ConfigMap VALUES are never returned — metadata only.
`name`	No	Exact resource name to fetch one item. Omit to list many. Must match ^[a-zA-Z0-9._-]{1,253}$. No partial/glob matching.
`context`	No	kubeconfig context name. Omit to use the current context. Cannot inject a KUBECONFIG path.
`selector`	No	K8s label selector, comma-separated, e.g. "app=foo,env=prod" or "tier!=cache". Ignored when `name` is given.
`namespace`	No	Target namespace. Omit to scan ALL namespaces (adds -A). Must match ^[a-zA-Z0-9._-]{1,253}$.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: read-only (runs kubectl get -o json only), idempotent, never creates/mutates/deletes, returns summarized output, excludes Secret/ConfigMap values, and raises on failures. This is comprehensive and exceeds the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with purpose then behavioral details, followed by parameter list. It is informative yet concise, though some redundancy exists (e.g., repeating namespace pattern) that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, 100% schema coverage, and presence of output schema, the description is complete. It covers behavior, permissions, limitations, output format, and cross-references sibling tools, leaving no significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds some context (e.g., common kind examples, effect of omitting namespace/name, selector ignored when name given) but does not significantly extend beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists or fetches K8s resources (specific verb+resource) and summarizes key fields. It differentiates from the sibling k8s_describe by noting that k8s_get provides summarized output while k8s_describe offers deeper detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use (read-only operations), that it is safe to call repeatedly, and provides clear alternative: for deeper detail use k8s_describe. It also notes prerequisites (kubeconfig with read/list access) and error conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

k8s_inventoryA

⭐ One-shot comprehensive cluster snapshot. Use for documentation, audits, or any task that needs broad visibility — replaces ~50 individual k8s_get calls.

Read-only: fans out many kubectl get -o json calls only — never mutates the cluster, idempotent. Requires broad read access (or read on the given namespace); kinds that are Forbidden/absent are skipped silently rather than failing the whole call. Pods are excluded from the payload (counts only).

Modes:

"full" (default): expand each namespaced item to its summarized form (deployment images, service ports, etc.). Use for documentation or audits.
"overview": skip per-item expansion. Each namespace entry carries only a by_kind_counts map. ~10-20× smaller payload. Use to scan cluster shape before drilling in with namespace-scoped follow-up calls.

By default, ConfigMap and Secret lists are EXCLUDED — they are typically the largest noise-to-signal source in cluster-wide inventories. Set include_config_resources=True to include them in by_kind_counts and the per-namespace breakdown. ConfigMap data and Secret values are NEVER returned — only metadata.

Pods are NOT included in the snapshot (potentially huge); only per-namespace pod counts are surfaced. Use k8s_triage for pod health, k8s_get pod for specifics.

Istio CRDs (Gateway / VirtualService / DestinationRule) are auto-included when present; absent CRDs are silently skipped. Set include_istio=False to skip.

Args: namespace: Limit scope to a single namespace; omit for cluster-wide. mode: "full" (default, expand items) or "overview" (counts only). include_config_resources: Include ConfigMaps and Secrets (default False). include_istio: Auto-detect and include Istio CRDs (default True). context: kubeconfig context.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Detail level. "full" (default) expands each item to summarized fields; "overview" returns per-namespace by_kind_counts only (~10-20× smaller). Only these two values are accepted.	full
`context`	No	kubeconfig context name; omit to use the current context.
`namespace`	No	Limit the snapshot to one namespace; omit for a cluster-wide snapshot.
`include_istio`	No	Auto-detect and include Istio CRDs (Gateway/VirtualService/DestinationRule) when present. Default true; absent CRDs are skipped.
`include_config_resources`	No	Include ConfigMaps and Secrets in counts and per-namespace breakdown. Default false (they are the biggest noise source). Values are NEVER returned either way — metadata only.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses read-only behavior, idempotency, silent skipping of forbidden/absent resources, exclusion of pods (counts only), and that ConfigMap/Secret values are never returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, front-loaded with purpose and key constraints. Slightly verbose but every sentence contributes; minor redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 5-parameter tool with no output schema, the description covers all relevant behavioral details, modes, exclusions, defaults, and edge cases, making it complete for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant value: explains mode payload sizes, reasons for default exclusion of config resources, and behavior of Istio auto-detection, all beyond basic schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'One-shot comprehensive cluster snapshot' for documentation/audits, and explicitly differentiates from sibling tools like k8s_triage (pod health) and k8s_get (specifics).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (broad visibility, audits) and when-not (pod specifics), includes mode guidance ('full' vs 'overview'), and references specific alternatives (k8s_triage, k8s_get).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

k8s_logsA

Fetch logs from a pod.

Read-only: runs kubectl logs only — never mutates the cluster, idempotent. Requires read access to pod logs; raises on kubectl failure (e.g. pod NotFound, container not yet started, Forbidden). Output is truncated to ~50 KB.

Args: pod: Pod name (required). namespace: Target namespace. container: Container name in multi-container pods. tail: Lines from the tail (default 100, hard max 1000). since: Look-back window like "5m", "1h"; only logs newer than this. previous: If True, fetch the previous container instance's logs (post-crash). context: kubeconfig context.

ParametersJSON Schema

Name	Required	Description
`pod`	Yes	Pod name (required, exact match, ^[a-zA-Z0-9._-]{1,253}$).
`tail`	No	Number of lines from the end of the log. Default 100; clamped to 1..1000 (values above 1000 are capped).
`since`	No	Only logs newer than this relative window. Format ^\d+[smhd]$ (e.g. "5m", "1h", "2d"). Omit for no time bound.
`context`	No	kubeconfig context name; omit to use the current context.
`previous`	No	If true, fetch the PREVIOUS (crashed/restarted) container instance's logs — use to debug a CrashLoopBackOff. Default false.
`container`	No	Container name — required only for multi-container pods; omit for single-container pods.
`namespace`	No	Target namespace; omit to use the default namespace.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully covers behavior: idempotent, non-mutating, output truncated to ~50 KB, and raises errors on kubectl failures. This is comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and safety, but the bulleted Args list is somewhat redundant with the schema. It could be trimmed, but it's not excessively long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no annotations, but an output schema exists, the description covers errors, truncation, idempotency, and usage constraints. It is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds minimal new meaning. The Args section mostly restates schema info. Some nuance like 'hard max 1000' is present but also in schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Fetch logs from a pod' and emphasizes it is read-only and idempotent, distinguishing it from sibling tools like k8s_describe or k8s_get. The verb and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use (for pod logs) and provides error conditions (pod NotFound, Forbidden). It lacks explicit when-not or alternatives, but the context is clear given sibling tools have distinct purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

k8s_triageA

⭐ Start here for cluster diagnostics. Single call returns: problem pods, recent warning events, unhealthy nodes, and stale deployments.

Read-only: fans out several kubectl get calls only — never mutates the cluster, idempotent. Requires read access cluster-wide (or to the given namespace); individual sub-queries that are Forbidden/absent are skipped rather than aborting. Use this as the FIRST tool for broad questions like "what's wrong with this cluster", "anything broken", or "give me a health summary", then dig deeper with k8s_describe / k8s_logs / k8s_events.

Args: namespace: Limit scope to a single namespace; omit for cluster-wide. since: Event recency window (default "1h"). Format: "Ns", "Nm", "Nh", "Nd". context: kubeconfig context.

ParametersJSON Schema

Name	Required	Description	Default
`since`	No	Warning-event recency window, format ^\d+[smhd]$ (e.g. "1h", "30m", "1d"). Default "1h".	1h
`context`	No	kubeconfig context name; omit to use the current context.
`namespace`	No	Limit the scan to one namespace; omit for cluster-wide triage.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only nature ('fans out several kubectl get calls only — never mutates the cluster, idempotent'), permission requirements, and error behavior ('Forbidden/absent are skipped rather than aborting'). No annotations provided, but description carries full burden effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise and well-structured: star emoji + bold header, bullet list of returns, behavioral paragraph, usage guidance, and parameter details. Every sentence adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 optional parameters and no output schema, description adequately explains what the tool returns (four categories) and how to use it. All necessary context (permissions, idempotency, error handling) is included.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 3 parameters with descriptions (100% coverage). Description's Args section adds default values, format constraints (e.g., '1h', '30m'), and clarifies namespace scoping. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description starts with 'Start here for cluster diagnostics' and lists specific outputs (problem pods, warning events, unhealthy nodes, stale deployments). It distinguishes itself from siblings by stating it's the first tool for broad questions, then deeper with k8s_describe/k8s_logs/k8s_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance: 'Use this as the FIRST tool for broad questions... then dig deeper with k8s_describe / k8s_logs / k8s_events.' Also states read-only and cluster-wide read access needed, with graceful handling of forbidden sub-queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool serves a distinct read-only purpose: describe details, list events, get summarized resources, inventory cluster snapshot, fetch logs, and triage diagnostics. No overlap.

Naming Consistency5/5

All tools follow the consistent pattern 'k8s_<verb or noun>' using lowercase and underscores. While some names are nouns (events, inventory, triage), they clearly describe the action and maintain alignment.

Tool Count5/5

With 6 tools, the set is well-scoped for a Kubernetes read-only diagnostic server, covering the essential operations without being over- or under-inclusive.

Completeness5/5

The tool set comprehensively addresses common diagnostic tasks: listing, describing, logs, events, inventory, and triage. No obvious gaps for read-only operations.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
Google GKE A
com.googleapis.container
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
Cloud Platforms Virtualization Observability
232
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2

Related MCP Servers

mcp-kubernetes-ro
Monitoring Cloud Platforms Developer Tools
patrickdappollonio
A
license
Not graded
quality
B
maintenance
Provides read-only access to Kubernetes clusters for AI assistants.
Updated 3 months ago (2026-06-17 18:01 UTC)
23
MIT
Kubernetes Tools MCP Server
Code Execution Developer Tools Observability
BenedatLLC
A
license
A
quality
C
maintenance
Provides a set of read-only Kubernetes functions via an MCP server, enabling interaction with Kubernetes clusters through agents or coding assistants like GitHub Copilot.
Updated 5 days ago (2026-08-30 17:59 UTC)
9
3
Apache 2.0
kubeview-mcp
Cloud Platforms Monitoring Code Execution
mikhae1
A
license
A
quality
B
maintenance
Read-only MCP server for safe Kubernetes inspection, diagnosis, and debugging. Supports Kubernetes core, Helm, Argo Workflows, and Argo CD.
Updated 23 days ago (2026-08-12 18:40 UTC)
2
126
5
MIT
k8s-readonly-mcp
Cloud Platforms Monitoring
ziyuyu23
A
license
A
quality
C
maintenance
A read-only MCP server for inspecting Kubernetes clusters, allowing LLMs to list resources, describe pods, and read logs without mutation.
Updated a month ago (2026-07-21 17:44 UTC)
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kaka-milan-22/kops'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

kops

Why

Install

Smoke test (no cluster needed)

Visual debug with MCP Inspector

Register with Claude Code

Multi-cluster (kubeconfig isolation)

End-to-end smoke (with a kind cluster)

What k8s_get returns per kind

What k8s_inventory returns

Safety

Extending

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

What `k8s_get` returns per kind

What `k8s_inventory` returns