lifelog
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GRAPH | No | Set to none to turn Graphiti off; episodes then stop at indexed. | |
| DIARIZER | No | Set to none to skip speaker diarization, or pyannote to use it. | |
| HF_TOKEN | No | Hugging Face read token for pyannote speaker diarization. Optional for the MCP server; without it set DIARIZER=none. | |
| API_TOKEN | No | Token required before the HTTP server is reachable from anything other than this Mac, e.g. the iPhone app. Not needed for the stdio MCP server. | |
| ASR_BACKEND | No | Speech-to-text backend: gpt-transcribe, gemini-3.5-transcribe, or chirp_3. | |
| GEMINI_MODEL | No | Gemini model id sent to Google; use gemini-3.5-transcribe-preview if Gemini returns 403 or 404. | |
| OPENAI_API_KEY | No | OpenAI API key, needed only when using gpt-transcribe as the speech-to-text backend. | |
| CLAUDE_CODE_PROJECTS | No | Comma-separated Claude Code project folder names the worker may read. Empty means nothing is read. | |
| GOOGLE_CLOUD_PROJECT | Yes | Google Cloud project used for Gemini/Chirp speech-to-text, embeddings and the Graphiti graph. Required for the MCP server's search, summary, people and timeline tools. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchA | Tìm trong bộ nhớ của người dùng: hội thoại đã ghi âm và các phiên làm việc với Claude Code. Trả về hai phần. |
| summaryA | What the user did on one day or in one week, written from all sources: Claude Code sessions by project, recorded conversations and online meetings, the calendar, time spent in apps on the Mac, and pages read. |
| peopleB | Everything known about one person: how often and when their voice was recorded and who else was there, the latest conversations with them (with a short summary), calendar meetings they were invited to, chats with them on the Mac, their direct chats with the user on Zalo (how much, the groups they write in, the latest days with what each was about), what the memory has gathered about them, and the newest facts that involve them. Their Zalo name also finds them. |
| timelineA | How a topic changed over time, oldest first, grouped by day: the facts about it in the order they became true, including those marked ĐÃ HẾT ĐÚNG (true once, replaced later), next to the passages where it was discussed. Use it for "how did we end up deciding X" or "what happened with Y over the last weeks". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct query intent: free-text retrieval (search), day/week digest (summary), entity lookup (people), and chronological topic evolution (timeline). search and timeline both surface facts and episodes, which could cause minor misselection, but their framing (query-driven vs. time-ordered) keeps them separable.
All four names are single lowercase words with no mixed conventions (no camelCase/snake_case clashes), so the set reads predictably. They are not a strict verb_noun pattern and mix noun forms (people, timeline, summary) with a verb (search), a minor deviation.
Four tools is on the lean side but each occupies a genuinely different retrieval axis for a personal memory domain. Nothing appears redundant, though a couple more query surfaces might be expected given the breadth of data sources described.
The read-only query surface covers search, aggregation, entity, and timeline views, which matches a passively-ingested lifelog where writes are automatic rather than tool-driven. Minor gaps exist (e.g., no direct fetch-by-episode-id, no explicit listing of sources/projects), but workable via search.