MCP server for Kubernetes cluster operations, providing tools for kubectl commands, Helm package management, Cilium CNI commands, and Hubble observability
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has severe definition quality issues across all four tools. While tool names follow verb_noun patterns (call_kubectl, call_helm, call_cilium, call_hubble), the input schemas are dangerously under-specified. All tools accept free-form string parameters with minimal validation guidance. Descriptions are present but generic and lack critical context about destructive operations, prerequisites, or error recovery. No output schemas are documented. The server exposes powerful cluster-level operations (kubectl, helm, cilium) without proper input constraints, format validation, or dependency hints. Parameter descriptions like 'Command arguments and flags for kubectl' provide no guidance on what constitutes valid input. For destructive tools (kubectl, helm, cilium), the lack of confirmation/dry-run patterns and error guidance is particularly dangerous.
Tools (4)
call_ciliumdestructivesource verified43/100
Run Cilium CNI commands for network policies and observability
call_helmdestructivesource verified43/100
Run Helm package manager commands for Kubernetes
call_hubbleread only45/100
Run Hubble observability commands for network flow monitoring
call_kubectldestructive43/100
Execute kubectl commands for Kubernetes cluster operations
No input validation or constraints on string parameters. call_kubectl accepts any 'operation' and 'args' without enum constraints, format validation, or allowed-value guidance. Agents can invoke dangerous commands like 'delete node' without restriction.
Missing output schemas. No documentation of what these tools return, field structure, or how to chain results to other tools. call_kubectl could return raw kubectl output (text) or JSON, agent cannot plan next steps without knowing structure.
No error handling guidance. Descriptions do not explain failure modes, recovery paths, or when to retry. For destructive tools, no guidance on what happened if kubectl delete partially succeeds.
Document output schema for each tool. Example for call_kubectl: 'Returns {"stdout": string, "stderr": string, "exitCode": number}'. Agents need to know if output is plain text or structured JSON.
Expand tool descriptions from 50-100 chars to 150-250 chars. Add WHEN to use (e.g., 'Call to retrieve current cluster state or troubleshoot resource issues'), prerequisites (e.g., 'Requires valid kubeconfig and cluster connectivity'), and failure modes (e.g., 'Returns non-zero exit code if resource not found or insufficient permissions').
Add parameter validation guidance. For 'args': 'Comma-separated or space-separated flags and arguments. Do not include quotes unless part of the argument itself. Examples: --namespace=kube-system, --all-namespaces, --output=json'.
For destructive tools (call_kubectl, call_helm, call_cilium), add a dry-run pattern. Introduce a 'dry_run' boolean parameter (default false). When true, append --dry-run=client to kubectl or --dry-run to helm. Document in description: 'When dry_run=true, previews the action without committing changes.'
Add error recovery guidance to descriptions. Example: 'If the tool returns "connection refused", verify kubeconfig is set and cluster is reachable. If it returns "permission denied", check RBAC policies for your user/service account.'
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Destructive operations lack confirmation or dry-run pattern. call_kubectl and call_helm can delete resources, but there is no safe way to preview the action before committing. Agents will make irreversible mistakes.
Parameter descriptions lack actionable constraints. 'args' parameter for kubectl says 'Command arguments and flags' but does not specify: are quotes required? Is URL encoding needed? Can it contain pipes or redirects? Format ambiguity invites malformed input.
Tool descriptions do not specify prerequisites or dependencies. call_kubectl description does not say 'Requires kubeconfig context to be set' or 'Cluster must be reachable'. Missing context prevents agents from knowing when a call will fail.
call_kubectl 'operation' parameter should be an enum (get, describe, apply, delete, patch, create, logs, exec, etc.), not a free-form string. Agents hallucinate invalid operations like 'retrieve', 'inspect', 'fetch'.
No mention of required permissions or RBAC requirements. Tools can fail silently with permission errors (e.g., 'User does not have permission to delete pods in namespace production'). Descriptions should surface this.
No guidance on timeout behavior or rate limits. If agents call these tools in loops (e.g., polling for pod readiness), they could overwhelm the cluster or hang indefinitely. Descriptions should specify timeout and retry semantics.
call_kubectlcall_helmcall_ciliumcall_hubble
Document RBAC/permission requirements. Example: 'Requires at minimum read:pods, list:pods, describe:pods permissions in the target namespace. Destructive operations require delete:pods, patch:pods, create:pods'.
Add timeout guidance: 'This tool has a default timeout of 30 seconds. For long-running operations (e.g., deployments), increase timeout or poll the status separately.'
Create a discovery tool (e.g., 'list_kubectl_operations') that returns available operations and required arguments, helping agents pick the right operation without hallucinating invalid ones.
For call_cilium and call_hubble, add context about when to use each. Example: 'call_cilium: For CNI and network policy operations. call_hubble: For read-only network flow observability. They are complementary, use hubble to observe, cilium to change policy.'
Add structured error examples to descriptions. Example: 'On error, returns JSON: {"error": "<message>", "suggestion": "<recovery action>"}. If resource not found, try list_* to find available resources.'
Document idempotence and side effects. Example: 'helm install is idempotent if the release name already exists, it will upgrade instead of error. kubectl apply is idempotent; kubectl create will fail if the resource exists.'
Add a note about command injection risk. Remind users that 'args' are passed to a shell, special characters like $, `, ;, | must be escaped. Document safe quoting rules.
Return structured output (JSON) rather than raw shell output. Agents parse JSON better than plain text. Modify tool to return: {"stdout": <text>, "stderr": <text>, "exitCode": <int>, "summary": <parsed object if applicable>}.