Server has 8 tools with complete JSON schemas and descriptions. Naming follows verb_noun pattern (open_*, close_*, launch_*, run_*, list_*). Descriptions are present (avg ~100 chars) but lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameter schemas are well-typed with descriptions. Critical gap: no error recovery guidance (e.g., 'If core dump not found, call list_crash_files()'), no output schema documentation, and mutual exclusivity in run_lldb_cmd is documented but not enforced with clear error messages. Tool composition is sound (each does one thing), but descriptions could better explain prerequisites and failure modes.

• Document output schema for each tool. E.g., 'Returns {status: string, backtrace: string[], threads: {id: number, name: string}[]}' so LLM knows what fields to extract.
• Add recovery guidance to error messages. E.g., 'Core dump not found at /cores/app.core. Call list_crash_files() to see available dumps in /cores/ and ~/Library/Logs/DiagnosticReports/'.
• Clarify mutual exclusivity in run_lldb_cmd: 'Exactly one of core_dump_path, remote_address, or program_path must be provided. Passing multiple or none will return an error.'
• Enhance descriptions with WHEN-to-use guidance. E.g., 'Use open_lldb_core to analyze a crash dump file. Use launch_debug to start a fresh debugging session. Use open_lldb_remote to attach to a running process on another machine.'
• Document what each boolean flag reveals. E.g., 'include_backtrace=true adds thread stack traces (useful for crash analysis); include_threads=true lists all threads (useful for deadlock detection).'

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

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