Burrow has 15 tools with mixed quality. Strengths: all tools have descriptions (10-100+ chars), tool annotations present (readOnlyHint, destructiveHint), and clear risk classification. Weaknesses: 6 tools (burrow_snapshot, burrow_history, burrow_top_processes, burrow_process_usage, burrow_disk_forecast, burrow_diff) lack visible input schemas entirely, cannot verify parameter structure. Names are descriptive but inconsistent in verb usage (burrow_* prefix dominates; some lack action verbs). Output schemas declared in metadata but not fully visible in source. Error handling guidance absent from descriptions. Destructive tools (burrow_evict, burrow_uninstall) have confirmation parameters but descriptions don't explain recovery or undo paths.

• Add visible input schemas to burrow_snapshot, burrow_history, burrow_top_processes, burrow_process_usage, burrow_disk_forecast, and burrow_diff in the source code. Include parameter types, descriptions, and constraints (e.g., time range for history, limit for top_processes).
• Rename tools to start with action verbs: burrow_snapshot → get_system_snapshot, burrow_history → get_metric_history, burrow_diff → compare_snapshots. This helps LLMs infer intent from the name alone.
• Expand destructive tool descriptions to include error recovery: 'If confirm=false, returns a dry-run preview. If confirm=true and permanent=true, files are permanently deleted (not recoverable). On partial failure, returns which paths succeeded and which failed.'
• Document output schemas inline in tool descriptions or in a separate schema registry visible in the source. Include examples of success and error responses so LLMs know what fields to expect.
• Add parameter constraints to descriptions: e.g., 'paths: array of absolute directory paths (must exist and be readable)' and 'confirm: must be JSON boolean true to execute; false or omitted performs a dry run (safe to call multiple times)'.