Single tool 'db.query' has a basic schema with type and enum constraints, but critical gaps undermine production readiness. Description is minimal (18 chars, well below 50-200 char baseline for A+ tools). No parameter descriptions visible in the schema, LLMs cannot infer what 'sql' or 'format' control. Output schema is undocumented. No error handling guidance, no recovery paths, no mention of SQL injection risk or permission gates. The tool exposes raw database access without visible input validation, sanitization, or audit context despite the codebase showing audit_logger infrastructure. Tool composition is monolithic (one tool for all queries) rather than split by intent (read vs write, discovery vs mutation).

• Expand tool description to 80-150 chars: 'Execute a read-only SQL query against the configured database. Returns results as JSON, text, or HTML. Use for data discovery and reporting only, mutations are not supported.'
• Add parameter descriptions: 'sql' → 'The SQL query to execute. Must be a SELECT statement; mutations (INSERT, UPDATE, DELETE) are rejected. Use parameterized queries to prevent injection.'; 'format' → 'Output format: json (default, structured), text (plain rows), or html (table markup).'
• Document output schema: 'Returns {success: boolean, data: array of objects (for json) or string (for text/html), error?: string, execution_time_ms?: number}'
• Add error handling: Return structured errors like '{success: false, error: "SQL syntax error: ...", suggestion: "Check query syntax or call list_tables() to discover available columns"}' instead of raw exceptions.
• Implement input validation: Reject non-SELECT statements, enforce parameterized queries, and add rate limiting to prevent runaway agents from overwhelming the database.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry