Repogent defines 9 tools with basic schemas and descriptions, but falls short of production quality. Tool names follow verb_noun convention (inspect_, start_, get_, approve_, select_, cancel_). Descriptions exist but are terse (10-50 chars), lacking context on WHEN to use each tool or what happens next. Input schemas are present but minimal, most parameters are typed as generic 'object' with only a description string, not detailed field-level schemas. No parameter descriptions beyond the top-level object. Error handling is present (ToolError wrapping) but generic; no recovery guidance. The server sanitizes outputs to prevent secret leakage, which is good, but lacks idempotency hints and confirmation patterns for destructive operations (approve_patch). Tool composition is reasonable (separate read/write/destructive operations), but parameter documentation is sparse.

• Expand tool descriptions to 50 - 200 characters. Include WHAT the tool does, WHEN to call it (e.g., 'Call after reviewing the implementation plan'), and WHAT happens next (e.g., 'Returns a RunSnapshot with pending_approval set'). Example: 'Approve the implementation plan for a run. Call this after reviewing the proposed changes. Returns updated run state with next approval step or execution preview.'
• Document nested field schemas for 'request', 'decision', and 'decision' parameters. Use JSON Schema with type, required, enum, and description for each field. E.g., for approve_requirements, document that 'decision' must have kind='REQUIREMENTS', approved=true|false, and optional reason string.
• Add confirmation pattern to approve_patch. Require an explicit 'confirmed=true' parameter and document: 'This operation applies changes to the repository and cannot be undone. Requires explicit confirmation. Always ask the user before calling with confirmed=true.'
• Enhance error guidance in tool descriptions. Document expected error scenarios and recovery steps. E.g., 'If the run is not found, call get_run() with the correct run_id. If the run is in an invalid state, call get_run() to check pending_approval.'
• Add parameter descriptions for all nested fields. For each tool, document what each field in 'request' or 'decision' means, valid values, and constraints. Use enums for fixed sets (e.g., kind: REQUIREMENTS|PLAN|PATCH|EXECUTOR).