Three tools with explicit schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names follow verb_noun pattern (execute_*, dry_run_*) which is good. However, descriptions lack actionable context for LLM selection, parameters are minimally documented, and output schemas are not formally specified. No error recovery guidance. The dry_run_mutate tool has a complex multi-parameter interface that lacks dependency documentation.

• Document output schemas for all three tools. Specify: What fields does execute_read_only return? (e.g., {output: string, executionTime: number, errors?: string[]}). This enables LLMs to extract and chain results.
• Add validation rules to parameter descriptions. For 'code' param: 'Ruby code string (max 5000 chars). Must not contain: DROP TABLE, DELETE FROM, TRUNCATE. Invalid syntax will return a Ruby error message.' Include examples of valid/invalid input.
• Implement error classification in responses. Return {success: boolean, result?: string, error?: {type: 'syntax_error'|'timeout'|'permission_denied'|'validation_failed', message: string, suggestion?: string}}. This guides LLM recovery.
• Document dry_run_mutate parameter relationships. Add to description: 'mutate_code is the actual mutation to execute. dry_run_code should be a read-only equivalent that shows what records will be affected. Both must reference the same model/scope or validation will fail.'
• Expand tool descriptions with WHEN/WHY context. E.g., execute_read_only: 'Use this to inspect data before mutations. Returns query results as JSON. Cannot use variables across commands, each call is isolated. Useful for: counting records, listing values, checking conditions before dry_run_mutate.'