speclaw provides 8 tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (compass_explore, lawbook_change, speclaw_setup). Descriptions range from adequate (compass_explore: 95 chars) to verbose (lawbook_change: 95 chars). All parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot predict return structure. Error handling is minimal; no recovery guidance or actionable error messages visible. Parameters like 'action' enums are well-constrained, but complex tools like lawbook_change (14 params) lack clear dependency documentation. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE vs READ_ONLY). Composition is reasonable, tools are single-purpose, but chaining IDs are not guaranteed in responses.

• Document output schemas for all 8 tools. Example: compass_explore should return {symbols: [{name, type, location}], callers: [...], callees: [...], blastRadius: {...}}. This enables LLMs to chain tools correctly.
• Add tool annotations: mark compass_index, lawbook_change, speclaw_setup with destructiveHint=true; mark compass_explore, compass_find, lawbook_investigate with readOnlyHint=true. This guides agent planning.
• For lawbook_change, document parameter dependencies in descriptions. Example: 'mode (propose|set|promote|explain), only valid when action=level. Ignored for other actions.'
• Add error recovery guidance to tool descriptions. Example: 'If projectPath not found, call speclaw_setup init first to initialize the project.' This enables agents to self-correct.
• Reduce lawbook_change parameter count by splitting into separate tools: lawbook_level (for level ceremony), lawbook_coverage (for coverage analysis), lawbook_drift (for drift analysis). This improves clarity and reduces cognitive load on LLMs.