Liyuan exposes 5 tools with minimal documentation. Tool names lack action verbs (read, bash, edit, write, echo_session are acceptable but generic). Descriptions are extremely brief (10-50 chars), below the 194-char baseline for production tools. Input schemas are present but sparse: parameters lack type constraints, enums, ranges, or validation guidance. The 'bash' tool accepts arbitrary commands with only a timeout parameter, no safety constraints, no dry-run option, no permission gates. The 'edit' tool schema is incomplete (missing content/operation details). No output schemas documented. Error handling is absent, no recovery guidance, no categorization. Security is critical: bash execution without sandboxing or audit trails is a severe risk. Overall, this reads as an early prototype, not production-grade.

• Expand all tool descriptions to 100-200 characters. Include WHAT (action), WHEN (use case), and any prerequisites. E.g., 'read: Retrieve file contents by path. Use to inspect code, configs, or logs before editing. Supports line-based offset/limit for large files.'
• Add input validation: bash timeout must be 1-300 seconds; read offset/limit must be non-negative integers; edit/write paths must not traverse parent directories (../). Document these constraints in parameter descriptions.
• Document output schemas for each tool. E.g., read returns {content: string, lineCount: number, truncated: boolean}; bash returns {stdout: string, stderr: string, exitCode: number, timedOut: boolean}.
• Implement error handling with recovery guidance. E.g., 'File not found at /path/to/file. Check the path and try again.' or 'Command timed out after 30s. Increase timeout or simplify the command.'
• Add security controls to bash: require explicit allowlist of safe commands (e.g., grep, find, cat); reject dangerous patterns (rm, dd, curl with credentials); log all invocations with timestamp, user, command, and result for audit trails.