The server implements 5 tools with partial schema documentation and inconsistent description quality. The delve tool has detailed input validation rules and structured parameters, but other tools (pprof, ssh_exec, sysinfo, kube) lack visible input schemas and detailed parameter descriptions in the provided source. Only delve has substantive parameter documentation; the others show minimal descriptions without parameter details. No output schemas are documented for any tool. Error handling is minimal, no recovery guidance, categorization, or actionable error messages visible. The naming follows verb_noun convention (appropriate), but parameter documentation is sparse. The HTTP transport and go-sdk framework are solid, but definition quality lags significantly behind production baselines.

• Document input and output schemas for all five tools in code. For pprof, ssh_exec, sysinfo, kube: define parameter types, descriptions, and constraints following the delve example (name, type, description, validation). Publish schemas in tool registration.
• Expand tool descriptions to 50-200 characters. Include: what the tool does, when to use it (vs similar tools), prerequisites, risk level (read-only vs write/destructive). Example: delve -> 'Connects to a remote Delve debugger to inspect running Go processes. Use to pause execution, read variables, and step through code during debugging. Requires network access to Delve server port.'
• Document output schemas for each tool. Specify response field names, types, and which fields are safe for downstream tool calls. Example: 'sysinfo returns {hostname: string, cpu_count: int, memory_bytes: int, ...}'. This enables tool chaining.
• Add per-parameter descriptions to all tools. For ssh_exec 'command': 'The shell command to execute (bash/sh syntax). Avoid pipes and redirects if possible; use separate calls instead.' For kube 'action': 'One of: exec, port-forward, logs, delete. Irreversible: delete cannot be undone without manual recovery.'
• Implement confirmation/dry-run patterns for write operations (ssh_exec, kube). Add optional 'dry_run' parameter (boolean) and require explicit 'confirm: true' parameter before executing destructive actions. Return what would happen without executing.
• Add error categorization and recovery hints. When an operation fails, structure the error as {code, message, retryable: bool, hint: 'try X instead'}. Example: 'Delve connection failed. Hint: verify host:port is reachable and Delve is listening. Try a simple command like \"version\" first.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry