src/mcp/mod.rs ignores AI_MEMORY_LLM_BACKEND — MCP stdio mode hardcoded to Ollama (post-#1067 surface gap)

[alphaonedev]

Severity: HIGH (post-#1067 surface gap — documented v0.7.0 feature unreachable from MCP)

Affected code: src/mcp/mod.rs:2139-2164 (the let llm: Option<Arc<OllamaClient>> init block)

Symptom: running ai-memory mcp --tier autonomous with AI_MEMORY_LLM_BACKEND=xai, AI_MEMORY_LLM_MODEL=grok-4.3 in env produces this boot banner:

ai-memory: connecting to Ollama for Gemma 4 Effective 4B (Q4) ...
ai-memory: Ollama connected, ensuring model gemma4:e4b is available...
ai-memory: LLM ready (Gemma 4 Effective 4B (Q4))

The env vars are IGNORED. The MCP daemon connects to local Ollama for Gemma 4 every time regardless of the operator's selector.

Root cause: #1067 (v0.7.0 LLM-vendor-agnostic backend selector) landed the env-aware OllamaClient::from_env resolver into src/daemon_runtime.rs:1746-1798 (the serve HTTP daemon path). The MCP stdio path in src/mcp/mod.rs:2139 was NOT updated — it still does the legacy OllamaClient::new_with_url(ollama_url, model_id) with model_id = llm_model.ollama_model_id().

CLAUDE.md §"Feature tiers" claims: "Post-#1067 (v0.7.0): tier no longer dictates LLM vendor. Any tier can speak to any provider — local Ollama, xAI Grok, OpenAI, Anthropic, Google Gemini, DeepSeek, ..." — but for the MCP surface this claim is false until this gap is closed.

Proposed fix: mirror the daemon_runtime.rs:1756-1799 env-aware path into the MCP init: check AI_MEMORY_LLM_BACKEND first; if set, use OllamaClient::from_env; else fall through to the legacy tier-default Ollama path.

Operator impact: Codex CLI configured to use ai-memory MCP with AI_MEMORY_LLM_BACKEND=xai cannot access xAI Grok. Same gap for any client that wires ai-memory through ai-memory mcp stdio (Claude Code, Cursor, ChatGPT Desktop fallback, Continue.dev, etc.) — the entire MCP integration surface is locked to Ollama.

Release-gate impact: v0.7.0 documents provider-agnostic LLM dispatch but the MCP surface (where most clients consume the substrate) hardcodes Ollama. Fix required before ship.

[alphaonedev]

Fixed via commit f515120. Ported the env-aware AI_MEMORY_LLM_BACKEND resolver from src/daemon_runtime.rs:1746-1798 into src/mcp/mod.rs MCP stdio init. Smoke evidence: AI_MEMORY_LLM_BACKEND=xai AI_MEMORY_LLM_MODEL=grok-4.3 ai-memory mcp --tier autonomous --profile full boots with banner LLM ready (backend=xai, model=grok-4.3) — the pre-fix connecting to Ollama for Gemma 4 line is gone. tools/list returns 73 entries (full profile). Codex CLI MCP wiring at ~/.codex/config.toml now reaches xAI Grok end-to-end. Verified per prime directive pm-v3 (memory cd8ede94).

[alphaonedev]

QC follow-up landed: filed and closed #1143 covering four sibling LLM-init bypass sites + one embed-client wire-shape mismatch that the original #1142 narrow fix had not closed:

1. src/cli/commands/atomise.rs::build_llm_curator — atomise CLI was locked to local Ollama.
2. src/cli/curator.rs::build_curator_llm — curator CLI (sweep / reflect / daemon) was locked to local Ollama.
3. src/daemon_runtime.rs::run_curator_daemon_with_primitives — legacy primitive entrypoint ignored env.
4. src/mcp/mod.rs embed-client fallback — when embed_url == ollama_url and AI_MEMORY_LLM_BACKEND set to a non-Ollama vendor, the embed client cloned the OpenAI-compatible chat client and sent /api/embed requests to an endpoint that doesn't exist on xAI / Anthropic, silently breaking semantic recall.

Fix shipped in commit 8d51118 via a shared OllamaClient::build_for_init(legacy_url, legacy_model) helper + a new is_ollama_native() introspector. Six new regression tests in src/llm.rs::wiremock_tests::*_1143. 4681/4681 lib tests green. The post-#1142 smoke that this comment thread claimed (LLM ready (backend=xai, model=grok-4.3)) is now joined by LLM client is OpenAI-compatible (non-Ollama wire shape); building dedicated Ollama embed client at <embed_url> (#1143) which proves the embed path doesn't get hijacked anymore.

Also fixed a drive-by pre-existing compile error in src/handlers/kg.rs:593 (missing use crate::models::Memory) that was blocking cargo build --release at HEAD f515120.

Verified per prime directive pm-v3 (memory cd8ede94).