All 13 tools have basic descriptions and parameter schemas, but quality is inconsistent. Descriptions are generic (avg ~80 chars, well below the 194-char baseline for A+ tools) and lack context on WHEN to use each tool or what distinguishes similar ones (e.g., get_pods vs describe_pod). Parameter descriptions are minimal, 'The CLI tool to use' repeats across all tools without explaining why an agent would choose 'oc' over 'kubectl'. No output schemas documented. No error handling guidance. No tool annotations (readOnlyHint, etc.). All tools are read-only and safe, but the definitions do not leverage this for agent optimization. Schema validation is present (command enum check) but only at runtime, not in the JSON Schema definition.

• Document output schemas for all tools. Specify that results are tab-separated or JSON-formatted kubectl output, and provide a sample structure (e.g., {"nodes": [{"name": "...", "status": "..."}]}). This enables LLMs to parse and chain results.
• Expand tool descriptions to 100 - 200 characters. Explain WHEN to use each tool: 'Get a list of all pods in a namespace (use before describe_pod to find a specific pod)' vs 'Get detailed info about a single pod (use after get_pods to inspect a pod you found).'
• Enhance parameter descriptions with context. For 'command', explain: 'The CLI tool to use. Use "kubectl" for standard Kubernetes clusters, "oc" for OpenShift clusters. Defaults to kubectl if unsure.'
• Add readOnlyHint: true to all tool schemas in the JSON Schema definition. This signals to agents that these tools are safe to retry and do not modify state.
• Wrap subprocess calls with structured error handling. Return JSON objects with {"success": true, "data": "...", "error": null} or {"success": false, "error": "...", "suggestion": "Try get_pods() first to find available pods"}. This enables agents to parse and recover from failures.