Server has 10 tools with complete input schemas and descriptions present for all. Naming follows verb_noun convention (list_domains, get_domain, begin_run, etc.). However, descriptions are minimal (10-50 chars for most tools), lacking context on WHEN to use each tool, prerequisites, or what happens on failure. Parameter descriptions exist but are terse. No output schemas documented. Error handling guidance is absent. Tools like file_issues and submit_feedback lack confirmation/dry-run patterns despite irreversible/sensitive nature. No tool annotations (readOnlyHint, destructiveHint) visible in schema.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to call it in the audit flow, and what happens on error. Example: 'Record the audit result for a domain. Call after evaluating each domain against its rules. Returns success or error if run_id is invalid or domain already recorded.'
• Document output schemas for all tools. Specify what fields each tool returns (e.g., run_status returns {run_id, status, domains_completed, domains_total, current_domain}). This enables LLMs to chain tools correctly.
• Add tool annotations to schema: mark list_domains, get_domain, get_config, run_status as readOnlyHint=true; mark begin_run, start_config, record_domain_result, render_report as destructiveHint=true; mark file_issues as irreversible.
• Implement Multi Round-Trip Requests (MRTR) for file_issues: return {status: 'input_required', message: 'Confirm filing issues for domain X?'} and require a second call with confirmed=true before executing. This prevents accidental GitHub issue creation.
• Add error recovery hints to parameter descriptions. Example: 'run_id (string): The run ID from begin_run. If not found, ensure begin_run was called first and the run has not expired.'