Single dynamically-generated tool with critical definition gaps. Tool name 'git-*' is a pattern placeholder, not a concrete verb-noun pair, LLMs cannot infer intent from the name alone. Description is generic and does not explain WHEN to use this tool vs alternatives, or that it executes DESTRUCTIVE commands. Input schema present but parameters lack actionable constraints: 'args' accepts free-form strings with no format guidance, validation rules, or examples of proper escaping. No output schema documented. No error handling guidance. The tool exposes raw git command execution, which is a security and usability anti-pattern, agents cannot reason about side effects.

• Split the single 'git-*' tool into specific, verb-noun tools: git_status, git_add, git_commit, git_push, git_pull, git_branch, git_checkout, git_log, git_diff, git_reset, git_rebase, git_merge, git_stash. Each tool should have a concrete name and clear description of what it does and when to use it.
• For each tool, document the output schema as a typed object with fields like 'success' (boolean), 'stdout' (string), 'stderr' (string), 'exit_code' (integer). This enables LLMs to parse results and chain operations.
• Add parameter constraints: 'args' should accept a structured object with named parameters (e.g., message, branch, remote) instead of free-form strings. Alternatively, provide an enum of common argument patterns and validate against them.
• For destructive tools (commit, push, reset, rebase, force-push), add a 'dry_run' boolean parameter (default: true) and a 'confirm' parameter. Require explicit confirmation before executing irreversible operations.
• Add error handling guidance: document which git errors are retryable (network timeouts, lock contention) vs user-fixable (invalid branch name, uncommitted changes) vs fatal (corrupted repository). Return actionable error messages like 'Branch "main" not found. Available branches: develop, feature-xyz, hotfix-abc'.