Descriptions are present but generic (10-40 chars), below the 50-200 char LLM-optimized baseline. Tool names lack action verbs (e.g., 'Bash' instead of 'execute_bash', 'Agent' instead of 'dispatch_agent'). No output schemas documented. No error handling guidance. No parameter descriptions. The codebase shows privacy-aware logging (tool-tracker.js) but this is metadata-only and does not compensate for absent tool definitions.

• Add explicit input schemas to all 14 tools with empty parameters. E.g., Read should declare {"file_path": {"type": "string", "description": "Path to file to read (relative to AIGENT_ROOT)"}}.
• Rename tools to verb_noun convention: execute_bash, dispatch_agent, invoke_skill, read_file, search_web, list_tasks, get_task, create_task, update_task, edit_file, write_file, grep_files, glob_files, list_directory, fetch_web, search_tools, read_notebook, list_mcp_resources, read_mcp_resource.
• Expand descriptions to 50-200 chars with WHAT, WHEN, and PREREQUISITES. E.g., 'Execute a bash shell command. Use for filesystem operations, package management, or version control. Returns stdout/stderr and exit code. Irreversible, use with caution.'
• Document output schemas for all tools. E.g., TaskCreate returns {"task_id": "string", "subject": "string", "created_at": "ISO8601"}. Include chaining IDs (task_id, agent_id) so downstream tools can reference results.
• Add error handling and recovery guidance. Bash tool: 'If command fails, check syntax and permissions. Common errors: file not found (ENOENT), permission denied (EACCES), command not found (ENOEXEC).' Destructive tools: implement dry-run or confirmation pattern (pattern:confirmation-request).