Other MCP clients
Any client with stdio or Streamable-HTTP support connects the same way.
Spomory doesn't do anything client-specific — every client above is just a different way of expressing the same two shapes: a local stdio command, or a remote URL with a header. If your client isn't listed, it almost certainly still works.
Local (stdio)
The pattern is the same everywhere: point the client's "command" (or equivalent) at uvx with args --from spomory[llm,embedding,mcp] spomory-mcp — this downloads and runs Spomory on demand, no install step — and pass it the LLM_API_KEY / LLM_BASE_URL / LLM_MODEL / EMBEDDING_MODEL environment variables. (Prefer a fixed, pinned install instead? Point command at the absolute path to memory-core-mcp inside a virtual environment installed outside ~/Documents.) Every MCP client that supports local stdio servers works this way — the only thing that differs is where that client keeps its own config file and whether it uses JSON, TOML, or a GUI form.
Where do these environment variables come from?
LLM_API_KEY is your key for whichever OpenAI-compatible provider you use for extraction — OpenAI, DeepSeek, Qwen, and others all work. LLM_BASE_URL and LLM_MODEL default to OpenAI if you leave them out; swap them to point at DeepSeek, Qwen, or any other OpenAI-compatible provider, or a fully local server (Ollama, vLLM, llama.cpp, MLX):
export LLM_API_KEY=...
export LLM_BASE_URL=https://api.deepseek.com # optional, defaults to OpenAI
export LLM_MODEL=deepseek-v4-flash # optional, defaults to gpt-4o-mini
export EMBEDDING_MODEL=BAAI/bge-m3 # optional, defaults to bge-m3Cloud (API key or OAuth)
Any client that supports a remote MCP server with custom headers can connect: URL https://api.yliuai.com/mcp-apikey/ for Streamable HTTP, or https://api.yliuai.com/mcp-apikey-sse/ for the older SSE transport — same x-api-key header either way. If a client only supports OAuth-based remote connectors (no custom-headers option), use the OAuth URL instead — https://api.yliuai.com/mcp — following that client's own connector-authorization flow.
Where does <your key> come from?
Get one instantly with curl — fine for your own testing:
curl -X POST https://api.yliuai.com/users/register \
-H "Content-Type: application/json" \
-d '{"email": "you@example.com"}'
# the api_key in the response (starts with mck_) is shown only this once -- save itThat hands you a key with no proof you control the email — fine for testing, but for real use, get one through the email-confirmation form instead, which actually verifies the address.
Get a verified key on the Cloud & Apps page →Make it actually get used
Connecting the tools doesn't mean your client reaches for them on its own — it needs to be told to call search_memory before answering and add_memory after you share something worth keeping. SKILL.md is a short instructions file that does that. How you load it is specific to each client: some auto-discover a skills folder the same way Claude Code does, others only have a custom-instructions or system-prompt field instead. Verified for this one:
A lot of coding-agent CLIs have converged on a shared .agents/skills/<name>/SKILL.md convention (Codex, Gemini CLI, Zed, DeepSeek Harness, Mistral Vibe, and others all read it) — try that path first. If your client doesn't pick it up, check its own docs for a skills feature or a custom-instructions/system-prompt field instead.
SKILL.md on GitHub →