Single tool 'execute_query' has a basic schema with two required string parameters (connectionAlias, query) but lacks critical depth. Description is minimal (11 words, 56 chars), below the 10 - 1024 char baseline and insufficient for LLM selection. No parameter descriptions visible in schema. No output schema documented. No error handling guidance. No mention of result limits, pagination, or data structure. Tool accepts raw SQL, creating injection risk without validation hints. Naming is verb-based (execute_query) but generic, does not clarify read vs. write intent or result format.

• Expand tool description to 100 - 200 chars. Example: 'Execute a read-only SQL query on a configured database connection. Returns structured rows with column names and types. Use for data retrieval only; write operations are not supported. Queries are executed with parameterized binding to prevent SQL injection.'
• Add parameter descriptions: connectionAlias: 'Name of the pre-configured database connection (e.g., prod_postgres, staging_mysql). Available aliases are listed in resources.' query: 'SQL SELECT statement. Must be read-only (no INSERT, UPDATE, DELETE, DROP). Use ? or $N placeholders for parameters to prevent injection.'
• Document output schema: 'Returns { rows: Array<Record<string, any>>, rowCount: number, columns: Array<{name: string, type: string}> }. Rows are capped at 1000; use LIMIT and OFFSET for pagination.'
• Add error handling guidance: 'If query fails, error includes the SQL error message and suggests parameterized queries if injection is suspected. If result exceeds 1000 rows, error suggests adding LIMIT clause.'
• Clarify connectionAlias as an enum or provide a discovery tool (list_database_connections) so LLMs know valid aliases without trial-and-error.