Single tool 'git' has a well-structured schema with proper enum constraints, type definitions, and comprehensive parameter descriptions. The tool description clearly states its purpose (read-only git operations) and lists subcommands. However, the description lacks guidance on WHEN to use this tool vs alternatives, and output schema is not formally documented. Input validation is robust (ref blocklist, path traversal checks, 100KB output cap), but error messages could be more actionable for LLM recovery. The tool name 'git' is generic and lacks a verb prefix (e.g., 'explore_git' or 'read_git_history' would be clearer). Overall solid implementation with room for LLM-optimized descriptions.

• Rename tool from 'git' to 'explore_git_history' or 'read_git_status' to lead with an action verb. This helps LLMs infer intent from the name alone.
• Add output schema documentation to the tool description. Example: 'Returns: For log/show, a formatted string with commit hash, author, date, and message. For diff, unified diff output. For status, working tree status. All output is capped at 100KB.'
• Enhance error messages with recovery hints. Instead of 'Error: ref contains blocked sequence', return 'Invalid ref: contains blocked sequence "..", use branch names (main, develop), tags (v1.0), or commit SHAs (abc123def). Avoid shell metacharacters (|, ;, $, `).'
• Add WHEN/WHY context to the tool description. Prepend: 'Use this tool to explore the codebase history, understand recent changes, and review file diffs. Call this first to understand project structure before proposing code modifications.'
• Document the relationship between 'ref' and 'ref2' parameters more clearly. Add to description: 'For diff: if ref2 is omitted, compares ref against the working tree. If both are provided, compares ref..ref2 (e.g., main..feature-branch). For log/show: ref2 is ignored.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry