TL;DR: Your `.env` file is not being read because the MCP server looks for it in its own working directory, not yours. Set `CHROMA_DOTENV_PATH` to the absolute path of your `.env` file, or put the variables directly in the client config `env` block.

```text
(env vars silently ignored; server behaves as if CHROMA_HOST etc. were unset)
```

## Fix it

1. Option A, absolute dotenv path. In the client config `env` block:

```json
{
  "env": {
    "CHROMA_DOTENV_PATH": "[HOME]/..."
  }
}
```

2. Option B, skip the file. Put the variables directly in the `env` block:

```json
{
  "env": {
    "CHROMA_CLIENT_TYPE": "http",
    "CHROMA_HOST": "YOUR_CHROMA_HOST",
    "CHROMA_PORT": "8000"
  }
}
```

3. Restart the MCP client.

   Expected: the server picks up the configured values. Connection succeeds.

## When to use this

- Variables in `.env` work when you run the server by hand but are ignored under the MCP client.
- The server behaves as if no configuration was given.

## When NOT to use this

- The values are wrong. A loaded-but-wrong value fails differently (auth errors, connection refused to the wrong host).
- You already use the `env` block. Then the file is irrelevant.

## Compatibility

- chroma-mcp with dotenv support.

## Why it happens

Relative dotenv paths resolve against the process working directory. Your terminal's directory and the MCP server's directory are different things (GUI clients often use the app bundle or system root). The default `.chroma_env` lookup misses, the server falls back to defaults, and nothing tells you the file was skipped.

## Edge cases

- The dotenv path itself must be absolute. A relative `CHROMA_DOTENV_PATH` has the same problem one level up.
- Command-line args beat env vars beat dotenv. If both are set, args win. Check for conflicts.
- Secrets in a `.env` file are still secrets. Keep the file out of git.