Configurable embedding function (custom / OpenAI-compatible endpoint) #3030

Another real-world use case, plus verified constraints from digging into this today on v13.24.5.

Use case: CJK users get weak recall from both retrieval paths. My corpus is mostly Chinese. MiniLM-L6-v2 is English-centric, so the semantic path contributes little — and the FTS path is also broken for CJK in the server runtime right now (#3859). For non-English users, a configurable EF is the difference between search working and search being keyword-luck.

Verified constraints (for whoever picks this up):

• chroma-mcp has never exposed an --embedding-function flag in any published version — checked 0.2.6 (what the worker resolves via uvx today) and 0.1.13 (with mcp<2 pinned just to make it import). So spawn-args-only solutions are a dead end; the worker needs to pass embedding_function_name through chroma_create_collection and read paths, plus extend the uvx --with deps — exactly as designed in the OP.
• Migration detail worth designing for: existing collections are 384-dim and Chroma collections can't change dimension, so an EF switch needs a delete + re-embed path. The chroma smart-backfill already rebuilds from SQLite, so gating a re-embed on EF-change detection seems feasible.

One addition to the proposal: beyond API providers (OpenAI-compatible endpoints), please also consider local embedding models — e.g. BAAI/bge-m3 via sentence-transformers (1024-dim, strong multilingual/CJK performance, runs offline for free). Local-first fits claude-mem's positioning, and bge-m3 is the standard pick for CJK corpora. An env shape like CLAUDE_MEM_EMBED_PROVIDER=local-sentence-transformers + CLAUDE_MEM_EMBED_MODEL=BAAI/bge-m3 would cover it.

Happy to test any preview build on a mostly-Chinese corpus (~900 observations).