Which integrations are available for this server?

Exposes a Kubernetes cluster to MCP-compatible AI clients, providing tools for listing contexts, namespaces, pods, deployments, nodes, events, and more. Supports write operations (apply, patch, delete, scale, rollout) and exec commands when enabled.

How do I use kubeaid-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kubeaid-mcp list pods in the default namespace" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kubeaid-mcp

by 1Shubham7

Overview Schema Related Servers Score Discussions

TypeScript

Local

kubeaid-mcp

An MCP (Model Context Protocol) server that exposes a Kubernetes cluster to any MCP-compatible AI client (Claude Code, Claude Desktop, Cursor, ...). The client launches the server as a subprocess and talks to it over stdio (JSON-RPC 2.0); the server translates tool calls into Kubernetes API calls via @kubernetes/client-node.

Built in TypeScript on the NitroStack MCP framework.

See design.md for the architecture.

Demo

kubeaid-mcp demo

Related MCP server: MCP Remote Server for Kubernetes

Tools

Tool	Description
`list_contexts`	List the kubeconfig contexts (clusters) the server can target.
`list_namespaces`	List namespaces in a cluster, with status.
`list_pods`	List pods in a namespace (or all namespaces), with derived status, ready count, restarts and age.
`describe_pod`	Pod status, per-container state (waiting/termination reasons, last restart), and recent events.
`get_pod_logs`	Tail a container's logs; `previous: true` reads a crashed instance's prior logs.
`list_deployments`	List deployments with ready/up-to-date/available replica counts and age.
`list_nodes`	List cluster nodes with Ready status, roles, version and internal IP.
`get_events`	Recent events in a namespace (or all), sorted oldest to newest.
`describe_resource`	Fetch any resource kind (incl. CRDs) by kind/plural/short-name and name.

Every tool accepts an optional context argument to target a specific kubeconfig context. Omit it to use the server's default context.

Write tools (opt-in)

These are registered only when KUBEAID_ALLOW_WRITES=true. Each accepts an optional dry_run to simulate the change server-side without persisting it.

Tool	Description
`apply_manifest`	Create or update resources from a YAML/JSON manifest (server-side apply).
`patch_resource`	Patch an existing resource (strategic / merge / json).
`delete_resource`	Delete a resource by kind and name.
`scale_deployment`	Set a deployment's replica count.
`rollout_restart`	Rolling-restart a deployment/statefulset/daemonset.
`exec_command`	Run a command inside a container (only with `KUBEAID_ALLOW_EXEC=true`).

Prompts

Prompts are user-invoked workflow templates (surfaced as slash commands / menu items in the client). Unlike tools, a prompt does not touch the cluster — it returns a message that guides the model through a task using the tools above.

Prompt	Arguments	What it does
`diagnose_pod`	`namespace`, `pod_name`, `context?`	Walk through describe → logs to find why a pod is unhealthy and suggest a fix.
`triage_namespace`	`namespace`, `context?`	Find every unhealthy workload in a namespace and investigate each.
`cluster_health_check`	`context?`	High-level health sweep: nodes, pods across all namespaces, recent warnings.
`review_warnings`	`namespace?`, `context?`	Review recent Warning events and explain what they mean.

Installation

Requires Node.js 20+. Build the server once, then register it with your AI client(s).

1. Build the server

git clone https://github.com/1shubham7/kubeaid-mcp-ts.git
cd kubeaid-mcp-ts
npm install
npm run build        # compiles TypeScript to dist/ (entry: dist/index.js)

Note the absolute path to the entry point — the AI clients need it:

echo "$(pwd)/dist/index.js"

