This MCP server exposes 3 database query tools with reasonable but incomplete documentation. Tool names follow verb_noun convention (query_database, execute_sql, get_schema_info), which is positive. However, critical gaps exist: (1) No input schemas are fully visible in the provided source code excerpt, the `get_schema_info` tool's inputSchema is incomplete (missing 'required' array and no type constraints on table_name). (2) Descriptions are present and moderately detailed (150-200 chars each), exceeding the 10-char minimum, but lack LLM-optimized guidance on error recovery and when to call each tool vs. the others. (3) Parameter descriptions exist but are sparse, 'table_name' in get_schema_info lacks type info (is it a string? enum of valid table names?). (4) Output schemas are not documented, callers do not know what structure query_database or execute_sql returns (e.g., are results a JSON object, a text table string, a CSV?). The code shows results are formatted as text tables, but this is not declared in the tool schema. (5) Security: the server accepts arbitrary SQL in execute_sql with only a surface 'must start with SELECT' check, no mention of injection prevention or schema/table whitelisting. (6) Error handling is minimal, the tool call handler catches exceptions generically and returns an error string, but does not guide LLMs on recovery (retryable vs. fatal).

• Add explicit output schema documentation to all tools. Specify: (1) If results are returned as a JSON object with fields like 'rows', 'column_names', 'row_count', document that structure. (2) If results are plain text tables, declare the response as a single string field with a note that LLMs must parse it. Example: {type: 'object', properties: {result: {type: 'string', description: 'Formatted text table with results'}}}.
• Complete get_schema_info inputSchema: add 'required: []' (table_name is optional), and change table_name from bare string to: {type: 'string', description: 'Optional: specific table name (e.g., heropass, usermarathonevent). If omitted, lists all available tables.'}. Consider adding an 'enum' constraint listing valid table names.
• Strengthen parameter constraints in execute_sql. Document allowed schemas explicitly as an enum or constraint: 'Must use table prefix ods_core.*, stage.*, or ris.* (e.g., ods_core.heropass). Non-prefixed queries are rejected.'
• Differentiate query_database vs. execute_sql in descriptions. Add guidance like: 'Use query_database when you have a natural language question and want the server to generate optimized SQL. Use execute_sql only when you already have a specific SQL query ready to run.'
• Implement SQL injection prevention: (1) Use parameterized queries / prepared statements. (2) Maintain a whitelist of allowed tables and schemas. (3) Parse and validate queries before execution (e.g., using sqlparse library). (4) Return actionable error messages: 'Query rejected: table xyz not in allowed list. Allowed: heropass, usermarathonevent, bookings, payments, notifications.'

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

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