Kubernetes MCP Server - provides Model Context Protocol access to Kubernetes cluster management and resource operations
This Kubernetes MCP server provides 13 READ_ONLY tools with consistent naming (all verb_noun: get_, list_, check_). However, tool definitions suffer from significant schema incompleteness and minimal parameter documentation. While tool names follow verb-starting conventions and descriptions exist, the schema definitions visible in the source code lack proper JSON Schema structures with type declarations and constraint definitions. Input schemas are provided in the evaluation metadata but are NOT visible in the actual source code excerpts shown (internal/mcp/server.go shows tool registration without input schemas). No output schemas are documented anywhere. Error handling exists (per features list) but guidance on recovery or categorization is not evident in the visible code. The server uses HTTP transport (current standard, good), but lacks modern MCP features like tool annotations, progress reporting, and structured error classification.
Check if the current user has permission to perform an action (kubectl auth can-i). Parameters: verb (string, required, e.g. 'get', 'list'), resource (string, required, e.g. 'pods'), namespace (string, required)
Get cluster status information (version, node count, namespace count)
Get cluster events. Parameters: namespace (string, required)
Get pod logs. Default tail_lines=100, max_bytes=1MB. Parameters: pod_name (string, required), namespace (string, required), container_name (string, optional), tail_lines (int, optional), previous (bool, optional), cluster_name (string, optional)
Get detailed information about a specific resource (JSON format). Secrets will be redacted. Parameters: resource_type (string, required, e.g. 'pods' or 'pod'), name (string, required), namespace (string, required)
Input schemas not visible in source code. Tool registration in internal/mcp/server.go uses mcp.AddTool() but does NOT include InputSchema field. Schemas provided in evaluation metadata appear inferred, not explicitly defined in the codebase.
Parameter descriptions lack actionable constraints. Examples: 'Kubernetes namespace name (required)' does not specify valid format, length limits, or character restrictions. 'Kubernetes resource type' does not document allowed values (pods, services, deployments, etc.) as an enum.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Get the full YAML definition of a resource. Secrets will be redacted. Parameters: resource_type (string, required, e.g. 'pods' or 'pod'), name (string, required), namespace (string, required)
List configmaps in a namespace. Parameters: namespace (string, required)
List deployments in a namespace. Parameters: namespace (string, required)
List all namespaces in the cluster
List all nodes in the cluster
List pods in a namespace. Parameters: namespace (string, required)
List services in a namespace. Parameters: namespace (string, required)
List statefulsets in a namespace. Parameters: namespace (string, required)
No output schemas documented. None of the 13 tools have documented return types, field structure, or what data agents should expect. This forces LLMs to parse results blindly and risks context loss in multi-step workflows.
No pagination support visible. List tools (list_pods, list_services, list_deployments, list_configmaps, list_statefulsets, list_namespaces) do not expose offset/limit/page parameters or return total counts. Large clusters could exceed context window limits.
No tool annotations present. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. All 13 tools are READ_ONLY and should declare this via proper annotations for client safety.
Resource type parameter accepts free-form strings ('pods' or 'pod' per description) without enum constraint. LLMs may pass invalid resource types ('pod123', 'mypod', 'Pod'). Should enumerate valid Kubernetes resource kinds: Pod, Service, Deployment, StatefulSet, ConfigMap, Secret, DaemonSet, etc.
Secrets are mentioned as 'redacted' in get_resource and get_resource_yaml descriptions but no detail on what redaction means or how to handle sensitive data workflows. Does the tool return '***' or omit sensitive fields entirely?