fix: elicitation fires for wrong users — DBT_HOST=None can't serve as both 'no platform' and 'please elicit host'

[b-per]

Background

PR #728 added MCP elicitation so users without DBT_HOST could be prompted to enter it interactively instead of getting a config error. In doing so it also removed the old conditional guards that disabled platform tools when DBT_HOST was absent.

PR #760 had to bypass ElicitingCredentialsProvider in _is_multi_project() to fix #759 (CLI users seeing "No tools" in Cursor). As a result, elicitation is now effectively disabled — ElicitingCredentialsProvider is wired only to Config.credentials_provider, which is no longer called from any hot path.

The core problem

DBT_HOST=None means two incompatible things at once:

1. "I am a CLI-only user — I don't need platform tools" (e.g. DBT_MCP_ENABLE_DBT_CLI=true, no host needed)
2. "I am a platform user who hasn't configured my host yet" (the target audience for elicitation)

There is no way to distinguish these two users from DBT_HOST=None alone. Any elicitation logic placed in the routing layer (_is_multi_project, list_tools, call_tool) will fire for both.

Additionally, validate_dbt_platform_settings checks legacy DISABLE_* flags and is blind to the newer DBT_MCP_ENABLE_* allowlist mode — so it incorrectly treats CLI-only users as needing platform credentials.

Options

Option 1 — New explicit opt-in flag

Add a new env var such as DBT_MCP_ENABLE_ELICITATION=true.

Elicitation only fires when:

• The flag is set, AND
• DBT_HOST is missing

Pros: Completely unambiguous — the user explicitly asked for interactive setup.
Cons: One more env var to document; users need to know it exists.

---

Option 2 — Reuse existing DBT_MCP_ENABLE_* toolset flags

Elicitation fires when:

• Any platform toolset is active (SEMANTIC_LAYER, DISCOVERY, ADMIN_API, SQL), AND
• DBT_HOST is missing

"Platform toolsets" need a host. "Local toolsets" (DBT_CLI, DBT_CODEGEN, DBT_LSP, PRODUCT_DOCS, MCP_SERVER_METADATA) never do. In default mode (no ENABLE_* flags set, all tools registered) platform toolsets are active, so elicitation fires — which is the right default for users who haven't configured anything yet.

Pros: No new env var; reuses existing, well-understood configuration.
Cons: Requires validate_dbt_platform_settings (or the elicitation trigger) to understand allowlist mode; slightly more logic.

---

Option 3 — Remove elicitation entirely

Revert to pre-#728 behaviour: DBT_HOST=None means local/CLI tools only; platform tools require DBT_HOST to be set explicitly.

Pros: Simplest; no ambiguity; power users are comfortable setting env vars.
Cons: Loses the interactive setup UX for non-technical users; the MCP elicitation infrastructure built in #728 goes unused.

---

Implementation note (applies to options 1 and 2)

Wherever elicitation is triggered, it must fire from inside the platform config providers (semantic layer, discovery, admin API), not from the routing layer. ElicitingCredentialsProvider should be passed to those providers so elicitation fires only when a platform tool actually needs a host — never for CLI-only tool calls.

[jairus-m]

@Muizzkolapo any thoughts here? Since you were the OG author of this feature!

Personally, in-between 2 and 3. 3 because elicitation only really helps with a single env var, but other env vars could still be misconfigured and users may be more confused.

[Muizzkolapo]

@jairus-m Just had a quick look. I am leaning towards option 2, the intent was to build the elicitation spine. DBT_HOST was just the first user. Moving the trigger into the platform config providers makes the most sense to me. I can start looking into that if we can all agree.

[jairus-m]

Yeah feel free to start looking into it! I'm aligned with that. It was also an option @b-per gave so Id assume he's okay with it as well. In the meantime, we can let Benoit chime in as necessary. Thanks!

[Muizzkolapo]

Okay will have a look.💯