Server has 6 tools with basic schemas and descriptions, but significant gaps prevent production readiness. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization), and input schemas are present but minimal. No output schemas documented. Error handling is absent, tools return raw strings with no guidance for LLM recovery. No tool annotations (readOnlyHint/destructiveHint). code_exec is particularly risky: accepts arbitrary code in any language with no validation, sandboxing details, or timeout guidance. Parameter descriptions are generic ('Search query', 'Code to execute') without format constraints, enums, or examples. No pagination support for list-like tools (rag_search, knowledge_qa). Missing idempotency guarantees and composition guidance.

• Expand all tool descriptions to 50-200 characters. Include WHAT (action), WHEN (use case), and any prerequisites. E.g., 'Execute Python, JavaScript, or Bash code in a sandboxed Docker container. Use for data processing, calculations, or system tasks. Timeout: 30s. Returns stdout/stderr.'
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. E.g., web_search should return [{title, url, snippet, source}] with total_results and next_cursor.
• Add tool annotations: mark web_search, file_reader, sql_query, rag_search, knowledge_qa as readOnlyHint=true; mark code_exec as destructiveHint=true (can modify files/state).
• Implement structured error responses with recovery guidance. E.g., 'SQL syntax error: invalid column name. Available columns: [list]. Try search_schema() first.' Return {error, code, recoverable, suggestion}.
• Add parameter constraints and enums. E.g., code_exec.language should be enum [python, javascript, bash]; sql_query should document max result rows (e.g., 1000) and suggest pagination.