For local iteration you can also run npm run dev (NitroStack's dev server with hot reload), which is handy with NitroStudio as a visual MCP client.

2. Register with Claude Code

claude mcp add kubeaid -- node "$(pwd)/dist/index.js"

With no KUBEAID_CONTEXT set, the server follows your kubeconfig's current-context live, so kubectl config use-context <name> switches the target cluster without re-registering. Pin a fixed default by adding -e KUBEAID_CONTEXT=kind-kubeaid if you'd rather it never move.

Read tools only are exposed by default. To enable the mutating tools (apply/patch/delete/scale/rollout), pass -e KUBEAID_ALLOW_WRITES=true, and list any production contexts as protected so they can never be written to:

claude mcp add kubeaid \
  -e KUBEAID_ALLOW_WRITES=true \
  -e KUBEAID_PROTECTED_CONTEXTS=prod-cluster,another-prod-cluster \
  -- node "$(pwd)/dist/index.js"

3. Register with Claude Desktop

Recent Claude Desktop builds gate local MCP servers behind a setting, so order matters:

Enable local MCP: Settings → Developer → Local MCP servers. Local stdio servers are off by default; opening/enabling this is required.
Edit the config: on that page click Edit Config — it opens the file the app actually reads (~/.config/Claude/claude_desktop_config.json on Linux; macOS ~/Library/Application Support/Claude/; Windows %APPDATA%\Claude\). Add a top-level mcpServers key, using the absolute path from step 1:
```
{
  "mcpServers": {
    "kubeaid": {
      "command": "node",
      "args": ["/home/you/kubeaid-mcp-ts/dist/index.js"]
    }
  }
}
```
If the file already has other keys (e.g. preferences), keep them and add mcpServers alongside — don't overwrite the file.
Fully quit and reopen Claude Desktop. Closing the window is not enough on Linux — the process must actually exit. The server then appears under Settings → Developer → Local MCP servers.

Enabling writes: add the options via an env block — e.g. make the local cluster writable while protecting production:

{
  "mcpServers": {
    "kubeaid": {
      "command": "node",
      "args": ["/home/you/kubeaid-mcp-ts/dist/index.js"],
      "env": {
        "KUBEAID_CONTEXT": "kind-kubeaid",
        "KUBEAID_ALLOW_WRITES": "true",
        "KUBEAID_PROTECTED_CONTEXTS": "prod-cluster,another-prod-cluster"
      }
    }
  }
}

Add "KUBEAID_ALLOW_EXEC": "true" for the exec_command tool, and re-run step 3 after changing the config.

Notes:

command/args must use absolute paths; GUI apps don't inherit your shell PATH, and Node needs the absolute path to dist/index.js.
Destructive tools carry a destructiveHint, so Desktop still prompts you per action — the env vars control what's possible; the prompt is your confirmation.
If your account is enterprise-managed, an admin policy can disable local MCP entirely, in which case no local config will load.

Safety

The server is read-only by default — the read tools only call non-mutating verbs (get, list, watch, log). Mutating tools exist but are gated:

KUBEAID_ALLOW_WRITES=true must be set for apply_manifest, patch_resource, delete_resource, scale_deployment, and rollout_restart to be exposed at all.
KUBEAID_ALLOW_EXEC=true (in addition) is required for exec_command.
KUBEAID_PROTECTED_CONTEXTS lists contexts that may never be written to or exec'd into, even with the flags above — put your production contexts here.
Tools are annotated (readOnlyHint / destructiveHint) so clients can prompt before risky actions.

The server authenticates with your kubeconfig credentials, so it can only do what your account is already permitted to do.

Configuration

All configuration is read from the environment at startup. An MCP client passes these via the server entry's env block (Claude Desktop) or -e flags (Claude Code). A local .env file also works for development — see .env.example.

Variable	Default	Meaning
`KUBECONFIG`	`~/.kube/config`	Path to the kubeconfig file.
`KUBEAID_CONTEXT`	follows kubeconfig current-context (live)	Pin a fixed default context. Omit it to track current-context live, so `kubectl config use-context` switches the cluster mid-session. Individual tool calls can always override it.
`KUBEAID_REQUEST_TIMEOUT`	`30s`	Per-request timeout for Kubernetes API calls (e.g. `30s`, `1m`, or milliseconds).
`KUBEAID_ALLOW_WRITES`	`false`	Expose the mutating tools (apply/patch/delete/scale/rollout).
`KUBEAID_ALLOW_EXEC`	`false`	Expose `exec_command` (run commands in containers).
`KUBEAID_PROTECTED_CONTEXTS`	none	Comma-separated contexts that may never be written to or exec'd into.

Development

Drive the server by hand (no AI client needed) to inspect the raw protocol and confirm which tools are registered:

npm run build
KUBECONFIG=~/.kube/config node scripts/drive.mjs   # initialize + tools/list + prompts/list

Available Tools

9 tools

describe_podA

Read-only

Describe a pod: its status, per-container state (including waiting/termination reasons and last restart), and recent events. Use this to diagnose why a pod is not healthy.

ParametersJSON Schema

Name	Required	Description
`context`	No	kubeconfig context (cluster) to target; omit to use the default context
`pod_name`	Yes	name of the pod
`namespace`	Yes	namespace of the pod

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds value by detailing the return content (status, container state, events, termination reasons). No contradictions found.

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?

Two sentences, each providing distinct value: scope and use case. No filler, front-loaded with the action.

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

Completeness4/5

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

No output schema, but the description adequately explains return values (status, container state, events). It covers the essential diagnostic information needed for the tool.

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 coverage is 100% with descriptions for all 3 parameters. The description adds no extra meaning beyond the schema, meeting the baseline.

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 'Describe a pod' with specific details (status, container state, events) and a diagnostic purpose. It distinguishes from siblings like 'describe_resource' and 'get_events'.

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?

Explicitly says 'Use this to diagnose why a pod is not healthy', providing a clear use case. It doesn't mention when not to use, but the context of sibling tools offers alternatives.

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

describe_resourceA

Read-only

Fetch any Kubernetes resource by kind and name, including custom resources (CRDs). Returns the resource object with noise (managedFields, last-applied annotation) stripped.

ParametersJSON Schema

Name	Required	Description
`kind`	Yes	resource kind, plural, or short name (e.g. Deployment, deployments, deploy)
`name`	Yes	name of the resource
`context`	No	kubeconfig context (cluster) to target; omit to use the default context
`namespace`	No	namespace for namespaced resources; defaults to "default"
`api_version`	No	optional apiVersion (e.g. apps/v1) to disambiguate a kind or target a CRD

TDQS

A4/5.0

Behavior4/5

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

Discloses noise stripping (managedFields, last-applied annotation) and CRD support, adding value beyond annotations which only state readOnlyHint. No contradictions.

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?

Two sentences with no redundant information. Front-loaded with purpose and key features.

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

Completeness4/5

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

Covers core functionality and output stripping. No output schema, but description gives enough context for a read tool. Could mention error handling.

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 coverage is 100%, so baseline 3. Description does not add extra meaning to parameters beyond what 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?

Clearly specifies 'Fetch any Kubernetes resource by kind and name, including custom resources (CRDs)'. Provides specific verb and resource scope, distinguishing from sibling tools like describe_pod.

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

Usage Guidelines3/5

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

Implies usage for any resource but lacks explicit guidance on when to use vs siblings like describe_pod. No exclusions or alternative mentions.

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

get_eventsA

Read-only

List recent events in a namespace (or across all namespaces if omitted), sorted oldest to newest. Warning-type events surface cluster problems.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	kubeconfig context (cluster) to target; omit to use the default context
`namespace`	No	namespace to get events from; omit for all namespaces

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable context: events are sorted oldest to newest and warning events signal cluster problems, which goes beyond the annotations.

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?

Two front-loaded sentences with zero redundancy, efficiently conveying purpose, scope, ordering, and special behavior.

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

Completeness4/5

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

Given no output schema and simple parameters, the description covers core behavior (events list, sorting, warning significance). Missing details like pagination or filtering but adequate for a read-only list tool.

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 coverage is 100%, baseline is 3. The description reinforces that omitting namespace queries all namespaces, adding slight value but not substantially beyond 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 uses specific verb 'List' and resource 'recent events', clearly differentiating from sibling tools (describe_pod, list_pods, etc.) by focusing on events and their ordering.

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

Usage Guidelines3/5

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

The description implies usage for listing events but does not explicitly provide when-to-use or when-not-to-use guidance compared to other tools. The sibling list helps but the description lacks direct alternative references.

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

get_pod_logsA

Read-only

Fetch the tail of a pod's container logs. Set previous=true to read logs from a crashed container's prior instance.

ParametersJSON Schema

Name	Required	Description
`lines`	No	number of lines from the end of the log to return (default 100)
`context`	No	kubeconfig context (cluster) to target; omit to use the default context
`pod_name`	Yes	name of the pod
`previous`	No	return logs from the previous terminated instance of the container; useful for crash loops
`container`	No	container name; omit for a single-container pod
`namespace`	Yes	namespace of the pod

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds behavioral context for the previous parameter but does not disclose other traits like rate limits or output format. It does not contradict annotations.

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?

Two sentences, front-loaded with the main purpose, no waste. Efficient and to the point.

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

Completeness4/5

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

For a 6-parameter, no-output-schema tool with full schema coverage, the description is sufficient. It covers the essential purpose and a key parameter use. Could mention return format but is acceptable.

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 baseline is 3. The description adds minimal additional meaning beyond repeating what is already in the schema (e.g., 'tail' implied by lines default). No enrichment of parameter semantics.

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 verb 'Fetch' and the resource 'pod's container logs', making the tool's purpose unambiguous. It distinguishes from siblings like describe_pod which provides pod details, not logs.

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 guidance on when to set previous=true for crash logs. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, though the purpose differentiation is implicit.

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

list_contextsA

Read-only

List the kubeconfig contexts (clusters) this server can target. The one marked isDefault is used when a tool call omits the context parameter.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds behavioral context about the isDefault marker affecting other tool calls when context parameter is omitted. No contradictions.

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?

Two concise sentences front-load the purpose and add an important detail. No unnecessary words.

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

Completeness4/5

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

The description covers the main purpose and a key behavioral detail. It could mention output format, but for a simple list tool this is sufficient given the familiar Kubernetes context.

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?

With zero parameters and 100% schema coverage, the description does not need to add parameter info. Baseline 4 is appropriate.

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 lists kubeconfig contexts (clusters) and distinguishes from sibling resource-listing tools like list_pods or list_deployments.

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?

It explicitly states when to use (to see available clusters) and provides context about the isDefault marker, but does not explicitly mention when not to use or alternatives.

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

list_deploymentsA

Read-only

List deployments in a namespace (or across all namespaces if omitted), with ready/up-to-date/available replica counts and age.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	kubeconfig context (cluster) to target; omit to use the default context
`namespace`	No	namespace to list deployments in; omit to list across all namespaces

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, which aligns with the listing operation. The description adds behavioral details such as the return of replica counts and age, enhancing transparency beyond annotations.

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 a single, well-structured sentence that conveys purpose and key details without superfluous words. It is front-loaded with the main action.

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 simple tool (2 optional params, no output schema), the description adequately covers return values (replica counts, age) and usage context. No gaps are apparent.

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 coverage is 100% with clear descriptions for both parameters. The description confirms the schema's info (namespace omission for all, context default) but adds no significant new meaning 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 verb 'list', the resource 'deployments', and the optional scope (namespace or all). It distinguishes from sibling tools like list_pods by specifying the resource type.

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 explains when to omit namespace to list across all namespaces. However, it does not provide explicit guidance on when not to use this tool or mention alternatives like describe_resource.

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

list_namespacesA

Read-only

List all namespaces in the Kubernetes cluster, with their status.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	kubeconfig context (cluster) to target; omit to use the default context

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns status, but it does not elaborate on the status values or any other behavioral traits like pagination or filtering.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose without extraneous words. Every phrase earns its place.

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

Completeness4/5

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

For a simple list tool with full schema coverage and read-only annotations, the description is mostly complete. It specifies 'all namespaces' and 'with their status', though it lacks details on what the status field contains.

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% (the 'context' parameter is fully described in the schema). The tool description does not mention parameters or add any meaning beyond the schema, so baseline 3 is appropriate.

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 specifies the verb 'List' and the resource 'namespaces' in the Kubernetes cluster, adding 'with their status' for extra clarity. It effectively distinguishes from sibling tools like list_pods and list_deployments.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., describe_resource or list_contexts). The description gives no context-specific usage advice or exclusions.

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

