Only one tool is defined (analyze_failed_load_job). The tool has a reasonable description (90 chars, within baseline 34-392), and three parameters with type annotations and descriptions. However, no output/return schema is documented anywhere in the visible code. The tool appears to be registered but without explicit schema validation or structured output documentation. The tool name uses verb_noun pattern correctly ('analyze_failed_load_job'). Parameter descriptions are present but minimal (15-40 chars each). Critical gaps: no documented output schema, no error handling guidance, no recovery patterns. The server exposes SSH credentials as tool parameters (ssh_user, ssh_key_path), which violates secret-injection patterns, these should be injected server-side from environment. This is a significant security issue.

• Move ssh_user and ssh_key_path to server-side environment configuration. Load them from env vars (SR_SSH_USER, SR_SSH_KEY_PATH) instead of accepting them as parameters. This prevents credential leakage in logs and traces.
• Document the return schema explicitly. Add to the tool description or a separate schema block: 'Returns: { status: "success" | "error", logs: string[], diagnostics: object, affected_nodes: string[], error_details?: string }'. This enables downstream chaining.
• Add error recovery guidance to the description. E.g., 'Fails if SSH connection times out (60s limit). If SSH fails, verify ssh_user is correct, firewall allows port 22, and the key file is readable. You can retry after fixing these.'
• Expand parameter descriptions with format and constraints. E.g., 'label: The load job label or numeric ID (visible in StarRocks FE logs or SHOW LOAD command). Accept either format.'
• State idempotency and side effects in the tool description. E.g., 'This tool is read-only. It collects logs and diagnostic data but does not modify any state. Safe to retry.'
• If ssh_key_path is a file path, validate it early and return a clear error: 'SSH key file not found at /path/to/key. Provide a valid path or use server-configured default.'
• Add a list of possible error conditions and recovery steps. E.g., 'Common errors: (1) SSH connection refused → check network connectivity; (2) Load job not found → verify label is correct; (3) Insufficient permissions → ensure SSH user can read log directories.'

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

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