Rails Informant demonstrates solid tool definition quality with consistent naming patterns, comprehensive parameter schemas, and detailed descriptions. All 14 tools follow verb_noun naming conventions (get_, list_, delete_, mark_, resolve_, etc.). Tool descriptions are well-crafted (averaging ~120 chars) and explain WHAT the tool does and WHEN to use it. Parameter schemas are fully typed with descriptions for all inputs. However, output schemas are not formally documented in the source code, responses are shaped as JSON text rather than structured MCP Response objects with explicit field definitions. Error handling is present but generic (catches Client::Error with message-only responses). The server includes comprehensive instructions guiding agent workflows, which partially compensates for missing output documentation. Tool composition is excellent, each tool has a single responsibility, and chaining is well-designed (mark_fix_pending → verify_pending_fixes → resolve_error). No security vulnerabilities detected (config/token injection via server_context, not parameters). Naming is context-specific and avoids ambiguity (e.g., list_errors vs list_occurrences vs get_error are clearly distinguished). The main gaps are: (1) no explicit output schema definitions in tool registrations, (2) error responses lack recovery guidance or categorization, (3) no confirmation patterns for destructive operations (delete_error, mark_duplicate).

• Document explicit output schemas for all tools. For list_errors, define: {errors: [{error_id: string, error_class: string, message: string, occurrences_count: integer, last_occurrence: ISO8601, status: string, severity: string}], meta: {page: integer, per_page: integer, has_more: boolean, total_count?: integer}}
• Enhance error responses with categorization and recovery guidance. Example: 'Error not found (error_id=xyz). This error may have been auto-deleted if it's older than 30 days. Try list_errors(status="all") to see available errors.'
• Add optional dry_run parameter to delete_error. Return 'Would delete error group XYZ with 42 occurrences. Call with dry_run=false to confirm.' until the user explicitly confirms.
• Implement confirmation pattern for mark_duplicate: return a confirmation response requiring the agent to call confirm_mark_duplicate(error_id, duplicate_of_id) to proceed, preventing accidental consolidation.
• Return pagination metadata as structured fields (not text) in list_errors and list_occurrences responses. Clients can then drive multi-page workflows programmatically.
• Add tool annotations to tool registration. Map Risk classifications to destructiveHint (DESTRUCTIVE→true, WRITE→false, READ_ONLY→false) and idempotentHint where applicable (get_*, list_*, verify_pending_fixes→true; others→false).
• Include chaining IDs in all responses. When list_errors returns error summaries, include error_id. When get_error returns occurrences, include deployment SHAs for git checkout. When mark_fix_pending succeeds, return the error_id for immediate verify_pending_fixes call.