What this means in practice
Memory Crystal uses several environment variables across the backend, MCP layers, and plugin/install flows.Most important variables
API keys
CRYSTAL_API_KEY— primary API key for Gemini-backed embeddings and related backend operationsGEMINI_API_KEY— legacy fallback ifCRYSTAL_API_KEYis not setOPENAI_API_KEY— still present in parts of the repo and some workflowsMEMORY_CRYSTAL_API_KEY— preferred client-facing API key variable for MCP clients
Backend URLs
CONVEX_URL— Convex deployment URLMEMORY_CRYSTAL_API_URL— preferred client-facing backend base URL for MCP clients
MEMORY_CRYSTAL_* names for client setup.
MCP / local runtime
CRYSTAL_MCP_MODECRYSTAL_MCP_HOSTCRYSTAL_MCP_PORT
Embeddings / provider selection
EMBEDDING_PROVIDER— currently important for backend behaviorGEMINI_EMBEDDING_MODEL
Local content / storage
OBSIDIAN_VAULT_PATH
Example
From.env.example:
How it actually works
Different variables matter to different layers:- backend/runtime
- MCP client/server setup
- plugin installation and local health checks
CRYSTAL_MCP_MODE=stdio.
Use CRYSTAL_MCP_MODE=http only when you explicitly want the deprecated local network MCP listener.
Commands / examples
Example check:Doctor script behavior
The repo’s doctor/smoke checks read these variables and will fail or warn when key values are missing. For example, withEMBEDDING_PROVIDER=gemini, the doctor expects a valid CRYSTAL_API_KEY or GEMINI_API_KEY.
Related docs
Source of truth
.env.examplescripts/crystal-doctor.shpackages/mcp-server/README.mdmcp-server/README.md