Provides graph/relationship memory for GZMO, enabling memory to be stored and queried as a graph.
Provides a hot session/cache plane for GZMO memory, supporting fast session state and caching.
Provides durable local vault storage with full-text search for curated memory.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gzmo-pi check my memory status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
GZMO curated memory for Pi — Pi extension + MCP (via bundled pi-mcp-adapter).
Local-first by default (~/.gzmo SQLite vault). Optional living stack (Redis, Neo4j, Qdrant) documented below for operator hosts.
Gallery / install:
pi install npm:gzmo-piThen in Pi:
/gzmo setup
/reloadCall gzmo_memory_status / gzmo_memory_search.
Piece | Role |
This package | Pi extension ( |
pi-mcp-adapter (bundled) | Lazy MCP tools so context stays small |
GZMO binary | Product MCP server ( |
Product tools: gzmo_memory_status, gzmo_memory_search, gzmo_memory_turn_start, gzmo_memory_recall_pull, gzmo_memory_chain, gzmo_memory_profile, gzmo_wiki_search.
Related MCP server: engram
Install GZMO binary + init vault:
curl -fsSL https://raw.githubusercontent.com/maximilianwruhs-cyber/GZMO/main/scripts/install-gzmo.sh | bashInstall this Pi package:
pi install npm:gzmo-piWire MCP + verify:
/gzmo setup
/gzmo statusRestart Pi or /reload, then use gzmo_memory_status.
Manual MCP shape (if you prefer editing files):
{
"mcpServers": {
"gzmo-memory": {
"command": "/home/YOU/.local/bin/gzmo",
"args": ["mcp-serve"],
"env": {
"GZMO_CONFIG": "/home/YOU/.gzmo/gzmo.toml",
"GZMO_ALLOW_LAB_VAULT": "1",
"GZMO_PRODUCT": "1"
}
}
}
}Written to ~/.config/mcp/mcp.json and ~/.pi/agent/mcp.json by /gzmo setup.
The product path above is intentionally minimal: SQLite vault, embeddings off, no LAN services.
For the full curated-memory topology (operator / multi-host — honeypot at scale, graph, vectors):
Service | Typical role in GZMO |
SQLite | Durable vault + FTS (always) |
Redis | Hot session / cache plane |
Neo4j | Graph / relationship memory MCP |
Qdrant | Vector recall (when embeddings enabled) |
Use the full repo: maximilianwruhs-cyber/GZMO
Read:
docs/PRODUCT_MCP.md — product vs ops tools
Living / CT101 deploy docs in that repo (docs/CT101_DEPLOY.md, docs/PI_GZMO_MEMORY_INTEGRATION.md)
Deploy Redis + Neo4j + Qdrant next to your living gzmo.toml
On the operator machine, prefer scripts/install-shared-mcp.sh (LAN gzmo-memory + Neo4j) instead of the laptop product fragment
Keep this gzmo-pi package on workstations for the SQLite product vault; keep living MCP on the host that owns Redis/Neo4j/Qdrant
In Pi: /gzmo living prints the short pointer.
Command | Action |
| Init |
| Binary, config, MCP wiring checklist |
| Pointer to full Redis/Neo4j/Qdrant stack docs |
git clone https://github.com/maximilianwruhs-cyber/gzmo-pi.git
cd gzmo-pi
npm install
pi install .Publish (maintainers):
npm login # interactive; or: npm config set //registry.npmjs.org/:_authToken=…
npm pack --dry-run # expect ~tens of KB, not tens of MB
npm publish --access public
# then: https://pi.dev/packages/gzmo-pipi-mcp-adapter is a normal dependency (installed by pi install / npm install), not bundledDependencies — bundling it pulled ~57MB of transitive SDK tree into the tarball.
Product binary / vault: GZMO
Pi packages: pi.dev/packages
MCP adapter: pi-mcp-adapter
This server cannot be deployed
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Hosted agent memory: store, search, and recall facts across sessions from any MCP client.
