Project Memory MCP Server

One small local server that gives any MCP-compatible AI coding tool the same persistent, searchable memory. Add a note once — from any tool, or by hand — and retrieve it from whichever tool you're in that day.

Why this works across tools

Antigravity and OpenCode are different products, but both speak MCP (Model Context Protocol) and both let you register a local server by giving them a command to launch it. Neither cares what's inside that server — it's just a subprocess they talk to over stdio. So instead of building "a memory feature for Antigravity" and "a memory feature for OpenCode," you build one server once, and register the same server.py in both tools' configs. Add Claude Code, Cursor, or anything else MCP-based later the same way, no extra work.

What's in this folder

File	Purpose
memory_store.py	Local vector store (ChromaDB, on-disk at ./chroma_db/) — add/search/list/delete
server.py	MCP server exposing that store as 4 tools, over stdio
ingest.py	Bulk-loads .md/.txt files from ./memory/ into the store
memory/example-notes.md	Demo notes — replace with your own

No external database, no account, no API key required for the default setup.

Setup

cd rag-memory-mcp
python3 -m venv venv
./venv/bin/pip install -r requirements.txt

The first time anything calls add_memory or search_memory, ChromaDB downloads a small local embedding model (~80MB, one-time). After that it runs fully offline — no per-query API calls, no per-query cost.

Seed it:

./venv/bin/python ingest.py

Get the absolute path to this folder (you'll need it for both configs below):

pwd

Wire it into Antigravity

Antigravity, its CLI, and its IDE share one MCP config file: ~/.gemini/config/mcp_config.json. You can also open it from inside the IDE: Settings → Customizations → Manage MCP Servers → View raw config. Add:

{
  "mcpServers": {
    "project-memory": {
      "command": "/absolute/path/to/rag-memory-mcp/venv/bin/python3",
      "args": ["/absolute/path/to/rag-memory-mcp/server.py"]
    }
  }
}

Then in Antigravity, refresh the MCP servers list (Manage MCP Servers → Refresh). project-memory's 4 tools show up alongside your others.

Wire it into OpenCode

Add to opencode.json — either globally at ~/.config/opencode/opencode.json, or per-project at opencode.json in a specific project's root if you only want it there:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "project-memory": {
      "type": "local",
      "command": [
        "/absolute/path/to/rag-memory-mcp/venv/bin/python3",
        "/absolute/path/to/rag-memory-mcp/server.py"
      ],
      "enabled": true
    }
  }
}

Restart OpenCode, or confirm it picked it up with opencode mcp list.

Using it day to day

Adding memories, two ways:

1. Write markdown in memory/ (one idea per paragraph — each becomes its own retrievable chunk), then re-run ingest.py. Add --wipe to rebuild from scratch instead of appending on top of what's there.
2. Just tell whichever agent you're talking to "remember that ___" — it calls add_memory directly, no ingest step needed.

Getting memories back: ask directly ("check memory for how I handled the Realtime bug before"), or make it automatic by adding a line to each tool's instructions (Antigravity: a rule/skill file; OpenCode: AGENTS.md or the instructions config key):

Before starting a nontrivial task, call search_memory with a short description of the task. When you learn something worth keeping — a decision, a root cause, a convention — call add_memory.

Testing it without any IDE

npx @modelcontextprotocol/inspector ./venv/bin/python3 server.py

Opens a browser UI where you can call each tool by hand and see raw results. Useful to confirm the server itself is healthy before debugging a specific tool's config. (Keep the Inspector on localhost only — don't expose its ports on a shared network.)

If you want memory synced across machines, not just local-only

Swap the ChromaDB calls in memory_store.py for Supabase + pgvector — same 4 function signatures (add_memory, search_memory, recent_memories, delete_memory), backed by a memories table with a vector column instead of ./chroma_db/. Since you're already running Supabase for Foster, this is mostly copy-pasting patterns you already have, and it means the same memory is reachable from any machine, not just the one where chroma_db/ lives.