list_nodesA

Read-only

List cluster nodes with Ready status, roles, age, kubelet version and internal IP.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	kubeconfig context (cluster) to target; omit to use the default context

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is communicated. Description adds the specific fields returned, enhancing transparency. No mention of pagination or filters, but adequate for a simple list operation.

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?

Single concise sentence that front-loads the purpose and lists key return fields. No wasted words.

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

Completeness4/5

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

With no output schema, the description sufficiently explains return fields. The optional parameter is handled. Sibling tools provide context. Minor gap: no mention of possible filtering or ordering, but adequate for a list operation.

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 coverage is 100% with a well-described optional 'context' parameter. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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 clearly states the verb 'List' and resource 'cluster nodes', and specifies the exact fields returned (Ready status, roles, age, kubelet version, internal IP). This distinguishes it from sibling tools that list other resources (pods, deployments, etc.).

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?

Description implies usage context (when node information is needed), but does not explicitly state when not to use or mention alternatives. Given sibling tools, it is clear this is for nodes, but lacks explicit guidelines.

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

list_podsA

Read-only

List pods in a namespace (or across all namespaces if omitted), with derived status, ready count, restarts and age.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	kubeconfig context (cluster) to target; omit to use the default context
`namespace`	No	namespace to list pods in; omit to list pods across all namespaces

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds that it returns derived status, ready count, etc., which aligns with a read operation. No destructive hints are needed. No contradictions.

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 a single sentence, under 20 words, front-loaded with the action and resource. Every word adds value. No wasted content.

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

