Three tools with clear verb-noun naming (get_issue, fix_issue, run_status) and basic descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are minimal (10-60 chars), lacking context on WHEN to use each tool, prerequisites, or recovery guidance. Output schemas are not documented, LLMs cannot predict response structure. No error handling guidance (e.g., what to do if a run fails or times out). Missing idempotency hints for fix_issue, which is a destructive operation. Parameter descriptions are sparse: 'repo is owner/name' is terse; base_branch lacks guidance on defaults or format.

• Document output schemas for all three tools. E.g., get_issue returns {title: string, body: string, labels: [string], url: string}; fix_issue returns {run_id: string, status: string}; run_status returns {status: string, pr_url?: string, error?: string, iteration: number, created_at: string}.
• Expand descriptions to 50 - 150 chars. E.g., fix_issue: 'Asynchronously start a full GitHub issue fix pipeline (plan → code → test → review → draft PR). Returns run_id immediately; poll run_status to track progress. Requires valid GitHub credentials.'
• Add parameter constraints and format guidance. E.g., repo: 'Repository in owner/name format (e.g., torvalds/linux). Both owner and name must be alphanumeric or hyphens.'; base_branch: 'Git branch name (optional, defaults to repo default). If omitted, uses main or master.'
• Add error handling guidance to fix_issue description: 'If the pipeline fails, check run_status for error details. Errors are typically retryable (API rate limits, transient network issues) or user-fixable (invalid issue, missing credentials). Contact support for persistent failures.'
• Declare fix_issue as non-idempotent and potentially destructive. Add note: 'This tool creates a draft PR and may modify the repository. Ensure the issue is valid before calling. Retrying with the same run_id is safe; retrying with a new call may create duplicate PRs.'