Qling provides 4 tools with minimal descriptions and incomplete schemas. Tool names are action-oriented (write, bash, read, search) but descriptions are extremely brief (10-30 chars), falling well below the 50-200 char baseline for LLM-optimized descriptions. Input schemas are present but lack detail: parameters have type and description fields, but no enums, ranges, or format constraints. No output schemas are documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. The bash and write tools pose significant security risks with no validation, sanitization, or permission gates visible in the provided code. Tool composition is reasonable (each does one thing), but descriptions are too terse for reliable LLM selection.

• Expand tool descriptions to 50-200 chars. Example for 'write': 'Write or create files with content. Use this to save code, config, or data to disk. Requires a valid file path and content string. Overwrites existing files without confirmation, use with caution.'
• Document output schemas for all tools. Example for 'read': 'Returns {success: boolean, content: string, error?: string, bytesRead: number}'. This enables LLMs to chain tools and extract required fields.
• Add parameter constraints: path should validate against path traversal (no '../'), content should have a max length, bash command should reject dangerous patterns (rm -rf, sudo, etc.).
• Implement approval gates for bash and write. Require explicit user confirmation before executing destructive commands. Log all invocations with user, timestamp, command, and result.
• Add error categorization and recovery hints. Example: 'File not found at /path/to/file. Available files in /path: [list]. Try search() to locate the file.' This guides LLM retry logic.