Phoenix MCP has 5 tools with significant definition gaps. Tool names lack clear action verbs (phoenix_sense, phoenix_snapshot, phoenix_heal are domain-specific but not verb-noun patterns). Descriptions exist but are terse (10-80 chars, below the 50-200 char baseline for LLM optimization). Input schemas are partially visible but lack parameter-level descriptions and type constraints. The phoenix_mission tool accepts complex nested objects (goals array with id/depends_on/task fields) but these nested structures are not documented. No output schemas are documented. Error handling and recovery guidance are absent. Only 1 of 5 tools has descriptions approaching adequacy.

• Rename tools to verb_noun pattern: 'sense_check' → 'validate_artifact_check', 'snapshot_artifact' → 'create_artifact_snapshot', 'heal_artifact' → 'restore_artifact_from_snapshot', 'verify_trace' → 'validate_trace_integrity', 'mission' → 'execute_goal_mission'.
• Expand descriptions to 100-150 chars each. Example: 'phoenix_sense' → 'Validate that an artifact (file, command output, hash) conforms to a check definition. Returns pass/fail with details. Use this to verify system state before healing.'
• Document nested parameter structures. For 'check' object, define: kind (enum: command_exit, file_hash, ...), target (string: path or command), expect (string or number: expected value). For 'goals' array, define each goal object: id (string), depends_on (array of strings), task (object with fields...).
• Add output schemas to each tool. Example: phoenix_snapshot returns {snap_id: string, path: string, timestamp: ISO8601, check_status: 'green'|'red'}. This enables tool chaining and LLM planning.
• Add error handling guidance. Example: 'If check fails, call phoenix_heal with the snapshot ID. If no snapshot exists, call phoenix_snapshot first with a green check.'