Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has 21 tools with schemas and descriptions present, but suffers from systematic quality gaps. Naming is verb-forward and mostly clear (kubectl_*, git_*, helm_*, flux_*), but descriptions are consistently brief (averaging 45-80 chars) and lack LLM-optimized context about when/why to use each tool. Parameter descriptions are minimal or generic. Output schemas are undocumented, no guidance on what fields to expect in responses. Error handling and recovery paths are absent. Critical security issue: write_file and read_file expose path traversal risk without clear constraints. The tools show domain completeness for K8s/Git/Helm/Flux operations, but fall short of production-grade definition quality. Most tools score 35-55 individually; average ~42.
Output schemas undocumented. No tool describes what fields or structure the response contains. LLMs cannot plan downstream tool chaining or extract required IDs (e.g., pod_id, helm_release_id) without guessing.
Descriptions are consistently under 100 chars and lack LLM optimization. Missing context about WHEN to use each tool, dependencies, and what problem it solves. E.g., 'Retrieve pod logs from Kubernetes' does not explain whether to call before or after describe, or how to handle log truncation.
Document the output schema for every tool. Specify the structure, field types, and meanings. For example: 'kubectl_get returns an object with fields: {pods: [{name: string, namespace: string, status: string, restarts: integer, ...}], total_count: integer}'. This enables proper response parsing and chaining.
Expand tool descriptions to 150-250 characters, adding: (1) specific use case ('Retrieve logs to debug pod failures'), (2) prerequisite discovery step if needed ('Call kubectl_describe first to identify container names'), and (3) side effects if any. Baseline: 194 chars average for production tools.
Add parameter descriptions that specify format, range, and valid values explicitly. E.g., 'output format: one of json, yaml, wide, custom-columns. Defaults to wide if omitted. Use json for parsing by downstream tools.'
Add enum constraints to parameters with known value sets (output, kind, resource). Define these in the JSON Schema 'enum' field and reference them in the description.
Implement and document explicit error classification for each tool: retryable (connection timeout), user-fixable (pod not found, try kubectl_get first), or fatal (invalid YAML). Return structured error responses with actionable guidance.
Add dry-run and confirmation support to destructive tools (kubectl_delete, kubectl_apply, helm_upgrade, git_push, write_file). Use MRTR (Multi Round-Trip Request) to ask the user before executing, or require an explicit 'confirm: true' parameter.
Add tool annotations to the MCP protocol response: readOnlyHint for all get/list/describe tools, destructiveHint for delete/apply/push, idempotentHint for idempotent operations. This enables clients to warn users or restrict speculative calls.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions are minimal or missing context. E.g., 'manifest' in kubectl_apply says 'YAML manifest content or file path' but does not clarify: is this required to be valid YAML? What happens if it is a path, is it read from the container filesystem? Does it auto-detect or require explicit specification?
Path traversal risk in read_file and write_file. The 'path' parameter states 'must be in allowed directories' but does not specify what those directories are or how the constraint is enforced. An LLM could be tricked into passing '../../../etc/passwd'. Requires explicit allowlist in description and implementation validation.
No error handling guidance. No tool description mentions how failures are reported (HTTP 400 vs 500), what to do if a pod does not exist, or whether operations are retryable. LLMs cannot recover from partial failures without explicit recovery guidance.
Destructive operations (kubectl_delete, git_push, helm_upgrade, write_file) lack dry-run confirmation or MRTR (Multi Round-Trip Request) for user confirmation. An LLM could delete all pods without asking the user first.
No tool annotation hints (readOnlyHint, destructiveHint, idempotentHint). Clients cannot determine which tools are safe to call speculatively vs. which require user confirmation. These are part of current MCP spec but absent from this server.
Parameters like 'namespace', 'container', and 'output' are marked optional but lack guidance on defaults or what happens when omitted. E.g., kubectl_get with no 'output' format, does it default to 'wide' or 'json'? LLMs will guess wrong.
No pagination or result-limiting guidance. Tools like helm_list, kubectl_get, and list_files could return hundreds of items. No mention of whether results are truncated, how to paginate, or what a reasonable limit is. This risks context window exhaustion.
Enum constraints missing for known-value parameters. E.g., 'output' in kubectl_get accepts 'json', 'yaml', 'wide', 'custom-columns', etc., but is documented as a free-form string, not an enum. LLMs will hallucinate invalid formats.
kubectl_gethelm_listflux_reconcile
Secure read_file and write_file by: (1) documenting the allowlist of permitted directories (e.g., '/app, /tmp, /config'), (2) validating paths in the implementation to reject '../' and absolute paths outside the allowlist, (3) failing fast with 'Path /etc/passwd not in allowed directories: /app, /tmp, /config'.
Add pagination support to list-returning tools (helm_list, kubectl_get, list_files, list_resources). Include 'limit' and 'offset' parameters, return a 'total_count' field, and document the default limit (recommend 20 - 50) to prevent context window exhaustion.
For git_pull and git_push, clarify whether they handle merge conflicts and what happens if a rebase is needed. Add error guidance for common cases (merge conflict, authentication failure, remote rejection).
For kubectl_exec, document whether the tool captures stdout/stderr and how to interpret non-zero exit codes. Return structured output: {exit_code: integer, stdout: string, stderr: string}.
Add examples of expected input to tool descriptions without including sample values that LLMs might reuse literally. E.g., instead of 'e.g. my-pod', describe the format: 'Pod name as shown in kubectl get pods (alphanumeric and dashes, lowercase)'.