Repro

With FAL_KEY, XAI_API_KEY, and any xAI OAuth all absent, hermes doctor's Tool Availability section shows:

⚠ Video Generation       (system dependency not met)
⚠ Image Generation       (system dependency not met)

Operator has no signal about WHICH env var would unblock them. They have to know to read the plugin docs to discover the FAL_KEY / XAI_API_KEY / OpenAI options.

Cause

tools/video_generation_tool.py registers with requires_env=[] because the toolset is multi-provider (any of FAL, xAI works). Same for image_gen. Doctor's for item in unavailable: loop falls through to check_warn(name, "(system dependency not met)") when missing_vars is empty — the generic, unhelpful fallback.

Other plugin-driven multi-provider toolsets that pick the first available provider have the same shape, but image_gen + video_gen are the two shipped today.

Fix

Add a _doctor_tool_unavailable_detail(toolset) -> str helper, parallel to the existing _doctor_tool_availability_detail (which decorates AVAILABLE rows). Returns a per-toolset hint:

• image_gen → "no image-gen provider configured — set OPENAI_API_KEY, XAI_API_KEY, or use OpenAI Codex OAuth (see hermes tools)"
• video_gen → "no video-gen provider configured — set FAL_KEY, XAI_API_KEY, or use xAI OAuth (see hermes tools)"

Then in the unavailable loop, prefer the per-toolset detail over the generic (system dependency not met) string when one is available.

Out of scope

• Generalizing: register-time declaration of "alternative env-var sets" for any multi-provider toolset. That's a registry-API change. The two shipped toolsets are addressable today with the per-toolset helper.
• Per-provider sub-probes inside doctor (would tell you "FAL_KEY is set but the key looks malformed"). Different shape — closer to hermes doctor: Mem0 check stops at API-key presence — no reachability probe (vs Honcho which connects) #34/doctor: Mem0 reachability probe with auth/network classification (#34) #35 Mem0 probe. Defer.

Filed by hermes-maintainer (PowerCreek). PR incoming.