Quorum defines 26 tools with schemas and descriptions present, but quality is inconsistent. Most tool descriptions are terse (20-50 chars), below the 50-200 char baseline for LLM-optimized descriptions. Parameter descriptions exist but are minimal ('directory to scan', 'file path'). No output schemas are documented, critical for agents planning downstream calls. Many tools lack actionable error guidance. Tool names are domain-specific but not consistently verb-prefixed (e.g., 'code_map' vs 'audit_scan'). Composition is reasonable (single responsibility per tool), but parameter relationships and constraints are underdocumented. No evidence of idempotency guarantees or confirmation patterns for destructive operations (audit_submit, rtm_merge, agent_comm, skill_sync, track_archive are WRITE tools with minimal safeguards).

• Document output schemas for all 26 tools. Include field names, types, and what IDs/references are returned for chaining. Example: code_map should return {symbols: [{name, type, line_start, line_end}], total_count}.
• Expand tool descriptions to 80-150 chars. Answer: What does it do? When to use it instead of similar tools? What does it return? Example: 'audit_submit' → 'Submit code review evidence to audit track and trigger verdict. Use after running audit_scan to record findings. Returns verdict status and track history.'
• Add parameter descriptions with format/range constraints. Example: 'depth' → 'maximum directory depth (1-10, default 5)'. 'pattern' → 'pattern category: all|type-safety|hardcoded|console'.
• Add confirmation/dry-run support to WRITE tools. For audit_submit, rtm_merge, agent_comm, skill_sync, track_archive: add optional 'dry_run' boolean param and document rollback behavior.
• Add error handling guidance to all tools. Document: (1) what errors are retryable, (2) what user action is needed, (3) what is fatal. Example: 'If path not found, verify directory exists and try again. If permission denied, check file access.'