Server has 6 tools with basic schemas and descriptions, but significant gaps prevent production use. All tools accept a 'dsn' parameter (database connection string) as a required input, this violates secret-injection patterns and forces agents to manage credentials. Descriptions are present but generic (10-50 chars), below the 50-200 char baseline for LLM optimization. No parameter descriptions beyond the dsn/sql/schema/table names. Output schemas are not documented, agents cannot predict response structure. Error handling is absent; no recovery guidance or categorization. No tool annotations (readOnlyHint/destructiveHint) despite clear risk differences (query vs execute). Tool composition is reasonable (each does one thing), but the lack of structured output documentation and missing parameter constraints severely limit agent reasoning.

• Move 'dsn' from tool parameters to server-side configuration (environment variable or config file). Agents should not handle credentials. Update tool signatures to remove dsn parameter entirely.
• Document output schemas for each tool. E.g., query() returns {rows: [{col1: val, col2: val, ...}], rowCount: N, executionTime: ms}. Include field types and constraints.
• Expand descriptions to 50-200 chars with WHEN/WHY context. E.g., 'Execute a SELECT query and return results as JSON rows. Use this to fetch data; use explain() to analyze performance instead.'
• Add tool annotations: mark execute() with destructiveHint=true and idempotentHint=false; mark query/list_*/describe_*/explain with readOnlyHint=true. This enables agents to reason about safety.
• Implement error handling with recovery guidance. Return structured errors: {error: 'SyntaxError', message: 'Invalid SQL: ...', suggestion: 'Check column names with describe_table()'}. Categorize as retryable, user-fixable, or fatal.