tailtest-mcp has 5 tools with generally clear naming and good descriptions, but significant gaps in schema documentation and parameter descriptions. Tool names follow verb_noun convention (tailtest_ping, tailtest_scenario_plan, tailtest_classify_failures, tailtest_pick_template, tailtest_setup) which is appropriate. Descriptions are descriptive and explain purpose well (avg ~180 chars, within 10-1024 baseline). However, INPUT SCHEMA documentation is inconsistent: tailtest_ping has a complete empty schema, but tailtest_scenario_plan, tailtest_classify_failures, and tailtest_pick_template have parameter schemas visible in the provided spec data, while tailtest_setup shows parameters in description but schema clarity is moderate. Output schemas are NOT documented anywhere, no indication of what these tools return beyond prose descriptions. Parameters lack comprehensive descriptions in the schema (e.g., 'runner_output' has description in the spec data, but many inferred parameter descriptions are missing from actual code visibility). Error handling is minimal, no evidence of recovery guidance, error categorization, or actionable error messages. Security is reasonable (no secrets exposed as parameters, mostly read-only operations except tailtest_setup which is marked WRITE). Composition is good, each tool has a single responsibility.

• Document OUTPUT schemas for all tools. For each tool, provide a JSON Schema or prose listing of returned fields, types, and examples. Example for tailtest_classify_failures: 'Returns {failures: [{type: "real_bug"|"environment"|"test_bug"|"unknown", reason: string, test_name: string, file: string, line: number, error_type: string, message: string}], summary: {real_bug_count: number, environment_count: number, test_bug_count: number, unknown_count: number}, total: number}'.
• Add pagination/limit parameters and result capping guidance. For tailtest_classify_failures: 'Returns up to 100 failures. If more exist, set limit parameter (1-1000) or use offset/cursor for pagination.' For tailtest_scenario_plan: 'Returns baseline scenarios (typically 5-20 per language/framework). If you need more, provide a limit_scenarios parameter (default 10, max 100).'
• Document error cases and recovery paths for each tool. Example for tailtest_scenario_plan: 'If file_path does not exist, returns error "File not found: <path>. Verify file_path is relative to project_root or provide absolute path." If framework detection fails, returns language baseline scenarios only with note "Framework not detected; using language-only templates."'
• Add a dry-run or plan-only mode to tailtest_setup. Example: 'Add preview: true parameter (optional, default false). When true, returns a report of what WOULD be written/skipped without actually writing files. Agents can verify changes before committing.'
• Enhance parameter descriptions with format/constraint guidance. Example for tailtest_scenario_plan file_path: 'Relative or absolute path to source file (e.g., src/main.py, tests/unit/test_auth.ts). Must exist and be readable.'