Server has 12 tools with complete input schemas derived from Pydantic models and descriptions present for all tools. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions exist but are minimal (avg ~30 chars, well below the 72-char baseline). Output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is present but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Tool naming is generally good (verb_noun pattern), but composition could be tighter, run_binary duplicates asan_run/lsan_run functionality.

• Document output schemas for all tools. Include field names, types, and descriptions. E.g., analyze_memcheck should document: {run_id: string, summary: {errors: int, leaks: int}, findings: [{type, location, severity}]}.
• Expand tool descriptions to 100-200 chars. Add WHEN to use, prerequisites, and how it differs from similar tools. E.g., 'Use analyze_memcheck for detailed memory errors; use asan_run for faster, instrumented analysis.'
• Add tool annotations: mark read-only tools with readOnlyHint=true; mark destructive tools (build_target, *_run) with destructiveHint=true; mark idempotent tools accordingly.
• Consolidate run_binary with asan_run/lsan_run or clearly document when to use each. If run_binary is a dispatcher, make that explicit in the description and document the 'analyzer' enum.
• Add parameter constraints: timeout_sec (min=1, max=3600), limit (min=1, max=100), leak_check enum (none|summary|full|reachable), analyzer enum (valgrind|asan|lsan).

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry