Both tools have minimal descriptions (under 20 chars penalty applies) and lack parameter descriptions entirely. The 'query' tool description is 44 chars; 'execute' is 45 chars, both below the 10-1024 baseline and lack actionable context. Neither tool documents what happens on error, retry behavior, or side effects. No output schema documented. The 'execute' tool is particularly dangerous, it accepts arbitrary shell commands with zero validation, sanitization, or permission gating. This is a mock/demo server, but the tool definitions would fail code review in production.

• Add 50-150 character descriptions to both tools. Example for 'query': 'Execute a read-only or write SQL query against the mock PostgreSQL database. Returns JSON results for SELECT; confirmation for INSERT/UPDATE/DELETE. Idempotent for SELECT, non-idempotent for writes.'
• Add descriptions to all parameters. Example: 'sql: A valid SQL statement (SELECT, INSERT, UPDATE, DELETE, or DDL). Queries are executed immediately and cannot be rolled back.'
• Document output schema explicitly. Example: 'Returns {content: [{type: "text", text: string}], isError?: boolean}. For SELECT, text is JSON array of rows. For writes, text is confirmation message.'
• For 'execute' tool: add input validation (whitelist allowed commands or patterns), implement a dry-run mode, require explicit confirmation for destructive operations, and log all invocations with timestamp and caller for audit trails.
• Add error handling guidance to descriptions. Example: 'On SQL syntax error, returns isError=true with error message. Retry with corrected SQL. On connection failure, returns timeout error, wait 5s and retry.'