Completeness4/5

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

Given no output schema, the description partially describes the output fields (derived status, ready count, restarts, age). It is sufficient for a list tool. Could mention pagination or error handling, but not required for this context.

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 coverage is 100% with both parameters described. The description mentions the namespace behavior (omit for all) which mirrors the schema. It adds no new parameter details beyond the schema, so baseline 3 is appropriate.

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 'List pods', specifies the optional namespace scope, and lists additional derived fields (status, ready count, restarts, age). This distinguishes it from siblings like describe_pod and get_pod_logs.

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 context for when to use (list pods in a namespace or all). It implicitly guides the agent by contrasting with siblings (e.g., describe_pod for single pod details). However, it does not explicitly state when not to use or list alternatives.

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.2/5.0

Disambiguation5/5

Every tool targets a distinct Kubernetes resource or action (e.g., describe_pod vs describe_resource, list_pods vs list_deployments), with no overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase and underscores (e.g., list_pods, get_events, describe_resource), making them predictable and easy to differentiate.

Tool Count5/5

With 9 tools, the surface is lean yet comprehensive for a diagnostic Kubernetes MCP server, covering essential inspection operations without unnecessary bloat.

Completeness4/5

The tool set covers core diagnostic workflows—listing, describing, logs, events—but misses operational actions like exec, port-forward, or resource creation. Minor gap given the diagnostic focus.

