Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This Kubernetes MCP server has moderate structural organization but significant quality gaps. The tool names follow verb_noun conventions (get_deployments, scale_deployment) which is good, but many tools lack proper input schema definitions in the visible code. Descriptions are present but vary in quality (10-100 chars, below the 194-char baseline for production tools). Parameter descriptions are sparse, the main.py registration code does not show detailed parameter annotations for any tool. Critical issues: (1) Input schemas are inferred from type hints but not explicitly visible in JSON Schema format in the registration; (2) No output schemas documented for any tool; (3) Error handling guidance is absent; (4) No pagination support for list tools (get_deployments, get_pods); (5) Parameter constraints (enums, ranges) are not declared; (6) Missing dependency hints and composition guidance.
Input schemas not explicitly visible as JSON Schema objects in registration code. Tools register with function references but no explicit schema validation definitions shown. Schema quality cannot be verified from the provided source.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract required fields without knowing the response structure. This violates the pattern:tool requirement.
Add explicit JSON Schema definitions for all tool inputs in the registration code. Each tool.tool() decorator should include a fully specified 'inputSchema' with type, required, properties, and format constraints for every parameter.
Add pagination to list tools: get_deployments, get_pods, get_nodes should accept 'limit' (1-100, default 20) and 'offset' (0-based) or 'page' parameters. Return {items: [...], total: int, limit: int, offset: int} structure.
For scale_deployment and rollout_deployment, add a 'dry_run' boolean parameter (default false) and describe the parameter as 'If true, simulate the change without applying it. Use this to preview the impact before executing.'
Standardize parameter descriptions to English and follow a consistent template: 'The [RESOURCE] [CONSTRAINT]. [WHEN/WHY]. [DEPENDENCIES if any].' Example: 'The Kubernetes context name. If omitted, uses the current context. Call get_available_contexts() to list valid values.'
Add error recovery guidance to each tool description. Append: 'Returns error if [CONDITION]. On error, try [RECOVERY_STEP].' Example for get_pod_details: 'Returns error if pod not found. On error, call get_pods(namespace=...) to verify the pod exists.'
Declare enum or pattern constraints for 'context' and 'namespace' parameters. Store available contexts in a config file or document that set_default_context dynamically validates context names against kubeconfig.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 6 points across a rubric change (v1 → v2)
44/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
44
<=2025-11-25
v2
2026-03-09
F
38
-
v1
writesource verified60/100
Realizar un rollout de un deployment en un cluster de kubernetes
scale_deploymentwritesource verified63/100
Escalar un deployment en un cluster de kubernetes
set_default_contextwritesource verified60/100
Establecer un contexto como el contexto por defecto en kubeconfig
List tools (get_deployments, get_pods) lack pagination support. No limit, offset, page_size, or next_cursor parameters documented. Large cluster results will blow context window. Baseline expects paginated results for list tools.
No error handling guidance or recovery paths documented. Tools do not explain what to do when a deployment is not found, a namespace is invalid, or Kubernetes API is unreachable. LLMs receive no direction on retry logic or alternative actions.
Destructive tools (scale_deployment, rollout_deployment, set_default_context) lack confirmation or dry-run support. No indication in descriptions that these modify state or are irreversible. No guidance on undo or compensation.
Parameter 'context' is inconsistently named and described across tools. Some tools document 'Nombre del contexto de Kubernetes' (Spanish), others use 'Contexto de Kubernetes a usar'. Descriptions vary in detail, creating ambiguity for LLM tool selection.
Parameter descriptions are in Spanish ('Nombre del contexto', 'Namespace específico') while tool descriptions mix Spanish and English. Inconsistent language and formatting reduce clarity for English-language LLM agents.
No constraints on parameter values. 'context' and 'namespace' accept free-form strings with no validation, enum, or pattern hints. 'replicas' in scale_deployment accepts any integer but allows negative values, description says '>= 0' but no schema constraint visible.
Tool composition and chaining not documented. No guidance on tool ordering (e.g., call get_available_contexts before set_default_context). No indication of which tools require output from other tools.
No idempotency guarantees documented. Agents retry on failure, unclear if scale_deployment(replicas=3) called twice results in 3 or 6 replicas, or if get_logs() retrieves the same logs or new logs on retry.
scale_deploymentrollout_deployment
For scale_deployment, add minimum/maximum constraints on 'replicas': 'Integer between 0 and 1000 (cluster dependent). Defaults to current replica count if omitted.'
Add tool composition hints in descriptions. Example for set_default_context: 'First call get_available_contexts() to see valid context names. Then pass one to this tool to make it the default.'
Document idempotency guarantees. scale_deployment(namespace, deployment_name, replicas=N) is idempotent if called with the same inputs, the deployment will have exactly N replicas, not N more. rollout_deployment is not idempotent (each call restarts pods). Include this in descriptions.
Add support for tool annotations: mark get_* tools with 'readOnlyHint': true, and mark scale_deployment, rollout_deployment, set_default_context with 'destructiveHint': true so clients can warn users before execution.
Include chaining IDs in responses. e.g., get_pods response should include namespace and context alongside each pod name so downstream tools (get_pod_details, get_logs) can use the result directly.
Add permission gates and audit logging. Log who called what tool, when, and with what parameters. For destructive tools, log the previous state and the change applied.