Single tool 'get_affected_tests' with clear, well-structured definition. Tool name uses action verb appropriately. Description is substantial (235 chars) and explains what/when/how clearly. Input schema is fully defined with proper JSON Schema structure, types, and parameter descriptions. Risk classification (READ_ONLY) is explicit. However, output schema is not documented, the tool returns text responses but no structured field definitions are provided. Error handling includes contextual guidance for recoverable failures (timeout, missing branch, git errors). Composition is focused (one job: identify affected tests). Minor gap: output schema documentation would improve LLM planning for downstream operations.

• Document the output schema explicitly. Add a comment or schema field describing that the tool returns: (1) on success with affected tests: newline-separated test FQNs, optionally followed by a note section listing unanalyzed file categories; (2) on empty results: 'No affected tests detected' or 'No changes detected against <ref>'; (3) on error: 'Error: <message>'. Structure this as a JSON object with 'tests: string[]', 'unanalyzedChanges?: string[]', 'error?: string' to enable downstream tool composition.
• Add structured output. Instead of returning plain text, return a JSON object with typed fields: { 'affected_tests': ['com.example.FooTest', ...], 'unanalyzed_files': [<list of file paths or categories>], 'total_affected': <count>, 'note': '<guidance if needed>' }. This enables LLMs to extract, filter, and pass results to downstream tools reliably.
• Classify timeout errors as retryable. Distinguish between timeout (recoverable, suggest increasing limit or breaking project into modules) vs. malformed inputs (user-fixable) vs. external failures (git command failed, check repo). Return error code or category alongside the message.
• Add a 'dry_run' or 'max_results' parameter to allow LLMs to scope analysis (e.g., 'I only want the top 10 affected tests' or 'show me what you would analyze without running the full diff'). This gives agents more control and faster feedback.
• Include examples in parameter descriptions to clarify expected formats. E.g., base_branch: 'Git ref to compare against (e.g., origin/main, origin/develop, HEAD~5). When omitted in deep scope, ariadne uses the repository default branch.'