Single tool 'query' has a clear verb-noun name and basic description, but critical gaps undermine quality. The input schema is visible with a 'sql' parameter (string type), but lacks validation constraints in the schema itself, validation happens only at runtime via validate_sql_query(). Parameter description is minimal (18 chars: 'SQL query string to execute'). No output schema is documented; the tool returns a formatted string but LLMs cannot predict structure. Error handling is absent, no guidance on what to do if validation fails or query times out. The tool does not follow the pattern:tool-description baseline (194 chars avg; this is ~60). No pagination, no result limits documented. Security validation is present (read-only check, SQL injection prevention) but not exposed in the schema or description, leaving LLMs unaware of constraints.

• Expand parameter description to 100+ chars: 'SQL query string to execute against Snowflake (read-only only; no INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, GRANT, REVOKE, COMMIT, ROLLBACK, or SQL comments allowed). Max 5000 chars.'
• Add output schema to tool docstring: 'Returns a JSON object with keys: rows (array of result tuples), row_count (integer), execution_time_ms (integer), columns (array of column names).'
• Implement structured error responses: catch validation failures and return JSON with error_type ('forbidden_keyword'|'sql_comment'|'timeout'), invalid_value, and recovery hint (e.g., 'Remove comments and retry' or 'Query timed out; try limiting result set with LIMIT clause').
• Add maxLength constraint to sql parameter schema (e.g., 5000) and document in description. Add pattern or enum if only SELECT is allowed.
• Document result limits in description: 'Results capped at 10,000 rows. For larger datasets, use LIMIT and pagination in your SQL query.'

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

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