Server has 5 tools with basic descriptions but critical gaps in schema documentation, parameter descriptions, and error handling. Tool names are reasonable (verb-noun pattern), but input schemas are not visible in the provided code, only parameter names and types are inferred from docstrings. No output schemas documented. Error handling is minimal (generic exception messages). The ask_support_assistant tool is overly broad (combines routing logic). upload_policy_document and safe_sql_query lack input validation guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Descriptions are present but generic (34 - 194 chars, below the 50 - 200 char LLM-optimized baseline). This server would not pass code review by a principal tool engineer.

• Add explicit JSON Schema definitions for all tool inputs. Include type, description, enum (for constrained values), minLength/maxLength, and pattern constraints. Example: {"query": {"type": "string", "description": "SQL query (SELECT only; no INSERT/UPDATE/DELETE)", "minLength": 5, "maxLength": 2000}}
• Document output schemas for each tool. Specify returned fields, types, and structure. Example: ask_support_assistant returns {"response": string, "source": enum["sql", "rag", "both"], "confidence": number}
• Replace generic error messages with actionable recovery guidance. Example: 'Invalid PDF: file is corrupted or not a valid PDF. Try uploading a different file or check the file with a PDF validator.' instead of 'Error indexing document: ...'
• Add input validation to safe_sql_query. Reject INSERT/UPDATE/DELETE/DROP statements. Return: 'SQL injection risk: only SELECT queries are allowed. Your query contains [INSERT|UPDATE|DELETE]. Rewrite using SELECT only.' This prevents malicious or accidental destructive queries.
• Split ask_support_assistant into separate tools: query_sql_database (for customer data) and query_policy_documents (for policies). This enables the agent to compose them independently and retry individual steps without re-routing.