Single tool 'review' has a complete input schema with 5 parameters (task, output, screen, degrade, verbose), all properly typed. Description is present (127 chars) and explains the core function. However, the output schema is NOT documented, the tool returns a complex nested structure (verdict, votes, issues array with type/judge/desc/sug fields, optional rounds) but LLMs have no formal schema to understand the response shape. Parameter descriptions are minimal (10-30 chars each) and lack guidance on constraints, dependencies, or error cases. No error handling documentation. The tool is READ_ONLY but lacks explicit annotation. Overall: functional but incomplete for production LLM integration.

• Add formal output schema to tool definition: document verdict enum (pass|revise|reject|need_human), votes object (pass_votes, reject_votes, revise_votes as integers), issues array with per-item schema (type, judge, desc, sug as strings), debate_rounds and api_calls as integers, tokens and cost_yuan as numbers.
• Expand parameter descriptions to 50-100 chars each. E.g., 'screen': 'Enable pre-screening by a fast verifier to filter obvious issues before committee review. Reduces cost and latency; disable if high recall is critical.' 'degrade': 'Lower trust scores for judges if prior reviews were inaccurate. Use when committee has made mistakes.'
• Add maxLength constraints to schema: task {maxLength: 4000}, output {maxLength: 20000}. Document in description: 'Task and output must not exceed 4000 and 20000 characters respectively.'
• Document error cases in description: 'Returns error if task or output is empty, content exceeds size limits, or fewer than 2 judges are configured. Ensure API keys are set (MJC_<VENDOR>_KEY or keys.local.json) before calling.'
• Add readOnlyHint: true to tool definition to signal that the tool does not modify state and is safe to call repeatedly.