This K8s/Helm MCP server has 16 tools with basic but inconsistent definition quality. Tool names follow verb_noun convention reasonably well (getAPIResources, listResources, getResource, describeResource, getPodsLogs, etc.), and all tools have descriptions. However, descriptions are often generic and lack specificity about WHEN to use each tool or HOW they differ from similar tools. Parameter schemas are present but lack depth, most parameters have type and description, but several critical parameters are missing constraint documentation (enums, ranges, validation rules). Output schemas are not documented anywhere in the provided code, making it impossible for LLMs to plan chained calls. Error handling information is absent from tool descriptions. Security considerations are not addressed (e.g., how credentials are injected, what permissions each tool requires). The tools cover a good surface area for K8s/Helm operations (CRUD, metrics, logs, helm lifecycle), but the definitions lack the polish needed for confident LLM usage at scale.

• Document return type schemas for all 16 tools. Include field names, types, and descriptions so LLMs can parse responses and extract IDs for downstream calls. Example: 'Returns object with fields: {apiVersion: string, kind: string, metadata: {name: string, namespace: string}, spec: {...}}'.
• Split createOrUpdateResource into two tools: createResource (with manifest and namespace) and updateResource (with kind, name, namespace, and new manifest). Each should clearly state its preconditions and side effects.
• Enhance descriptions for getResource vs describeResource: 'getResource returns the resource object as a lightweight summary; describeResource returns the full manifest with status and annotations.' Make the distinction explicit.
• Add enum constraints or format descriptions for parameters. For example: namespace parameter should note 'Leave empty for cluster-scoped resources; use specific namespace name otherwise.' Helm 'values' should document expected structure (e.g., 'Object with chart-specific keys; see helm values output for available options.').
• Add error guidance to all tool descriptions. Template: 'If resource not found, try listing resources with listResources first. If permission denied, ensure kubeconfig context has RBAC access.' Include specific recovery actions.
• Add confirmation/dry-run guidance to helmUninstall and helmRollback descriptions. Document that these are irreversible and suggest calling helmHistory first to confirm the revision.
• Document pagination for listResources and getAPIResources. Add parameters for limit (default 50, max 1000) and offset/cursor, and return total_count so LLMs can iterate safely.