Critical gaps across all 8 tools. No input schemas visible in source code, tool-router.ts defines ToolEntry interface with optional schemaRef but no actual schemas are provided or loaded. Descriptions are present but minimal (10-60 chars), lacking WHEN/WHY context and parameter guidance. No parameter descriptions visible. No output schemas documented. No error handling guidance. Tools expose destructive operations (bash, delete_file) without confirmation patterns or permission gates. Rate limiting is declared for web_search/web_fetch but not enforced in visible code. This is a tool authorization framework, not a production-grade tool implementation.

• Create explicit JSON Schema definitions for each tool's input parameters. Include type, description, enum constraints, and min/max bounds. Store in tool-packs or embed in ToolEntry.
• Expand tool descriptions to 100-200 chars following pattern: 'WHAT it does, WHEN to use it, WHAT it returns.' Example: 'str_replace_editor: Edit code by specifying file path, old text, and replacement. Use for code generation and refactoring. Returns success status and updated file content.'
• Add parameter descriptions to schema definitions. Every parameter (file_path, old_text, new_text, etc.) needs a description explaining format, constraints, and examples.
• Document output schemas for each tool. Specify return fields, types, and whether results are paginated. Include examples of success and error responses.
• Implement confirmation pattern for bash and delete_file: add requiresConfirmation flag enforcement and return 'input_required' result type when confirmation is needed (per MRTR pattern).