Server defines 9 tools with explicit schemas and descriptions visible in index.ts. All tools have basic descriptions (10-50 chars) and input schemas with type definitions. However, descriptions are minimal and lack LLM-optimized guidance on WHEN to use each tool or what happens next. Parameter descriptions are present but terse. No output schemas documented. Error handling is absent from tool definitions. Destructive tools (delete_pod, scale_deployment, update_deployment_image) lack confirmation patterns or dry-run support. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Naming is verb-first and clear, which is a strength.

• Expand tool descriptions to 50-200 chars. Include WHEN to use (e.g., 'Call this to list all pods in a namespace before selecting one to inspect or delete'), WHAT it returns (e.g., 'Returns pod names, status, and restart count'), and HOW to chain (e.g., 'Use pod names from this call as input to get_pod_logs or describe_pod').
• Document output schemas for all tools. Example for get_pods: 'Returns {pods: [{name: string, status: string, restarts: number, age: string}], total: number}'. This enables LLMs to extract and chain data correctly.
• Add tool annotations to destructive/write tools. In the tool definition, add 'destructiveHint: true' for delete_pod, 'idempotentHint: true' for restart_deployment, and 'readOnlyHint: true' for all get_* and describe_* tools.
• Implement confirmation pattern for delete_pod and scale_deployment. Add a 'confirm' parameter (boolean, default false) or a separate 'confirm_delete_pod' tool that requires explicit user approval before executing irreversible operations.
• Add parameter constraints and validation hints. For scale_deployment, document 'replicas must be 0-100' and 'scaling to 0 will stop all pods'. For update_deployment_image, document 'image must be a valid container image reference (e.g., nginx:1.21, gcr.io/project/app:v1.0)'.