Maintenance

ActivityStale

ResponsivenessSyncing

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

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
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
Quallaa
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1

Related MCP Servers

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 4 days ago (2026-08-30 17:59 UTC)
9
3
Apache 2.0
MCP Remote Server for
Cloud Platforms Developer Tools App Automation
huchunlinnk
A
license
Not graded
quality
D
maintenance
Provides Kubernetes cluster management capabilities through natural language via MCP protocol over HTTP/SSE. Supports Pod, Service, Deployment operations, log retrieval, and resource management with JWT authentication and RBAC permissions.
Updated 10 months ago (2025-10-20 07:57 UTC)
1
MIT
mcp-kubernetes-server
Cloud Platforms Developer Tools Command Line
feiskyer
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to interact with Kubernetes clusters by translating natural language into kubectl and Helm operations. It allows users to query, manage, and diagnose Kubernetes resources and cluster states through a seamless integration.
Updated 7 months ago (2026-02-04 05:25 UTC)
20
Apache 2.0
Kubernetes MCP Server – 5G
Monitoring Observability
sanzco
F
license
Not graded
quality
D
maintenance
Exposes Kubernetes cluster state with specialized telecom awareness of 5G Core network functions and topologies to MCP-compatible LLMs. It enables natural language analysis of 5G workloads, network slices, UPF data planes, and cluster health.
Updated 6 months ago (2026-03-16 15:20 UTC)

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/1Shubham7/kubeaid-mcp-ts'

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