Six read-only tools with clear, domain-specific naming (optics_list_runs, optics_get_run, optics_prove, optics_discover_local, optics_explain, optics_upgrade_path). All have descriptions (50 - 150 chars, within baseline 34 - 392). Input schemas present with type definitions and parameter descriptions. However, output schemas are not documented in the source code, LLMs cannot predict return structure. Error handling is minimal; no recovery guidance. Tool composition is sound (each does one thing), but descriptions lack WHEN/WHY context that would optimize LLM selection. No tool annotations (readOnlyHint, etc.) despite all being read-only.

• Document output schemas for all tools. E.g., optics_list_runs should specify: returns {runs: [{trace_id, timestamp, status, ...}], total_count, next_cursor}. LLMs need this to plan downstream calls.
• Add readOnlyHint: true to all tool definitions. This signals to LLMs that these tools are safe to call speculatively and can be retried without side effects.
• Enhance descriptions with WHEN context. E.g., 'optics_explain: Call this first to understand Optics capabilities and privacy boundaries. Optionally include latest run summary to show what data is captured.'
• Add error recovery hints. E.g., optics_get_run: 'If trace_id not found, call optics_list_runs to discover available IDs, or use "latest" to fetch the most recent run.'
• Clarify optics_upgrade_path output. Specify what fields/structure it returns (e.g., product names, pricing tiers, feature comparisons) so LLMs know how to present it to users.