AuditLens exposes 3 tools with significant definition gaps. Tool names lack action verbs (get-spans, add-dataset-examples, list-traces use hyphens inconsistently). Descriptions exist but are vague and lack WHEN/WHY context. Input schemas are present but incomplete: parameters lack type constraints, enums, or validation guidance. No output schemas documented. Error handling is absent, no recovery guidance or categorization. The tools appear to delegate to external MCP servers (Phoenix) rather than implementing core logic, which limits their autonomy and clarity.

• Rename tools to snake_case: get_spans, add_dataset_examples, list_traces. Update descriptions to 100 - 200 chars, explicitly stating WHEN to call (e.g., 'Call after evaluating a trace to fetch raw span data for compliance analysis').
• Document output schemas for each tool. E.g., get_spans returns {spans: [{span_id, trace_id, input, output, latency_ms}], total_count}. add_dataset_examples returns {added: N, failed: N, errors: [{example_idx, reason}]}.
• Add min/max constraints to numeric parameters: limit 1 - 100 for get_spans and list_traces. Add format/length guidance to string parameters: project_identifier must be 2 - 50 alphanumeric chars.
• Implement error handling with recovery guidance. E.g., 'Project not found. Verify project_identifier via list_projects() or check Phoenix dashboard.' Categorize errors: retryable (timeout, rate limit) vs user-fixable (invalid project) vs fatal (auth failure).
• Add idempotency guidance to add_dataset_examples: document whether duplicate examples are deduplicated or appended, and provide a dry_run parameter to preview changes before committing.