Critical gaps across all dimensions. Tool definitions are inferred from registration code (bootstrap/tools.go) rather than directly visible in source. No input schemas, parameter descriptions, or output documentation found in provided code. Tool names lack consistent verb-noun patterns (e.g., 'AgentTool', 'SkillTool' are vague). Descriptions are absent or not visible. Error handling patterns not evident. This server appears to be a framework/CLI wrapper around Claude, not a production MCP server with properly documented tool interfaces.

• Add comprehensive tool descriptions (50-200 chars) to every tool. Include WHAT it does, WHEN to use it, and any prerequisites. Example: 'FileReadTool: Read file contents. Use when you need to examine code, config, or text files. Returns raw file content as string.'
• Define explicit JSON Schema for every tool's input parameters. Include type, description, required fields, and constraints (enums, min/max, patterns). Example: { type: 'object', properties: { path: { type: 'string', description: 'Absolute file path (must exist)' } }, required: ['path'] }
• Rename vague tools to verb_noun pattern: 'AgentTool' → 'create_agent' or 'spawn_agent'; 'SkillTool' → 'register_skill' or 'load_skill'; 'BriefTool' → 'generate_brief'; 'SyntheticOutputTool' → 'create_synthetic_output'.
• Document output schemas for all tools. Specify what fields are returned, their types, and what downstream tools can consume them. Example: 'Returns { success: bool, file_id: string, size_bytes: number }'.
• Add error handling guidance to destructive tools. Implement dry-run or confirmation patterns for delete/write operations. Return actionable error messages: 'File not found at /path/to/file. Check path spelling or use GlobTool to search.' instead of raw errors.