Micro-Tools vs God-Tools
definition
The micro-tools vs god-tools spectrum defines the fundamental granularity decision in tool design: should you give an agent many small, focused tools (read_file, write_file, search_code) or fewer large, multi-capability tools (manage_codebase with subcommands)? Micro-tools are easier for agents to learn and compose, produce more interpretable traces, and fail in contained ways, but they require more tool calls and more context to describe all available options.
The micro-tools vs god-tools spectrum defines the fundamental granularity decision in tool design: should you give an agent many small, focused tools (read_file, write_file, search_code) or fewer large, multi-capability tools (manage_codebase with subcommands)? Micro-tools are easier for agents to learn and compose, produce more interpretable traces, and fail in contained ways, but they require more tool calls and more context to describe all available options. God-tools reduce the number of choices the agent faces and can bundle related operations atomically, but they create opaque execution blocks and risk overwhelming the model with complex parameter schemas. The best production systems tend toward micro-tools with clear naming conventions, because models consistently perform better when tool selection is unambiguous — but they strategically combine related operations when atomicity matters (like "create file and add to git" as a single tool). This concept connects to tool definition patterns for designing each tool's interface, tool composition for combining micro-tools into workflows, function calling for how models select between available tools, and the orchestrator pattern for how architecture can compensate for tool granularity decisions.