The mcp-server-kubernetes allows you to programmatically manage and interact with Kubernetes clusters. Key capabilities include:
Connect to a Kubernetes cluster
List resources such as pods, deployments, services, nodes, namespaces, cronjobs, and events
Describe detailed information about nodes, pods, services, and cronjobs
Create resources including pods (using templates like ubuntu, nginx, busybox, alpine), deployments (with configurable ports and replicas), namespaces, services, ConfigMaps, and cronjobs
Delete specific resources such as pods, services, ConfigMaps, and cronjobs
Update existing resources like deployment replicas, services, and ConfigMaps
Retrieve logs from pods, deployments, jobs, and using label selectors
Manage Helm v3 charts (install, uninstall, upgrade)
Support kubectl commands like explain and api-resources
Perform port forwarding
Clean up all managed resources
Operate in non-destructive mode for read and create/update-only access
Docker support is in progress as mentioned in the 'In Progress' section
Support for Helm to install charts is listed as a planned feature
Allows connecting to a Kubernetes cluster to manage it, including listing, creating, deleting, and describing pods, services, deployments, and namespaces
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-kubernetes list all 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.
MCP Server that can connect to a Kubernetes cluster and manage it. Supports loading kubeconfig from multiple sources in priority order.
https://github.com/user-attachments/assets/f25f8f4e-4d04-479b-9ae0-5dac452dd2ed
Before using this MCP server with any tool, make sure you have:
kubectl installed and in your PATH
A valid kubeconfig file with contexts configured
Access to a Kubernetes cluster configured for kubectl (e.g. minikube, Rancher Desktop, GKE, etc.)
Helm v3 installed and in your PATH (no Tiller required). Optional if you don't plan to use Helm.
You can verify your connection by running kubectl get pods in a terminal to ensure you can connect to your cluster without credential issues.
By default, the server loads kubeconfig from ~/.kube/config. For additional authentication options (environment variables, custom paths, etc.), see ADVANCED_README.md.
Add the MCP server to Claude Code using the built-in command:
claude mcp add kubernetes -- npx mcp-server-kubernetesThis will automatically configure the server in your Claude Code MCP settings.
Add the MCP server to Codex CLI using the built-in command:
codex mcp add kubernetes -- npx mcp-server-kubernetesThis registers the server globally in ~/.codex/config.toml and makes its tools available in all Codex sessions.
Add the following configuration to your Claude Desktop config file:
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": ["mcp-server-kubernetes"]
}
}
}MCP Server Kubernetes is also available as a mcpb (formerly dxt) extension. In Claude Desktop, go to Settings (Cmd+, on Mac) -> Extensions -> Browse Extensions and scroll to find mcp-server-kubernetes in the modal. Install it & it will install & utilize kubectl via command line & your kubeconfig.
To manually install, you can also get the .mcpb by going to the latest Release and downloading it.
For VS Code integration, you can use the MCP server with extensions that support the Model Context Protocol:
Install a compatible MCP extension (such as Claude Dev or similar MCP clients)
Configure the extension to use this server:
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": ["mcp-server-kubernetes"],
"description": "Kubernetes cluster management and operations"
}
}
}Cursor supports MCP servers through its AI integration. Add the server to your Cursor MCP configuration:
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": ["mcp-server-kubernetes"]
}
}
}The server will automatically connect to your current kubectl context. You can verify the connection by asking the AI assistant to list your pods or create a test deployment.
Related MCP server: MCP Kubernetes
mcp-chat is a CLI chat client for MCP servers. You can use it to interact with the Kubernetes server.
npx mcp-chat --server "npx mcp-server-kubernetes"Alternatively, pass it your existing Claude Desktop configuration file from above (Linux should pass the correct path to config):
Mac:
npx mcp-chat --config "~/Library/Application Support/Claude/claude_desktop_config.json"Windows:
npx mcp-chat --config "%APPDATA%\Claude\claude_desktop_config.json"Connect to a Kubernetes cluster
Unified kubectl API for managing resources
Get or list resources with kubectl_get
Describe resources with kubectl_describe
List resources with kubectl_get
Create resources with kubectl_create
Apply YAML manifests with kubectl_apply
Delete resources with kubectl_delete
Get logs with kubectl_logs
Manage kubectl contexts with kubectl_context
Explain Kubernetes resources with explain_resource
List API resources with list_api_resources
Scale resources with kubectl_scale
Update field(s) of a resource with kubectl_patch
Manage deployment rollouts with kubectl_rollout
Execute any kubectl command with kubectl_generic
Verify connection with ping
Advanced operations
Scale deployments with kubectl_scale (replaces legacy scale_deployment)
Port forward to pods and services with port_forward
Run Helm operations
Install, upgrade, and uninstall charts
Support for custom values, repositories, and versions
Template-based installation (helm_template_apply) to bypass authentication issues
Template-based uninstallation (helm_template_uninstall) to bypass authentication issues
Pod cleanup operations
Clean up problematic pods (cleanup_pods) in states: Evicted, ContainerStatusUnknown, Completed, Error, ImagePullBackOff, CrashLoopBackOff
Node management operations
Cordoning, draining, and uncordoning nodes (node_management) for maintenance and scaling operations
Troubleshooting Prompt (k8s-diagnose)
Guides through a systematic Kubernetes troubleshooting flow for pods based on a keyword and optional namespace.
Non-destructive mode for read and create/update-only access to clusters
Secrets masking for security (masks sensitive data in kubectl get secrets commands, does not affect logs)
OpenTelemetry Observability (opt-in)
Distributed tracing for all tool calls
Export to Jaeger, Tempo, Grafana, or any OTLP backend
Configurable sampling strategies
Rich span attributes (tool name, duration, K8s context, errors)
See docs/OBSERVABILITY.md for details
The MCP Kubernetes server includes optional OpenTelemetry integration for comprehensive observability. This feature is disabled by default and can be enabled via environment variables or Helm configuration.
Enable observability with environment variables:
export ENABLE_TELEMETRY=true
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
npx mcp-server-kubernetesAll tool calls: kubectl_get, kubectl_apply, kubectl_logs, etc.
Execution duration: How long each operation takes
Success/failure status: Automatic error tracking
Kubernetes context: Namespace, context, resource type
Rich metadata: Host, process, and custom attributes
Works with any OTLP-compatible backend:
Jaeger (open source)
Grafana Tempo (open source)
Grafana Cloud (commercial)
Datadog, New Relic, Honeycomb, Lightstep, AWS X-Ray
See docs/OBSERVABILITY.md for comprehensive documentation including:
Configuration options
Deployment examples (Kubernetes, Helm, Claude Code)
Sampling strategies
Production best practices
Troubleshooting guide
# Start Jaeger
docker run -d --name jaeger \
-e COLLECTOR_OTLP_ENABLED=true \
-p 16686:16686 \
-p 4317:4317 \
jaegertracing/all-in-one:latest
# Enable telemetry
export ENABLE_TELEMETRY=true
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_TRACES_SAMPLER=always_on
# Run server
npx mcp-server-kubernetes
# View traces: http://localhost:16686The MCP Kubernetes server includes specialized prompts to assist with common diagnostic operations.
This prompt provides a systematic troubleshooting flow for Kubernetes pods. It accepts a keyword to identify relevant pods and an optional namespace to narrow the search.
The prompt's output will guide you through an autonomous troubleshooting flow, providing instructions for identifying issues, collecting evidence, and suggesting remediation steps.
Make sure that you have bun installed. Clone the repo & install dependencies:
git clone https://github.com/Flux159/mcp-server-kubernetes.git
cd mcp-server-kubernetes
bun installStart the server in development mode (watches for file changes):
bun run devRun unit tests:
bun run testBuild the project:
bun run buildLocal Testing with Inspector
npx @modelcontextprotocol/inspector node dist/index.js
# Follow further instructions on terminal for Inspector linkLocal testing with Claude Desktop
{
"mcpServers": {
"mcp-server-kubernetes": {
"command": "node",
"args": ["/path/to/your/mcp-server-kubernetes/dist/index.js"]
}
}
}Local testing with mcp-chat
bun run chatSee the CONTRIBUTING.md file for details.
You can run the server in a non-destructive mode that disables all destructive operations (delete pods, delete deployments, delete namespaces, etc.):
ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true npx mcp-server-kubernetesFor Claude Desktop configuration with non-destructive mode:
{
"mcpServers": {
"kubernetes-readonly": {
"command": "npx",
"args": ["mcp-server-kubernetes"],
"env": {
"ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS": "true"
}
}
}
}All read-only and resource creation/update operations remain available:
Resource Information: kubectl_get, kubectl_describe, kubectl_logs, explain_resource, list_api_resources
Resource Creation/Modification: kubectl_apply, kubectl_create, kubectl_scale, kubectl_patch, kubectl_rollout
Helm Operations: install_helm_chart, upgrade_helm_chart, helm_template_apply, helm_template_uninstall
Connectivity: port_forward, stop_port_forward
Context Management: kubectl_context
The following destructive operations are disabled:
kubectl_delete: Deleting any Kubernetes resources
uninstall_helm_chart: Uninstalling Helm charts
cleanup: Cleanup of managed resources
cleanup_pods: Cleaning up problematic pods
node_management: Node management operations (can drain nodes)
kubectl_generic: General kubectl command access (may include destructive operations)
For additional advanced features, see the ADVANCED_README.md and also the docs folder for specific information on helm_install, helm_template_apply, node management & pod cleanup.
See this DeepWiki link for a more indepth architecture overview created by Devin.
This section describes the high-level architecture of the MCP Kubernetes server.
The sequence diagram below illustrates how requests flow through the system:
sequenceDiagram
participant Client
participant Transport as Transport Layer
participant Server as MCP Server
participant Filter as Tool Filter
participant Handler as Request Handler
participant K8sManager as KubernetesManager
participant K8s as Kubernetes API
Note over Transport: StdioTransport or<br>SSE Transport
Client->>Transport: Send Request
Transport->>Server: Forward Request
alt Tools Request
Server->>Filter: Filter available tools
Note over Filter: Remove destructive tools<br>if in non-destructive mode
Filter->>Handler: Route to tools handler
alt kubectl operations
Handler->>K8sManager: Execute kubectl operation
K8sManager->>K8s: Make API call
else Helm operations
Handler->>K8sManager: Execute Helm operation
K8sManager->>K8s: Make API call
else Port Forward operations
Handler->>K8sManager: Set up port forwarding
K8sManager->>K8s: Make API call
end
K8s-->>K8sManager: Return result
K8sManager-->>Handler: Process response
Handler-->>Server: Return tool result
else Resource Request
Server->>Handler: Route to resource handler
Handler->>K8sManager: Get resource data
K8sManager->>K8s: Query API
K8s-->>K8sManager: Return data
K8sManager-->>Handler: Format response
Handler-->>Server: Return resource data
end
Server-->>Transport: Send Response
Transport-->>Client: Return Final ResponseSee this DeepWiki link for a more indepth architecture overview created by Devin.
Go to the releases page, click on "Draft New Release", click "Choose a tag" and create a new tag by typing out a new version number using "v{major}.{minor}.{patch}" semver format. Then, write a release title "Release v{major}.{minor}.{patch}" and description / changelog if necessary and click "Publish Release".
This will create a new tag which will trigger a new release build via the cd.yml workflow. Once successful, the new release will be published to npm. Note that there is no need to update the package.json version manually, as the workflow will automatically update the version number in the package.json file & push a commit to main.
Adding clusters to kubectx.
If you find this repo useful, please cite:
@software{Patel_MCP_Server_Kubernetes_2024,
author = {Patel, Paras and Sonwalkar, Suyog},
month = jul,
title = {{MCP Server Kubernetes}},
url = {https://github.com/Flux159/mcp-server-kubernetes},
version = {2.5.0},
year = {2024}
}Execute a command in a Kubernetes pod or container and return the output. Command must be an array of strings where the first element is the executable and remaining elements are arguments. This executes directly without shell interpretation for security.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the pod to execute the command in | |
| command | Yes | Command to execute as an array of strings (e.g. ["ls", "-la", "/app"]). First element is the executable, remaining are arguments. Shell operators like pipes, redirects, or command chaining are not supported - use explicit array format for security. | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| timeout | No | Timeout for command - 60000 milliseconds if not specified | |
| container | No | Container name (required when pod has multiple containers) | |
| namespace | No | Kubernetes namespace | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, so description adds moderate context by noting direct execution without shell. Does not elaborate on other behaviors like timeout effects or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, efficient sentences. No unnecessary text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, command format, and security. Lacks details on return format (e.g., stdout/stderr handling) and error scenarios, but reasonable given no output schema and typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by emphasizing security aspect of command array format and implying default timeout. Adds nuance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Execute a command in a Kubernetes pod or container and return the output', specifying verb, resource, and output. Distinguishes from sibling tools like kubectl_logs that read logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on command format (array of strings) and security implications (no shell interpretation). Could be stronger on when to use this versus sibling tools like port_forward or kubectl_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get documentation for a Kubernetes resource or field
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Output format (plaintext or plaintext-openapiv2) | plaintext |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| resource | Yes | Resource name or field path (e.g. 'pods' or 'pods.spec.containers') | |
| recursive | No | Print the fields of fields recursively | |
| apiVersion | No | API version to use (e.g. 'apps/v1') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, establishing this as a safe read operation. The description aligns by stating 'Get documentation', which is non-destructive. However, no additional behavioral context (e.g., if it requires specific permissions, if output is paginated, or if it mirrors `kubectl explain`) is provided. The description adds minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get documentation for a Kubernetes resource or field'. Every word is essential, no filler, and it directly answers what the tool does. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief but sufficient for a documentation retrieval tool. It covers the essential purpose. However, given that there is no output schema, the description could hint at the output format (e.g., plaintext or structure) to better set expectations. Still, it is adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: every parameter (resource, apiVersion, recursive, context, output) has a clear description. The tool description does not add any further meaning to these parameters, so the baseline score of 3 applies. No parameter-specific elaboration is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get documentation for a Kubernetes resource or field' clearly indicates the tool's purpose: retrieving documentation. It specifies the resource/field, which distinguishes it from action-oriented tools like kubectl_apply or kubectl_patch. However, it does not explicitly differentiate from kubectl_describe, which might show similar info, but overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. For example, it does not mention that kubectl_describe shows runtime state while explain_resource shows documentation. No exclusions or prerequisites are given, leaving the agent to guess usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a Helm chart with support for both standard and template-based installation
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the Helm release | |
| repo | No | Helm repository URL (optional if using local chart path) | |
| chart | Yes | Chart name (e.g., 'nginx') or path to chart directory | |
| values | No | Custom values to override chart defaults | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| namespace | Yes | Kubernetes namespace | default |
| valuesFile | No | Path to values file (alternative to values object). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'values' to pass the values inline instead. | |
| useTemplate | No | Use helm template + kubectl apply instead of helm install (bypasses auth issues) | |
| createNamespace | No | Create namespace if it doesn't exist |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals potential destructiveness. The description adds mention of two installation modes but does not elaborate on behavioral traits such as error handling, rollback behavior, or prerequisites like Helm being installed. Given the annotation coverage, a score of 3 is appropriate as the description adds some but limited context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is concise and front-loaded with the core purpose, though it could benefit from a brief expansion on usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, destructive potential, and no output schema, the description is incomplete. It does not cover return values, error scenarios, prerequisites, or when to choose between installation modes. The schema and annotations provide partial context, but the description should bridge remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description does not add meaningful extra semantics beyond referencing the two installation modes (standard/template), which is already covered in the 'useTemplate' parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool installs a Helm chart and highlights support for standard and template-based installations, which differentiates it from sibling tools like upgrade_helm_chart and kubectl commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives or which installation mode to choose. The parameter schema hints at use cases for the 'useTemplate' flag, but the description itself does not provide decision points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a Kubernetes YAML manifest from a string or file
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | If true, immediately remove resources from API and bypass graceful deletion | |
| dryRun | No | If true, only validate the resource, don't actually execute the operation | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| filename | No | Path to a YAML file to apply (optional - use either manifest or filename). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'manifest' to pass the file's contents instead. | |
| manifest | No | YAML manifest to apply | |
| namespace | No | Kubernetes namespace | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true. Description adds no additional behavioral context beyond the schema's parameter descriptions. No contradiction, but no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 9-word sentence, front-loaded with verb and resource, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values or errors, but does not. However, the tool is a standard kubectl operation; description is adequate but incomplete for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. Description only hints at 'string or file' but adds no meaningful semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Apply a Kubernetes YAML manifest from a string or file', specifying the action (apply) and resource (YAML manifest). It distinguishes from siblings like kubectl_create, which creates resources differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use apply versus siblings like kubectl_create or kubectl_patch. Usage is implied but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Kubernetes contexts - list, get, or set the current context
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the context to set as current (required for set operation) | |
| output | No | Output format | json |
| detailed | No | Include detailed information about the context | |
| operation | Yes | Operation to perform: list contexts, get current context, or set current context | list |
| showCurrent | No | When listing contexts, highlight which one is currently active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool can 'set the current context', which is a write/mutating operation, but the annotations declare readOnlyHint=true, indicating a read-only expectation. This is a direct contradiction, severely reducing transparency. Without annotations, the set operation would require more detail about side effects, but here the contradiction is the primary issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose. It is concise and to the point, with no superfluous words. It could be slightly more informative without adding length, but it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple operations including a mutating 'set'), the description lacks details about return values, prerequisites, or side effects. The contradiction with annotations further undermines completeness. No output schema is provided, so the description should cover behavioral expectations but fails to do so adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the schema already explains each parameter. The tool description does not add additional meaning beyond the schema, meeting the baseline. No extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage Kubernetes contexts' and enumerates the specific operations (list, get, set), providing a specific verb and resource that distinguishes it from sibling tools like kubectl_get or kubectl_describe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for managing contexts) but does not provide explicit guidance on when not to use it or suggest alternatives. The usage context is clear from the tool name and schema, but no exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create Kubernetes resources using various methods (from file or using subcommands)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the resource to create | |
| port | No | Port that the container exposes | |
| image | No | Image to use for the containers in the deployment | |
| dryRun | No | If true, only validate the resource, don't actually execute the operation | |
| labels | No | Labels to apply to the resource (e.g. ["key1=value1", "key2=value2"]) | |
| output | No | Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file | yaml |
| command | No | Command to run in the container | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| suspend | No | Whether to suspend the CronJob | |
| tcpPort | No | Port pairs for tcp service (e.g. ["80:8080", "443:8443"]) | |
| filename | No | Path to a YAML file to create resources from. The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'manifest' to pass the file's contents instead. | |
| fromFile | No | Path to file for creating configmap/secret (e.g. ["key1=/path/to/file1", "key2=/path/to/file2"]). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use "fromFileContent" to pass file contents directly instead. | |
| manifest | No | YAML manifest to create resources from | |
| replicas | No | Number of replicas to create for the deployment | |
| schedule | No | Cron schedule expression for the CronJob (e.g. "*/5 * * * *") | |
| validate | No | If true, validate resource schema against server schema | |
| namespace | No | Kubernetes namespace | default |
| secretType | No | Type of secret to create (generic, docker-registry, tls) | |
| annotations | No | Annotations to apply to the resource (e.g. ["key1=value1", "key2=value2"]) | |
| fromLiteral | No | Key-value pair for creating configmap (e.g. ["key1=value1", "key2=value2"]) | |
| serviceType | No | Type of service to create (clusterip, nodeport, loadbalancer, externalname) | |
| resourceType | No | Type of resource to create (namespace, configmap, deployment, service, etc.) | |
| fromFileContent | No | Inline file contents for creating a configmap/secret, provided by the client instead of a server-side path (e.g. [{"key": "app.conf", "content": "..."}]). Safe on all transports; use this instead of "fromFile" on remote (SSE/Streamable HTTP) servers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'Create', implying a mutation, but does not elaborate on idempotency, error behavior, permission requirements, or side effects. The parameter 'dryRun' hints at validation support, but the description itself adds no further behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it could be more structured by front-loading the two creation methods and possibly indicating that the tool supports many resource types. It is not verbose but lacks a clear structure that aids quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, no output schema, no annotations), the description is insufficient. It does not explain how parameters interact, which resource types are supported, or what the return value looks like. The user must rely entirely on the schema, which is unusual for such a versatile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter has a description in the schema. The tool description adds minimal value beyond the schema; it only mentions two methods without linking them to specific parameters. The baseline is 3 because the schema already documents all parameters, and the description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create Kubernetes resources using various methods (from file or using subcommands)'. It identifies the tool's function (creating resources) and distinguishes it from siblings like kubectl_apply (which applies updates) and kubectl_patch (which modifies existing resources). The verb 'Create' and resource type 'Kubernetes resources' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as kubectl_apply, kubectl_patch, or exec_in_pod. It mentions two methods (file or subcommands) but does not explain which scenarios favor one method over the other. There are no prerequisites, exclusions, or context on when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe Kubernetes resources by resource type, name, and optionally namespace
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the resource to describe | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| namespace | No | Kubernetes namespace | default |
| resourceType | Yes | Type of resource to describe (e.g., pods, deployments, services, etc.) | |
| allNamespaces | No | If true, describe resources across all namespaces |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds no further behavioral context (e.g., output format, detail level). While no contradiction, it does not leverage the opportunity to explain the verbosity of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the core action and key parameters. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's purpose, the description fails to clarify what 'Describe' returns (detailed info). Also lacks differentiation from kubectl_get for list vs detail. Under-specified for 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers all 5 parameters at 100% coverage. The description adds no additional meaning beyond listing parameters, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool describes Kubernetes resources with specific attributes (resource type, name, optionally namespace). It is distinct from sibling tools like kubectl_get which list resources, though it doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like kubectl_get or kubectl_logs. The description does not mention scenarios for deep inspection versus summary views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get or list Kubernetes resources by resource type, name, and optionally namespace
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the resource (optional - if not provided, lists all resources of the specified type) | |
| output | No | Output format | json |
| sortBy | No | Sort events by a field (default: lastTimestamp). Only applicable for events. | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| namespace | No | Kubernetes namespace | default |
| resourceType | Yes | Type of resource to get (e.g., pods, deployments, services, configmaps, events, etc.) | |
| allNamespaces | No | If true, list resources across all namespaces | |
| fieldSelector | No | Filter resources by field selector (e.g. 'metadata.name=my-pod') | |
| labelSelector | No | Filter resources by label selector (e.g. 'app=nginx') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. Description adds that it can get or list, but lacks additional behavioral traits like output format (though schema covers enum) or pagination behavior. With annotations, this is adequate but not excellent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 14 words, front-loaded with verb and object. No unnecessary words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is too brief. It doesn't explain return values or behavior (like formatting options or listing vs getting). The schema covers parameters but the description should provide a high-level overview, which it does but minimally. Lacks completeness for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. Description does not add meaning beyond what's in the schema (e.g., no explanation of interaction between name and list behavior, which is implied). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get or list') and the resource ('Kubernetes resources') with key parameters (resource type, name, namespace). It distinguishes from siblings like kubectl_describe (detailed) and kubectl_logs (logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't contrast with kubectl_describe for detailed info or kubectl_logs for pod logs. The description assumes agent knows context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs from Kubernetes resources like pods, deployments, or jobs
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the resource | |
| tail | No | Number of lines to show from end of logs | |
| since | No | Show logs since relative time (e.g. '5s', '2m', '3h') | |
| follow | No | Follow logs output (not recommended, may cause timeouts) | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| previous | No | Include logs from previously terminated containers | |
| container | No | Container name (required when pod has multiple containers) | |
| namespace | Yes | Kubernetes namespace | default |
| sinceTime | No | Show logs since absolute time (RFC3339) | |
| timestamps | No | Include timestamps in logs | |
| resourceType | Yes | Type of resource to get logs from | |
| labelSelector | No | Filter resources by label selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with a read-only operation. It adds the resource type constraint but does not disclose other behaviors like timeout risks for follow, which is mentioned only in the schema parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description captures core purpose adequately for a read-only tool with full schema coverage. Could benefit from mentioning that logs are text output or the follow parameter caution, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters. The description adds no additional meaning or clarification for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and resource 'logs from Kubernetes resources', with specific examples (pods, deployments, jobs). This distinguishes it from siblings like kubectl_describe or exec_in_pod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., kubectl_describe for details, exec_in_pod for interactive access). No exclusion criteria or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update field(s) of a resource using strategic merge patch, JSON merge patch, or JSON patch
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the resource to patch | |
| dryRun | No | If true, only validate the resource, don't actually execute the operation | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| namespace | No | Kubernetes namespace | default |
| patchData | No | Patch data as a JSON object | |
| patchFile | No | Path to a file containing the patch data (alternative to patchData). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'patchData' to pass the patch contents instead. | |
| patchType | No | Type of patch to apply | strategic |
| resourceType | Yes | Type of resource to patch (e.g., pods, deployments, services) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true. Description adds patch types but no additional behavioral context (e.g., side effects, rollback). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and nested objects, the description is too brief. Lacks explanation of patch type differences or return values, though schema covers parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no extra parameter meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates fields of a resource using specific patch types, distinguishing it from sibling tools like kubectl_apply or kubectl_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks context on selecting patch type or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconnect to the Kubernetes API server by recreating all API clients. Use this after cluster upgrades (e.g., EKS control plane upgrades that rotate ENIs/IPs) to force fresh DNS resolution and new TCP connections.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool recreates all API clients, forcing fresh DNS resolution and new TCP connections. Annotations only indicate it is not read-only, so the description adds significant behavioral context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the purpose stated first, followed by a specific use case. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description adequately covers purpose and usage. It could mention the return value or success indication for completeness, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema coverage is 100%. The description does not need to add parameter details, so a baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reconnects to the Kubernetes API server by recreating all API clients. It uses specific verbs and resources ('reconnect', 'API server', 'API clients'), and distinguishes itself from sibling tools that focus on resource management or debugging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool after cluster upgrades (e.g., EKS control plane upgrades that rotate ENIs/IPs) to force fresh DNS resolution and new TCP connections. It provides a clear use case, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the rollout of a resource (e.g., deployment, daemonset, statefulset)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the resource | |
| watch | No | Watch the rollout status in real-time until completion | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| timeout | No | The length of time to wait before giving up (e.g., '30s', '1m', '2m30s') | |
| revision | No | Revision to rollback to (for undo subcommand) | |
| namespace | Yes | Kubernetes namespace | default |
| subCommand | Yes | Rollout subcommand to execute | status |
| toRevision | No | Revision to roll back to (for history subcommand) | |
| resourceType | Yes | Type of resource to manage rollout for | deployment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint:true, which partially indicates potential impact. However, the description adds no behavioral details beyond generic 'manage rollout' – it doesn't explain that subcommands like undo or restart are destructive while status/ history are safe, nor does it mention permissions or cluster state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core purpose. No wasted words, though it could include brief sibling differentiation or a link to more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no description of subcommand behaviors or output format, the tool definition is incomplete. The description does not explain what each subcommand returns (e.g., status output, history list), nor does it list prerequisites like kubectl configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no extra meaning to parameters; it does not elaborate on subcommand effects, revision handling, or timeout usage beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Manage the rollout of a resource' with examples of resource types, clearly indicating the tool's scope. However, 'manage' is somewhat generic and doesn't specify the subcommands (history, pause, etc.) that are listed in the schema. Sibling tools like kubectl_apply and kubectl_scale differ in purpose, so it's distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternative kubectl tools or how to choose among subcommands. The description implies usage for rollout operations but lacks context for when-not-to-use or prerequisites like resource existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scale a Kubernetes deployment
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the deployment to scale | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| replicas | Yes | Number of replicas to scale to | |
| namespace | No | Kubernetes namespace | default |
| resourceType | No | Resource type to scale (deployment, replicaset, statefulset) | deployment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, implying the tool can cause destructive changes. The description adds no further behavioral context, such as how scaling affects pods or whether it triggers rollout. Since annotations already cover the safety profile, the description marginally meets the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It is front-loaded but lacks important details, making it less effective than a more complete but still brief description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description omits return values, error conditions, or side effects. The focus on 'deployment' is misleading and incomplete, failing to cover the full scope of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema documents all parameters. The tool description does not add any additional meaning beyond what is already in the schema, meeting the baseline but not compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Scale' and resource 'Kubernetes deployment', but it is inaccurate because the input schema allows scaling other resource types like replicaset and statefulset. This reduces clarity and differentiates it poorly from siblings like kubectl_patch or kubectl_rollout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., kubectl_rollout for rolling updates). It lacks context about prerequisites, typical use cases, or exclusion criteria, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the API resources available in the cluster
| Name | Required | Description | Default |
|---|---|---|---|
| verbs | No | List of verbs to filter by | |
| output | No | Output format (wide, name, or no-headers) | wide |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| apiGroup | No | API group to filter by | |
| namespaced | No | If true, only show namespaced resources |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. No additional behavioral traits are disclosed, but no contradictions either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear verb and resource. No wasted words, appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 parameters, the description is too minimal. It doesn't explain what 'API resources' means, how the output looks, or how filtering works. Siblings like kubectl_get have more descriptive documentation, making this tool's description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' and resource 'API resources available in the cluster', clearly distinguishing it from siblings like kubectl_get (which lists instances of a specific resource) and explain_resource (which describes a single resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like kubectl_get or explain_resource. The purpose is implied but not directly compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that the counterpart is still responsive and the connection is alive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and description adds that it verifies connection, consistent with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and directly states purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ping with no parameters and output schema, description sufficiently explains behavior and expected outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so no need for additional parameter description; schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool verifies connectivity and responsiveness, which is specific and distinguishes it from sibling tools that perform Kubernetes operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied that this is for checking liveness, but no explicit guidance on when to use vs alternatives; however, context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward a local port to a port on a Kubernetes resource
| Name | Required | Description | Default |
|---|---|---|---|
| localPort | Yes | ||
| namespace | No | ||
| targetPort | Yes | ||
| resourceName | Yes | ||
| resourceType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no behavioral hints. The description only repeats the purpose. It does not disclose that the port forward runs in the background, requires a running process, or how to stop it. No mention of potential side effects or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it sacrifices necessary detail for brevity. It could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is woefully inadequate. It does not cover return values, lifecycle (how to stop), or error states (e.g., port already in use). The agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for its 5 parameters. The description does not explain any parameter meanings, such as what resourceType values are valid (e.g., pod, service), or the difference between localPort and targetPort. This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (forward) and the resource (local port to a Kubernetes resource). It is specific, but does not differentiate from sibling tools like exec_in_pod, which also involve connecting to a pod. No mention that this is similar to kubectl port-forward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternative tools such as exec_in_pod or kubectl_get. Missing context like prerequisites (e.g., pod must be running) or use cases (e.g., debugging a database).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a port-forward process
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action. It does not disclose what happens when stopping (e.g., immediate vs. graceful shutdown) or any side effects, and annotations are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. It is front-loaded with the action but fails to be informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema), the description is incomplete. It should specify the nature of the 'id' parameter and any return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is defined in the schema but not described in the description. With 0% schema description coverage, the description should explain what 'id' refers to (e.g., process ID), but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stop' and the resource 'port-forward process', distinguishing it from sibling tools like 'port_forward' which presumably starts the process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., the sibling 'port_forward' tool). There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upgrade an existing Helm chart release
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the Helm release to upgrade | |
| repo | No | Helm repository URL (optional if using local chart path) | |
| chart | Yes | Chart name or path to chart directory | |
| values | No | Custom values to override chart defaults | |
| context | No | Kubeconfig Context to use for the command (optional - defaults to null) | |
| namespace | Yes | Kubernetes namespace | default |
| valuesFile | No | Path to values file (alternative to values object). The path is read on the machine running the MCP server, so it is rejected when the server runs over a remote (SSE/Streamable HTTP) transport; use 'values' to pass the values inline instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds no additional behavioral context, such as authorization needs, side effects, or rollback behavior, which would be valuable for an upgrade operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks sufficient detail. It could be expanded slightly without sacrificing conciseness, e.g., by mentioning that the release must already exist.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, and the description does not explain return values, error handling, or the upgrade process. For a tool with 7 parameters and a nested object, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the input schema already describes all parameters. The description does not add extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('upgrade') and resource ('existing Helm chart release'), clearly indicating what the tool does. However, it does not distinguish itself from the sibling tool 'install_helm_chart' for new installations, which would be a minor improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the release must exist ('existing') but provides no explicit guidance on when to use this tool versus alternatives like 'install_helm_chart'. No prerequisites or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct Kubernetes operation or resource. The kubectl_* tools cover different actions (apply, create, logs, scale, etc.), while other tools like port_forward, exec_in_pod, and install_helm_chart are clearly separate concerns. There is no overlap or ambiguity between tools.
The majority of tools follow a consistent 'kubectl_verb' pattern, but several tools (ping, explain_resource, install_helm_chart, etc.) deviate without a clear alternative convention. The mix is still readable and predictable, but not perfectly uniform.
With 18 tools, the server covers a broad range of Kubernetes management tasks without being overwhelming. Each tool has a clear use case, and the count is appropriate for the complexity of the domain.
The tool set covers essential operations like get, describe, apply, create, logs, scale, port forwarding, and Helm management. However, a delete operation is notably missing, which is a common requirement in Kubernetes workflows. This gap is minor but prevents a higher score.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
Manage Kubernetes clusters, deployments, databases, secrets and observability on Mengi Cloud.
Deploy containers on Kubernetes with x402 billing. 9 workload types and source builds.
Ship production-ready TypeScript code in half the time, at half the cost.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Flux159/mcp-server-kubernetes'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
