VibeRevert MCP server has critical definition gaps. Tool descriptions are present but minimal (10-50 chars, well below the 50-200 char baseline for LLM-optimized descriptions). No input schemas are visible in the provided source code, tool-registry.ts shows tool names and descriptions only, with no parameter definitions, types, or output schemas documented. This prevents LLMs from understanding what inputs each tool accepts or what structure to expect in responses. The server lacks parameter descriptions entirely, violating the pattern:tool-description requirement that every parameter must be documented. Error handling is not evident in the visible code. Tool naming follows verb_noun convention (check_repo, explain_diff, classify_risk, list_risky_files, get_policy, start_session, create_checkpoint, generate_fix_prompt), which is a strength, but without schemas and detailed descriptions, the tools are not production-ready for agent use.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'check_repo: Scan the repository for risky changes (file deletions, dependency updates, config modifications) and return a structured report with risk level, affected files, and recommended actions.'
• Define complete input schemas for all tools in JSON Schema format. For each parameter, specify: type (string, number, boolean, array, object), required/optional, enum values (if constrained), min/max (if numeric), pattern (if regex), and a 50-100 char description. Example: { "parameters": { "type": "object", "properties": { "repo_path": { "type": "string", "description": "Absolute path to the repository root directory" } } } }
• Document output schemas for all tools. Specify the structure of returned objects, field types, and what IDs/references are included for chaining. Example: check_repo returns { risk_level: 'low'|'medium'|'high', affected_files: [{path, risk_type, severity}], report_id }.
• Add confirmation/dry-run support to destructive tools. start_session and create_checkpoint should accept a 'dry_run' parameter (boolean, default false) that returns a preview without persisting state. This prevents accidental data loss.
• Implement error handling with recovery guidance. When a tool fails, return structured errors with: error_code, message, and next_steps. Example: { error_code: 'REPO_NOT_FOUND', message: 'Repository not found at /path/to/repo', next_steps: 'Verify the path is correct and the repository is initialized' }.