Server has 17 tools with complete Zod schemas and basic descriptions. However, descriptions are uniformly terse (10-40 chars), parameter descriptions lack context about constraints/formats, and output schemas are undocumented. No error recovery guidance, no idempotency hints, and no distinction between read-only and destructive operations in descriptions. Tool names follow verb_noun convention but lack clarity on mutual exclusivity (e.g., sapling_diff_untracked vs sapling_diff_changed vs sapling_diff_target). Schemas are present but minimal, no enums, ranges, or format constraints. This is typical community-grade work: functional but not LLM-optimized.

• Expand all descriptions to 50-200 chars. Include WHAT (action), WHEN (use case), and WHAT IT RETURNS. Example: 'Get repository status including staged/unstaged changes and untracked files. Call this first to understand what needs to be committed. Returns: status summary with file counts.'
• Document output schemas for all tools. Define response fields (e.g., 'Returns: {status: string, files: [{path: string, status: 'modified'|'added'|'deleted'}], total: number}'). This enables LLMs to extract and chain data.
• Add error recovery hints to descriptions. Example for sapling_commit: 'If commit fails due to merge conflicts, call sapling_status to see conflicted files, then resolve manually or call sapling_revert to abort.'
• Rename diff tools for clarity: sapling_diff_untracked → sapling_status_untracked, sapling_diff_changed → sapling_status_staged, sapling_diff_target → sapling_diff_revision. Or consolidate into one sapling_diff with a 'type' enum parameter (untracked|staged|revision).
• Add dry-run support to destructive tools. Add optional 'dryRun: boolean' parameter to sapling_commit, sapling_push, sapling_land, sapling_revert. Return what WOULD happen without executing. This prevents accidental data loss.