memex
Enables secure syncing of the Memex database across multiple devices via Tailscale's private network.
Click on "Install 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., "@memexsearch my chats about the authentication flow"
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.
Memex
Your Claude.ai chats and your Claude Code sessions live in two worlds that never talk. Memex makes them one memory you can search from both.
Local-first MCP server that indexes your Claude.ai chat history and your local Claude Code / terminal sessions, and exposes them to Claude Code (stdio) and Claude.ai (remote MCP connector).
Status: alpha, 0.3.1 on PyPI. Phases 0 to 7 closed, security-audited (plus four adversarial red-team rounds). Shipped: hybrid search, live capture, auto-summaries, chat ↔ repo association, the Claude.ai remote connector (GitHub OAuth), Claude Code / terminal ingestion with secret redaction, one-command setup, cross-platform autostart, and one-click claude.ai history backfill.

End-to-end demo: from Claude Code, you ask about something you discussed on claude.ai. Memex searches your chat history (search_chats) and Claude answers from the real conversation. No copy-paste, no manual context handoff.
Install
One command installs uv + Memex and runs memex setup (registers the MCP server, installs the always-on capture service, indexes your local sessions, prints the pairing token):
# macOS / Linux
curl -LsSf https://raw.githubusercontent.com/dioniipereyraa/memex/main/scripts/install-pypi.sh | sh# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://raw.githubusercontent.com/dioniipereyraa/memex/main/scripts/install-pypi.ps1 | iex"Then the one browser step a terminal cannot do: install the Chrome extension, paste the token it printed, and click "Backfill claude.ai history". Other paths (pipx, uv tool install, from source) are under Installation.
Related MCP server: conversation-history-mcp
The problem
Brainstorming and planning happen in Claude.ai. Execution happens in Claude Code. The two worlds do not talk to each other: Claude Code cannot read a chat of yours from Claude.ai, not even the one that originated the task it is currently working on. The memory Anthropic shipped on Claude.ai (March 2026) is curated, not full history, and lives isolated inside Claude.ai.
Memex fills that gap: runs locally, indexes the entire corpus of your chats, and exposes them as MCP tools so Claude can search and pull past context whenever it needs to.
How it works
[Claude.ai]
↓ (official JSON export / Chrome ext)
[Ingestor] → [SQLite + sqlite-vec] → [local embeddings (fastembed / Ollama)]
↓
[core: storage + retrieval]
↓
[MCP stdio] ───→ Claude Code, Claude Desktop
[MCP Streamable HTTP] ─→ Claude.ai connectorDesign: pure core (storage, ingest, embeddings, retrieval) decoupled from transport. The same engine serves both stdio and remote MCP without a rewrite.
Installation
Quick install (one command)
Installs uv if needed (it brings the right
Python), installs Memex from PyPI, and runs memex setup to wire it into Claude
Code (MCP server + always-on capture service + local session indexing + the
pairing token). No git clone required.
# macOS / Linux
curl -LsSf https://raw.githubusercontent.com/dioniipereyraa/memex/main/scripts/install-pypi.sh | sh# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://raw.githubusercontent.com/dioniipereyraa/memex/main/scripts/install-pypi.ps1 | iex"The only step a terminal cannot do is the browser one: install the Chrome extension, paste the token the installer prints, and click "Backfill claude.ai history" to import your history. Embeddings work out of the box (a quantized 130 MB fastembed model downloads on first ingest; no Ollama, no API key).
A plain
pipx install memex-chats(oruv tool install memex-chats) followed bymemex setupdoes the same thing in two steps. The autostart service is generated for the wheel install too (launchd / systemd / a logon Scheduled Task), so no clone is needed for it.
From source (for development)
Clone the repo to get an editable install plus the extension source and service templates. You need git; the script installs uv and the pinned Python for you.
macOS / Linux
git clone https://github.com/dioniipereyraa/memex
cd memex
./scripts/install.shinstall.sh installs uv if you do not have it, runs uv sync, and verifies
the install with memex doctor. That is the whole setup.
Windows (PowerShell)
git clone https://github.com/dioniipereyraa/memex
cd memex
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1Same three steps as the macOS script (install uv, sync, verify). If git is not installed, get it from git-scm.com first.
Manual (any OS, if you prefer explicit steps)
# 1. Install uv (skip if you already have it):
# macOS/Linux: curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
git clone https://github.com/dioniipereyraa/memex
cd memex
uv sync # installs Python 3.13 + dependencies into .venv
uv run memex doctor # verifyUpgrading (already have memex)
Upgrade with the same tool that installed it, or the new version will not land
on your PATH. A previous install owns the memex executable, so installing again
with a different manager fails with "Executables already exist" and memex keeps
running the old version. (This is the usual reason memex sync seems to "not
exist" after an upgrade: an old pipx-owned memex shadowed a newer uv tool
install.)
# 1. Find which tool owns it:
which memex # macOS / Linux
Get-Command memex # Windows (PowerShell)
# 2. Upgrade with that tool:
pipx upgrade memex-chats # if pipx owns it
uv tool upgrade memex-chats # if uv owns itIf you want to switch managers, uninstall the old one first (pipx uninstall memex-chats or uv tool uninstall memex-chats), then reinstall. After upgrading,
memex --version shows the new version and memex doctor should pass.
Multi-device (optional)
To make Claude one memory across several machines, install Tailscale first (so each device has a stable private address), then opt in once per device:
memex setup --sync # opt-in, persisted: the always-on service is sync-reachableIt prints the single memex sync connect ... line to run on your other devices.
The choice is saved, so the service stays sync-reachable across reboots without
re-running anything. Full flow, security model, and the manual one-shot
alternative are in Syncing across your devices.
For a dual-boot machine (Linux and Windows that are never on at the same time),
use file-based sync instead: memex setup --sync-dir <shared-folder> on each OS,
pointed at the same folder. No Tailscale, no two devices online at once. See
Dual-boot or never-online-together.
First run
The fast path is one command:
uv run memex setupmemex setup wires everything end to end and is safe to re-run: it registers
the MCP server with Claude Code (claude mcp add), installs the always-on
live-capture service (launchd on macOS, systemd on Linux, a Scheduled Task on
Windows), indexes your local Claude Code sessions, and prints the access token
to paste into the Chrome extension. Each step degrades to a warning instead of
aborting the rest. Flags: --no-mcp, --no-autostart, --no-ingest,
--remote (also install the claude.ai connector agent), -y (no prompt).
After that, the only manual step left is installing the Chrome extension and pasting the token, so new chats are captured as you go.
Manual steps (if you prefer to run them yourself)
# 1. Request your official Claude.ai export (Settings → Privacy → Export data),
# then ingest it (first run downloads the embedding model, ~30s):
uv run memex ingest /path/to/your-export.zip
# 2. Optionally index your local Claude Code / terminal sessions:
uv run memex ingest-claude-code
# 3. Search, or wire it into Claude Code (see "Wiring it into Claude Code"):
uv run memex search "your query" -n 5
uv run memex stats(If you installed with a script, the commands above work as written. If you
installed the published PyPI package instead, drop the uv run prefix.)
Where your data lives. From a cloned repo, the database and exports stay in
<repo>/data. From auvx/pipinstall, they go to your OS data directory (~/Library/Application Support/memexon macOS,%LOCALAPPDATA%\memexon Windows,~/.local/share/memexelsewhere). Override withMEMEX_DB_PATH/MEMEX_EXPORTS_DIR.memex doctorprints the resolved path.
Using Memex (after setup)
Once memex setup finishes, nothing else needs launching: the capture server and
the indexers run in the background. You use Memex three ways.
1. From Claude Code (the main way). Setup registers the MCP server, so Claude Code can search your whole history and keep it fresh through these tools:
Tool | What it does |
| Semantic + keyword search across your claude.ai chats AND Claude Code sessions |
| Fetch a full conversation by id |
| Your most recent conversations |
| Conversations related to a topic or snippet |
| Index your local Claude Code sessions now (so the current one becomes searchable) |
| Sync with your other devices now (paired peers + the dual-boot shared folder) |
Just ask Claude Code naturally ("what did we decide about X in my claude.ai
chats?", "index this session", "sync this to my other devices") and it calls
these. index_terminal_sessions and sync_now are local-only (never exposed to
the remote claude.ai connector). Note sync_now sends what is already indexed, so
to include the session you are in, ask Claude to index_terminal_sessions first. To have context injected automatically at the start
of a session, add the optional SessionStart hook.
2. From the terminal. memex search "...", memex stats, memex doctor,
memex token (re-print the extension pairing token), memex --version.
3. Capture (automatic, you run nothing). The Chrome extension indexes a claude.ai chat as you open or reload it (and its "Backfill" button imports your old history once); your Claude Code sessions are indexed when a session ends, plus a 15-minute backstop.
How fresh is the data (real-time)?
Path | Latency |
A claude.ai chat into your local index | Near-instant: captured as you open/reload the chat (embedded in seconds) |
A Claude Code session into your local index | At session end, plus a 15-minute backstop |
Available to Claude Code on the same machine | Immediate (it reads the same local DB the capture writes) |
Across devices | Not live. Periodic + overlap: see below |
Same-machine is essentially real-time. Cross-device is not a live relay (it is
peer-to-peer with no cloud): paired devices auto-reconcile every 15 minutes while
both are online, and you can force it immediately with memex sync now. A
claude.ai chat is captured by the extension on open/reload, so to sync the latest
turns of an in-progress chat, reload it (so the extension re-captures it), then run
memex sync now. The terminal cannot read claude.ai directly, so the extension is
always what captures; sync only propagates what is already indexed locally.
Embeddings backend
Default is fastembed (zero-config). To route through a local Ollama instead (e.g. you already run it for other models):
export MEMEX_EMBED_BACKEND=ollama
ollama pull nomic-embed-text # install Ollama first: https://ollama.com/downloadOn Windows, install Ollama from ollama.com/download
before setting MEMEX_EMBED_BACKEND=ollama. This is optional; fastembed needs
none of it.
Diagnostics
Run memex doctor any time something is not working. It checks Python version, database, embedder, live-capture server, summarizer config, registered repos, and indexed corpus. Reports OK / WARN / FAIL per check.
Troubleshooting
Start with memex doctor (above): most of the issues below also surface there.
memex: command not found right after installing. The memex executable lives in the tool's bin directory, which may not be on your PATH in the current shell yet. Open a new terminal, or add it now:
macOS / Linux:
export PATH="$HOME/.local/bin:$PATH"Windows: re-open the terminal so the installer's PATH change takes effect (the bin dir is
%USERPROFILE%\.local\binforuv tool, or the pipx Scripts dir).
Then confirm the right binary: which memex (macOS/Linux) or where memex (Windows). It should point at the uv-tool / pipx install, not an old clone.
The extension shows the server as not responding, or ingest returns 401.
Is the server up?
curl -s http://127.0.0.1:5777/healthshould return JSON. If it does not, start it (memex serve) or check the autostart service below.401means the pairing token is missing or stale: runmemex token, copy the value, paste it into the extension popup, and click Save token.
The autostart service did not come up. Check its status, then read its log:
Linux:
systemctl --user status memex-serve; log at~/.local/share/memex/serve.log.Failed to connect to busmeans there is no user systemd manager for this session (common over plain SSH): runloginctl enable-linger "$USER", make sureXDG_RUNTIME_DIR=/run/user/$(id -u)is set, then re-runmemex install-service.macOS:
launchctl list | grep memex; log in the data dir (~/Library/Application Support/memex/com.memex.serve.logon a PyPI install,<repo>/data/serve.logfrom source).Windows: Task Scheduler, or
schtasks /Query /TN MemexServe /V; log at%LOCALAPPDATA%\memex\serve.log. If an older install left a task with the same name, it can silently mask the new one: delete it (schtasks /Delete /TN MemexServe /F) and re-runmemex install-service.
Autostart does not survive logout or reboot (Linux). A systemd user unit is torn down when your session ends unless lingering is enabled: loginctl enable-linger "$USER".
The one-command installer fails with a shell error. The installer is POSIX sh. If you are on a very old or unusual shell and the pipe fails, fetch and run it with bash instead: curl -LsSf <url>/install-pypi.sh | bash.
Windows: uv tool install fails with "Acceso denegado (os error 5)" copying memex-mcp.exe. Two causes, usually together:
Claude Code / Claude Desktop is running and its MCP child process holds the running
.exe. Close Claude Code and Claude Desktop, then retry.Windows Defender blocks writing a brand-new
.exeeven when nothing holds it. The tell: the destination file does not exist yet (Test-Path "$env:USERPROFILE\.local\bin\memex-mcp.exe"isFalse) but the copy still fails. Add a Defender exclusion for%USERPROFILE%\.local\binand%APPDATA%\uv.
Then re-run with uv tool install --force memex-chats (or uv tool install --reinstall --refresh <spec> when updating from a branch).
Windows: a paired device times out reaching your sync port (5777). In sync-reachable mode the always-on server binds 0.0.0.0:5777, but Windows Firewall silently drops inbound connections (the peer just times out, never "connection refused") until a rule allows the port. memex setup --sync adds it for you (idempotent, best-effort); if setup was not elevated it prints the one-time admin command to run yourself: New-NetFirewallRule -DisplayName "Memex sync 5777" -Direction Inbound -Protocol TCP -LocalPort 5777 -Action Allow.
Sync times out even though tailscale ping works. If tailscale ping <peer> succeeds but regular ping/TCP (and memex sync) time out in BOTH directions, the problem is a local TUN/routing conflict on one of the machines, not memex and not the firewall rule: another VPN-style adapter (Hamachi, another VPN, a virtual switch) is swallowing the OS traffic that should ride the Tailscale interface. Disable or remove the other adapter and restart the Tailscale service. (Seen live: a Hamachi adapter installed for game hosting broke a Windows box's Tailscale traffic while tailscale ping kept working.)
The first backfill (or first ingest) is slow. The first embed downloads a ~130 MB quantized model; that is one-time, later runs are fast. The backfill is incremental and safe to re-run, so a slow or interrupted first pass simply resumes where it left off.
Ingest uses too much memory. Peak RAM scales with the embed batch size. Lower it: set MEMEX_EMBED_BATCH_SIZE=1 (about 0.67 GB peak) in your environment or .env.
Where is my data? memex doctor prints the DB path. By default it is ~/.local/share/memex (Linux), ~/Library/Application Support/memex (macOS), or %LOCALAPPDATA%\memex (Windows) for a PyPI install, or <repo>/data from a clone. Override with MEMEX_DB_PATH / MEMEX_EXPORTS_DIR.
MCP server tools (v1)
search_chats(query, limit=5, source?, mode="hybrid", repo?)searches the corpus. Modes:hybrid(default, combines vector search + FTS5 BM25 via Reciprocal Rank Fusion),semantic(vectors only),lexical(FTS5 only, ideal for proper nouns or exact terms).sourcefilters by origin (conversations,design_chat,memory).repoboosts results associated to a registered repo (see "Repo associations" below). Deduplicated per conversation.get_chat(uuid, messages_limit=10, messages_offset=0)fetches a conversation with its messages, paginated.raw_contentis omitted; each message is truncated to 1500 chars to stay inside the client's token budget (worst-case response ~17k chars). Long chats are paginated withmessages_offset; maxmessages_limitis 100.list_recent_chats(limit=10, source?)lists the latest chats ordered by last update.find_related(context, limit=5, repo?)takes free-form text (a paragraph, a file contents, the current discussion) and returns chats that are semantically related. Pure vector search, no FTS, capped at 4000 input chars. Useful when you want "more like this" without typing a keyword query.
The stdio server (memex-mcp, used by Claude Code) also exposes two write/maintenance tools, so you can ask Claude to keep your memory fresh instead of dropping to a terminal. They are local-only: never registered on the remote claude.ai connector (they mutate the store and reach the network).
index_terminal_sessions()runs the incrementalingest-claude-codescan (indexes new/changed local Claude Code sessions, including the current one up to what is flushed to its transcript). Shares the single-flight ingest lock; returns counts.sync_now()runs an immediate two-way reconcile with every paired device and, if a shared folder is configured, a file sync. Requires sync enabled. It propagates what is ALREADY indexed, so to include the current session callindex_terminal_sessionsfirst.
Search is also reachable from the CLI with memex search "query" --mode {hybrid|semantic|lexical}. For databases created before the hybrid FTS5 work, run memex reindex-fts once to populate the lexical index.
Wiring it into Claude Code
Once your local database is populated (memex ingest), start the MCP server with uv run memex-mcp. For Claude Code to discover it automatically, add a .mcp.json file at the root of your project (or a user-level server in ~/.claude.json):
{
"mcpServers": {
"memex": {
"command": "uv",
"args": ["run", "memex-mcp"],
"cwd": "/absolute/path/to/the/memex/repo"
}
}
}Set cwd to the absolute path where you cloned Memex (where pyproject.toml lives). Restart Claude Code and the tools search_chats, get_chat, list_recent_chats will show up in the session.
The same searches are also available from the CLI via uv run memex search "..." if you prefer them outside Claude Code.
Connecting from claude.ai (remote MCP, Phase 4)
memex serve-remote exposes the same 4 tools as a custom connector for claude.ai. One connector works across claude.ai web, Claude Desktop, and the mobile apps: the connection is brokered by your Claude account and always originates from Anthropic's cloud, never from your device. That has two consequences:
The server must be reachable on a public HTTPS URL (a hostname with a public IPv4
Arecord;localhostand private IPs are rejected by design). The intended setup is a tunnel that terminates TLS and proxies to Memex on loopback.Auth is either none or full OAuth 2.0 (claude.ai has no field to paste a token). Memex uses OAuth backed by a GitHub OAuth App, restricted to an allow-list of GitHub usernames: anyone else who completes the OAuth dance still gets a 401 on every request. Your machine must be on (and the tunnel up) for the connector to respond.
1. Publish a URL with Tailscale Funnel
Install Tailscale, log in, then:
tailscale funnel --bg 8377This prints your public URL, e.g. https://my-mac.my-tailnet.ts.net, TLS included. Any other tunnel works the same way (ngrok, Cloudflare Tunnel); Memex only needs the resulting https:// URL.
2. Create a GitHub OAuth App
At github.com/settings/developers > OAuth Apps > New OAuth App:
Homepage URL: your funnel URL.
Authorization callback URL:
<funnel URL>/auth/callback.
Copy the Client ID and generate a Client Secret.
3. Configure and run
In .env (see .env.example):
MEMEX_REMOTE_BASE_URL=https://my-mac.my-tailnet.ts.net
MEMEX_GITHUB_CLIENT_ID=Iv1.xxxxxxxxxxxx
MEMEX_GITHUB_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxx
MEMEX_REMOTE_ALLOWED_GITHUB_LOGINS=your-github-usernameuv run memex serve-remote # listens on 127.0.0.1:8377, endpoint at /mcpThe server refuses to start with incomplete config (no insecure defaults: an empty allow-list would expose your whole chat history to any GitHub account).
4. Add the connector in claude.ai
Settings > Connectors > Add custom connector, with URL https://my-mac.my-tailnet.ts.net/mcp. claude.ai registers itself via dynamic client registration, sends you through the GitHub authorization, and the tools appear in your chats. OAuth state is persisted encrypted on disk, so restarting serve-remote does not break the connection.
Security model in short: loopback bind + tunnel, OAuth proxy over GitHub with a username allow-list enforced on every request (revoking the app on GitHub locks it out immediately), TrustedHostMiddleware pinned to the public hostname, and the same indirect-prompt-injection envelope on tool results as the stdio transport.
Indexing Claude Code / terminal sessions (Phase 6)
Memex also indexes your local Claude Code and terminal sessions, so a single search covers both halves of your history: what you discussed on claude.ai and what you built with Claude Code. Claude Code records each session as a JSONL file under ~/.claude/projects/; Memex reads them directly (no extension, no network). This covers Claude Code wherever it runs, the terminal CLI and the VS Code / JetBrains extensions alike: they all write the same transcripts.
uv run memex ingest-claude-code # scans ~/.claude/projects/**/*.jsonl
uv run memex ingest-claude-code --path /custom/path # alternate rootThese sessions are stored under the claude_code source, searchable like any other chat (and filterable with source="claude_code"). Details:
Incremental. Unchanged sessions are skipped (by content hash), so re-running after more work is cheap. Sessions grow append-only, so a re-scan picks up new turns and new sessions. Re-run it whenever you want to refresh, or wire it to a schedule.
Repo-aware for free. Every session carries its working directory, so each is auto-associated with the registered repo of that
cwd(runmemex repos add <path>first).search_chats(repo=...)then boosts the sessions where you worked on that project.What is indexed: your prompts, the assistant replies, and tool calls as
[tool_use: ...]/[result]markers. Excluded: assistant internal reasoning (thinking), parallel sub-agent side threads, and CLI plumbing (slash-command echoes, bash wrappers). Everything stays in the local SQLite DB.Secret redaction. Session logs capture real terminal output and file contents, which often contain credentials. Before storing, Memex masks common secret shapes (API keys, bearer/JWT tokens, PEM private keys,
KEY=/SECRET=assignments, URLs with embedded passwords) as[REDACTED:...], and does not persist the raw block content for this source. Best-effort, not a guarantee: it catches well-known formats so third-party credentials that were never really part of a conversation stay out of the index (this matters because the remote connector can surface indexed text to claude.ai).
Getting a Claude Code session indexed
A session becomes searchable once its transcript is scanned. Day to day there are three ways to trigger that yourself:
Ask Claude. Say "index this session" and Claude calls the
index_terminal_sessionsMCP tool (the current conversation is captured up to what Claude Code has flushed to its transcript at that point). Follow with "sync my devices" (sync_now) if you want it on your other machines right away.Close the conversation. With the SessionEnd hook below installed, ending the Claude Code chat (just the conversation, not the whole terminal) ingests that session the moment it closes.
Run the command.
memex ingest-claude-codescans everything new right now.
Even if you do none of these, the periodic backstop below picks up new and grown sessions within about 15 minutes of their last write. The two automatic mechanisms complement each other (both run in the background at low priority, and the embedding model only loads when there is something new, so they barely cost anything):
SessionEnd hook — ingests a session the moment it closes (no delay, nothing lost). Add to
~/.claude/settings.json:{ "hooks": { "SessionEnd": [ { "matcher": "*", "hooks": [ { "type": "command", "command": "/absolute/path/to/memex/scripts/session-end-hook.sh" } ] } ] } }The hook reads the closed session's
transcript_pathand ingests just that one session, detached, returning immediately (SessionEnd hooks cannot block Claude Code).Periodic backstop — a scheduled scan that catches anything the hook missed (e.g. a crash). On macOS, with launchd:
sed "s|__REPO__|$(pwd)|g" scripts/com.memex.ingest-claude-code.plist.template \ > ~/Library/LaunchAgents/com.memex.ingest-claude-code.plist launchctl load ~/Library/LaunchAgents/com.memex.ingest-claude-code.plistIt runs
scripts/scheduled-ingest.shevery 15 minutes as a low-priority background job. A PyPI install does not need these manual steps on macOS or Windows:memex setup(ormemex install-service) already schedules the backstop there (thecom.memex.ingest-claude-codelaunchd agent / theMemexIngestScheduled Task). On Linux the installer sets up only the serve, so wire the backstop yourself with a systemd user timer or cron runningmemex ingest-claude-code.Per-OS state of the two mechanisms: the SessionEnd hook script is bash, so it works on macOS and Linux; on Windows it needs a PowerShell equivalent of
session-end-hook.sh, not yet included, so there the ways in are the backstop task, asking Claude, or the manual command.
Syncing across your devices
If you run memex on more than one machine (say a laptop and a desktop), memex sync makes Claude one memory across them: index a chat on one device and search
it from the other. Each device keeps its own local store and they sync
peer-to-peer, with no central server and nothing leaving your hardware. The sync
needs both devices powered on and reachable at the same time (it is overlap
sync, not a cloud relay). It ships in memex 0.4.0+; on an older install,
upgrade first (uv tool upgrade memex-chats).
The whole feature is off by default and exposes nothing until you turn it on. While it is off, the sync endpoints return 404 and the sync commands refuse, so a normal single-device install has no extra surface.
Set it up once (recommended)
Install Tailscale on each device first, then opt in once:
memex setup --syncThis is the normal setup plus one thing: it turns sync on and makes your
always-on capture service sync-reachable on this device's Tailscale address
(it binds 0.0.0.0 so one server still answers the local extension, with the Host
allow-list pinned to loopback + your Tailscale IP, resolved at startup, and the
per-install token gating access). The choice is persisted: set it once and the
service comes up sync-reachable on every reboot, so you never hand-run a serve
command. It prints the single line to run on each other device:
memex sync connect --url http://100.x.y.z:5777 --token <TOKEN> --name my-macconnect turns sync on there, pairs, and runs a two-way reconcile, so that device
is set up and caught up in one step.
Set-and-forget: memex setup --sync also enables auto-sync, so paired
devices reconcile by themselves every 15 minutes while both are online (no env var,
no cron). It is overlap sync, not a cloud relay: if the other device is off, that
tick is skipped and catches up next time both are on. On top of the timer, a
capture also triggers a sync a few seconds after it lands: when the Chrome
extension captures a chat and Memex indexes it, that new conversation is pushed to
your other devices right away (no need to run anything). A burst of captures (a
backfill, several open tabs) is coalesced into one sync once it settles, and it
only fires while both devices are on (for a dual-boot the other OS just picks up
the change on its next boot). Turn just this off with MEMEX_SYNC_ON_CAPTURE=false;
tune the coalescing window with MEMEX_SYNC_ON_CAPTURE_DEBOUNCE_SECONDS (default
10). You can still sync immediately by hand between ticks (e.g. to push the chat
you are having right now), with:
memex sync now # immediate two-way reconcile with every paired devicememex sync now propagates what is already indexed locally; a claude.ai chat is
indexed when the extension captures it (on open/reload), so reload an in-progress
chat first if you want its latest turns included. memex sync status shows what is
paired and the last sync; memex sync reconcile is the same as now. Turn the
whole thing back off (loopback-only, sync + auto-sync off) with memex setup --no-sync. Tune the interval with MEMEX_SYNC_INTERVAL_SECONDS (default 900).
One-shot (without changing your setup)
If you would rather not make the service permanently reachable, start a temporary endpoint on the device that has the conversations:
# SOURCE device:
memex sync serve
# -> Memex sync serve reachable at http://100.x.y.z:5777
# On the other device, run this one command:
# memex sync connect --url http://100.x.y.z:5777 --token <TOKEN> --name my-macmemex sync serve works the same on macOS, Linux, and Windows (it uses your
Tailscale address, so there is no per-OS network setup and no --host/allow-list
juggling). If you are not on Tailscale, pass --host <address the other device can reach>. It binds to that address only and runs alongside your loopback capture
server without a port clash; keep it up while the other device connects, then stop
it with Ctrl+C. Afterwards, memex sync reconcile re-syncs an already-paired device.
reconcile is the usual command: it syncs both ways and converges the two
devices, keeping the newer copy of anything that exists on both (last writer wins
by update time). If the same conversation was edited on both devices with the
exact same timestamp, that is a conflict: reconcile leaves both copies
untouched and reports it, and you pick a winner with a one-directional memex sync pull --peer mac (take the peer's) or push --peer mac (send yours).
Every sync only transfers conversations that are new or changed, brings their
embeddings along so your machine never re-embeds, and is idempotent (re-running
moves nothing new). A large history transfers in size-bounded batches
automatically, so it works no matter how many conversations you have (tune the
target with MEMEX_SYNC_MAX_BATCH_BYTES, default 8 MB; a single conversation
larger than the peer's MEMEX_INGEST_MAX_BODY_BYTES is skipped with a clear
message). Both devices must use the same embedding model (the sync refuses on a
mismatch). The peer's token is stored user-only (0600) next to the DB. Pairing is
a trust decision (it shares an access token), so only pair devices you control.
Never sync the SQLite file itself with a folder-sync tool; always use memex sync, which is consistent at the conversation level.
Auto-sync (the every-15-minutes reconcile) is turned on for you by memex setup --sync; you do not need an env var. Under the hood it reconciles with each paired
peer on startup and every MEMEX_SYNC_INTERVAL_SECONDS (default 900), skipping a
peer that is offline and backing off while an ingest is running. If you did not use
setup --sync (e.g. a manual/dev setup) you can still enable it with
MEMEX_SYNC_AUTO=true before memex serve; either the persisted flag or the env
var starts the loop. It only runs while sync is enabled; turn the whole feature
back off with memex sync disable (or memex setup --no-sync).
Dual-boot or never-online-together (file-based sync)
Network sync needs both devices online at the same time. That never happens on a
dual-boot machine (Linux and Windows on the same disk, only one running at a
time), and is awkward for any pair of devices that are rarely on together. For
that, memex has a second sync mode that uses a shared folder instead of a live
connection: each OS exports a snapshot of its store to the folder and imports the
others'. No server, no port, no token, no third device. It ships in memex 0.4.4+.
Point every OS at the same shared folder (one command per OS):
# On Linux (the Windows partition mounted at, e.g., /mnt/windows):
memex setup --sync-dir /mnt/windows/memex-sync --device-name linux
# On Windows (the SAME physical folder, its path there):
memex setup --sync-dir C:\memex-sync --device-name windowsThat is it. From then on each OS, when it boots, auto-syncs through the folder
(every 15 minutes while running), and memex sync now syncs immediately. The
folder is created for you if it does not exist, and the choice is persisted, so
you set it up once.
Where to put the folder on a dual-boot: it must be readable from both OSes, so put it on the Windows / NTFS partition. Linux reads and writes NTFS out of the box; Windows cannot read Linux's ext4. (For two separate machines that are rarely on together, any shared location works: a USB drive, or a cloud-synced folder like Dropbox.)
Dual-boot gotcha: Windows Fast Startup (and hibernation) leaves the NTFS
partition dirty, so Linux mounts it read-only, and file sync needs to write
its snapshot there (the initial export fails loudly if it cannot). If the folder
mounts read-only on Linux, disable Fast Startup on Windows (or powercfg /h off)
and shut Windows down fully once.
How it converges: a device only ever writes its own <device>.memexsync.gz and
reads the others', so they never clash. Sync is last-writer-wins by update time,
exactly like the network mode, and a same-timestamp conflict (a fork) is left
untouched and reported. The other OS's newer conversations land on your next boot
(it left its snapshot on disk), and yours reach it on its next boot. Give the two
OSes distinct --device-name values if their hostnames are the same, or they
would overwrite each other's snapshot. The snapshot carries your conversation text
and vectors, so keep the shared folder somewhere only you can read (the same "only
share what you control" rule as pairing a peer). The two modes are independent: you
can use file sync, network sync, or both.
Rotating a token
Each device has one access token (the ingest_token file next to its database;
memex doctor shows the folder). Rotate it whenever it was pasted somewhere it
should not live: a chat, a screenshot, a ticket. There is no rotate command yet,
and the running server reads the file only once, so the order matters:
Delete the token file (
rm <data-dir>/ingest_token; PowerShell:Remove-Item -Force $env:LOCALAPPDATA\memex\ingest_token).Restart the always-on serve (macOS:
launchctl unloadthenloadoncom.memex.serve; Linux:systemctl --user restart memex-serve; Windows:schtasks /End /TN MemexServethenschtasks /Run /TN MemexServe). Skipping this leaves the OLD token accepted (it is cached in memory) and the new file ignored.Run
memex tokento see the new value. Re-paste it into that machine's Chrome extension popup, and re-pair every device that dials this one:memex sync connect --url http://<this-device>:5777 --name <name> --token "..."(passing--tokenavoids the hidden prompt, which is easy to mistype).
Running always-on
memex serve (claude.ai capture) is a long-lived server, and the Claude Code
ingest backstop runs on a schedule. To have them start on login and stay up
(restarting if they crash), let memex setup install the service, or call it
directly on any OS:
memex install-service # install (launchd / systemd / Scheduled Task)
memex install-service status # show what is registered
memex install-service uninstall # remove itThis is cross-platform: launchd agents on macOS, a systemd user unit on Linux,
a Scheduled Task on Windows. By default it manages the live-capture server plus
the 15-minute Claude Code ingest backstop. Idle cost is low: neither loads the
embedding model until there is real work. It works the same from a PyPI / pipx /
uv tool install (a self-contained launchd / systemd / Scheduled Task that runs
the installed memex serve directly) and from a cloned repo. Use a persistent
install (pipx or uv tool), not transient uvx, so the service has a stable
interpreter to launch at boot.
To also run the claude.ai remote connector as a service, pass --remote
(macOS): memex install-service --remote. It only makes sense once the
MEMEX_REMOTE_* config is in .env and the Tailscale Funnel is up on the same
port (tailscale funnel --bg 8377), otherwise the agent crash-loops; that is
why it is opt-in.
cd /path/to/memex
for svc in serve ingest-claude-code; do
sed "s|__REPO__|$(pwd)|g" "scripts/com.memex.$svc.plist.template" \
> ~/Library/LaunchAgents/com.memex.$svc.plist
launchctl load ~/Library/LaunchAgents/com.memex.$svc.plist
done
launchctl list | grep memexTo stop a service: launchctl unload ~/Library/LaunchAgents/com.memex.<name>.plist.
Auto-summaries (Phase 3, optional)
When search_chats returns a chat that does not have a summary yet, Memex can generate one on-the-fly using Claude Haiku. The summary is persisted, so the next search of the same chat hits cache and does not pay the API again. This way you only pay for chats you actually look at, not for the whole corpus.
Opt-in. Off by default. Cap: at most 3 summaries generated per search_chats call (parallel), to bound latency and per-query cost.
Install the extra (adds the
anthropicSDK):uv sync --extra summariesIn your
.env(or as env vars), set:ANTHROPIC_API_KEY=sk-ant-... MEMEX_SUMMARY_ENABLED=trueUse
search_chatsfrom Claude Code as usual. The first time a chat appears in results without a cached summary, Memex generates one. Subsequent searches return the cached summary instantly.
Configurable via env: MEMEX_SUMMARY_MODEL (default claude-haiku-4-5-20251001), MEMEX_SUMMARY_MAX_TOKENS (default 200). If the API fails for a particular chat (no key, rate limit, network), that one result comes back without a summary, the search itself never aborts, and the warning is logged.
Cost model: bulk ingest of an export with 74 chats costs $0 (no summaries are generated at ingest time). Each unique chat you actually open in a search costs roughly $0.01 (Haiku, ~5-10k input + ~200 output tokens). $5 of API credits comfortably covers months of use.
Repo associations (Phase 3)
Memex can associate each chat with the local code repos it touches, and boost those chats when search_chats is invoked from inside a repo. So when you ask Claude Code something like "remember the auth refactor we discussed?", chats that touched the current repo rank higher than unrelated chats with the same keywords.
How it works:
Register a repo:
uv run memex repos add /path/to/your/repoMemex reads
.git/config(origin URL), andpyproject.toml/package.json/Cargo.toml(package name). The canonical key prefers the git remote (stable across clones) over the path.Run a one-time scan over chats you already ingested:
uv run memex repos scanEach chat gets matched against every registered repo. The matcher uses 4 signals (highest wins): remote URL literal in chat text (confidence 1.0), absolute path literal (0.9), manifest name word-bounded (0.8), display name word-bounded (0.5). Anything below 0.5 is dropped. New chats ingested after registering the repo are auto-scanned at ingest time.
From Claude Code, search with the repo argument:
search_chats(query="auth refactor", repo="d:/dionisio/memex")Or pass the git remote URL, or the canonical key from
memex repos list. Chats associated to the repo get their distance reduced by0.3 * confidence. Chats outside the repo still appear lower down (it is a boost, not a filter).
CLI helpers:
uv run memex repos list # show registered repos
uv run memex repos remove <key> # unregister + cascade-remove associations
uv run memex tag <chat-uuid> <repo-key> # manual override (sticky vs auto-scan)
uv run memex untag <chat-uuid> <repo-key> # remove an associationA manual tag survives subsequent auto-scans: once you tag a chat by hand, the matcher will not overwrite it.
Proactive context injection (SessionStart hook)
Claude Code supports hooks that run shell commands at session boundaries. Memex ships memex session-context, designed to be wired into the SessionStart hook so every new Claude Code session in a registered repo starts with a Markdown blob listing the most relevant past chats. No query needed.
To enable it, add to your .claude/settings.json (project-local) or ~/.claude/settings.json (user-global):
{
"hooks": {
"SessionStart": [{
"command": "uv run memex session-context"
}]
}
}The command auto-detects the active repo by walking up from cwd until it finds .git. If the repo is registered in Memex and has associated chats, it prints a short Markdown blob with the top N (default 5) chats, ordered by manual first, then auto by confidence. If anything fails (no .git, repo not registered, no associations), it prints nothing on stdout (only diagnostics on stderr), so the hook is a silent no-op in that case.
You can also run the command by hand to debug: uv run memex session-context [--repo <path>] [--limit N].
Live capture (Phase 2)
So that new Claude.ai chats land in Memex without asking for a manual export:
Start the local HTTP server in a terminal:
uv run memex serveListens on
127.0.0.1:5777by default. Keep it running while you browse claude.ai. On start it prints an access token; the extension must send it (the loopback Origin check alone does not authenticate other local processes). Reprint it any time withuv run memex token.Load the Chrome extension:
Soon: install from the Chrome Web Store (in review for the alpha).
For now (unpacked load):
Open
chrome://extensions/Enable Developer mode
Load unpacked → pick
chrome-extension/from the repoClick the Memex icon and confirm the "Server" chip says responding (green).
Pair the extension with the access token. Run
uv run memex token, copy the value, paste it into the extension popup's token field, and click Save token. This is a one-time step per machine (the token lives user-only next to your DB). Without it, ingest requests are rejected with401.Import your full history (one click). With a claude.ai tab open, click Backfill claude.ai history in the popup. It pages through your entire chat list and pulls every conversation into Memex, skipping the ones already indexed and unchanged (so re-running is cheap and a closed tab just resumes on the next click). Progress shows in the popup. This is what makes a fresh install searchable without a manual export.
Then just use claude.ai. Every new chat you open or create is ingested automatically. Verify with
memex statsor by callingsearch_chatsfrom Claude Code.
Details in chrome-extension/README.md.
Autostart (macOS + Windows + Linux)
So you do not have to run memex serve by hand every time you log in (this is also what memex setup does for you):
memex install-service # default action: install
memex install-service status # check current state
memex install-service uninstallThe CLI dispatches to the right installer for your OS:
macOS: writes launchd agents for
serve+ the 15-minute Claude Code ingest backstop, andlaunchctl loads them. Logs in the data dir (<repo>/data/serve.logfrom a clone,~/Library/Application Support/memex/com.memex.serve.logfrom a PyPI install). Add--remoteto also run the claude.ai connector (needs theMEMEX_REMOTE_*config). See Running always-on.Windows: registers a Scheduled Task (
MemexServe) that runsmemex serveat logon. No admin required, no console window, survives VS Code close. Logs at%LOCALAPPDATA%\memex\serve.log. Auto-restarts up to 3 times if it dies.Linux: writes a systemd user unit at
~/.config/systemd/user/memex-serve.service, enables it, and starts it now. Logs at~/.local/share/memex/serve.log. To keep it running across logout:loginctl enable-linger $USER. Status:systemctl --user status memex-serve.
From a pip/pipx install (no cloned repo), memex install-service works on macOS, Linux, and Windows alike: it generates a self-contained agent (launchd / systemd / a logon Scheduled Task) that runs the installed memex serve directly, with the database in your per-user data directory. Use pipx (not transient uvx) so the service has a stable interpreter to launch at boot.
Making Claude use Memex proactively
By default, LLMs are conservative with tools: they prefer to ask before invoking anything. If you say "remember we talked about X?", Claude tends to answer "I don't recall" instead of searching.
The docstrings of the 4 tools already include "USE PROACTIVELY" instructions, but you can reinforce it by adding this snippet to your CLAUDE.md (global at ~/.claude/CLAUDE.md for every session, or local at <project>/CLAUDE.md for a specific one):
## Memex: persistent memory of Claude.ai chats
There is an MCP server `memex` with 4 tools: `search_chats`, `get_chat`, `list_recent_chats`, `find_related`.
They index ALL of the user's Claude.ai history, reachable via hybrid search
(semantic + lexical FTS5).
**Operational rule:** before answering "I have no record", "I don't remember", "this is
the first time I hear about this", or anything equivalent, call `mcp__memex__search_chats`
with the relevant query. Claude Code's native memory starts clean every session; Memex
is the only path into the user's real history.
Typical triggers: "remember when...", "did I tell you about...", "we already talked about...",
"the other day we discussed...", or any reference to a project / person / decision that might
live in history.Roadmap
See ROADMAP.md for phases, close criteria, and current status (in Spanish, it is the internal journal).
Devlog
See DEVLOG.md for the log of decisions, blockers, and progress (in Spanish).
Inspiration and references
Official feature request: anthropics/claude-code#12858
Claude Historian, claude-conversation-extractor: MCP servers for Claude Code / Desktop history. Reference for tool structure.
claude-conversation-export: Claude.ai exporter using the same capture strategy. Useful as backfill.
Spin-off of the SyncChat project.
License
MIT.
Available Tools
6 toolsget_chatA
Fetch a specific conversation from history by uuid (with pagination).
USE when:
You have already identified a relevant chat (usually via
search_chats) and need more context than the result snippet.The user gave you a specific uuid and asked you to review it.
You are following a thread and need detail from a specific chat that appeared earlier in the conversation.
DO NOT use to discover new chats without searching first. To find
chats by topic or keyword, use search_chats.
If the chat is long, call again with messages_offset to paginate
(truncated response is indicated by truncated: true and
total_messages).
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | Chat UUID (typically obtained via `search_chats` or `list_recent_chats`). | |
| messages_limit | No | How many messages to fetch starting from the offset (default 10, max 100). Individual messages are truncated to 1500 chars so the total response fits in the MCP client's token cap (~17k chars worst case with the default). If you need more detail per message, ask for fewer messages (e.g. messages_limit=5) and you can request a higher messages_limit in chats with short messages. | |
| messages_offset | No | How many messages to skip from the start of the chat (default 0). Use this to paginate long chats: first call with offset=0, second with offset=10, etc. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully bears the burden. It discloses pagination behavior, token limits, message truncation to 1500 chars, and how to handle long chats. No destructive traits to disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 150 words) and well-structured with sections. The main purpose is front-loaded. Every sentence adds value; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and no annotations, the description covers all needed context: use cases, alternatives, pagination, token limits, message truncation. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds significant value by explaining pagination mechanics, token cap considerations, and practical usage advice like asking for fewer messages for more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a specific conversation from history by uuid (with pagination).' It specifies the verb, resource, and key detail. It distinguishes from siblings by indicating this tool is used after searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'USE when' and 'DO NOT use' sections, contrasts with search_chats, and gives specific scenarios. The guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
index_terminal_sessionsA
Index the user's local Claude Code / terminal sessions into Memex now.
Runs the same incremental scan as memex ingest-claude-code: reads
~/.claude/projects/**/*.jsonl and ingests new or changed sessions
(source claude_code) so they become searchable. Unchanged sessions are
skipped, so this is cheap. The CURRENT session is captured up to what
Claude Code has flushed to its transcript on disk.
USE when the user asks to index / capture / save their terminal or Claude
Code work into their memory ("indexá esta charla", "index my sessions",
"guardá esta conversación en memex"). To also send it to the user's other
devices, follow with sync_now.
Returns:
JSON with status and, on success, indexed (new sessions),
unchanged, messages, chunks, errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the incremental scan, file sources, skipping unchanged sessions, and that it captures up to what Claude Code has flushed. Also describes return value structure. Highly transparent for a read/index operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs, bullet points, and examples. Front-loaded with main action. Could be slightly trimmed, but overall efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given no parameters and existence of output schema. Covers behavior, file locations, performance characteristic (cheap), return structure, and follow-up action (sync_now). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. Description provides context but no parameter details needed. Schema coverage is 100% (empty schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it indexes local Claude Code/terminal sessions into Memex with specific verbs and resources. Mentions similar functionality to 'memex ingest-claude-code' but doesn't explicitly distinguish from sibling tools like search_chats or get_chat; however, the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use: 'when the user asks to index / capture / save their terminal or Claude Code work' with concrete examples including Spanish phrases. Also recommends following with sync_now for multi-device sync. Lacks explicit 'when not to use' but covers key usage clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_chatsA
Chronological browse of the user's most recent Claude.ai chats.
USE when:
The user asks about recent activity without a specific keyword ("what have I been up to", "which chats did I have this week", "catch up on what I have been thinking about").
You need general context on the topics the user has been working on before going deeper.
The user asks to explore without knowing exactly what to look for.
For targeted topic/keyword searches use search_chats. This tool is
for chronological scanning, not for searching.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 10, max 100). | |
| source | No | Optional filter by origin. Same values as in `search_chats`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It notes chronological order and recency, but does not disclose behavioral details like whether only metadata or full content is returned, pagination behavior, or rate limits. With an output schema present, return value details are covered, but behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is tightly written with no wasted words. Uses bullet points for usage guidance, making it scannable. Every sentence adds value: purpose, use cases, and sibling tool differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (0 required params, 2 optional, output schema exists), the description provides clear purpose, usage scenarios, and alternative tools. It fully covers what an agent needs to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema; it merely restates 'Optional filter by origin' which is already in the schema. No new semantic context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool action: 'Chronological browse of the user's most recent Claude.ai chats.' It uses a specific verb (browse) and resource (recent chats), and distinguishes from sibling `search_chats` by emphasizing chronological scanning vs. targeted search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE when' section lists concrete user intents (e.g., 'what have I been up to', 'catch up on what I have been thinking about'), and explicitly states when not to use: 'For targeted topic/keyword searches use search_chats.' This provides clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_chatsA
Access to the user's persistent memory: ALL their past Claude.ai chats.
This is the only tool available to access the user's real history. Your native memory starts empty in every Claude Code session; anything the user has discussed on claude.ai lives only here.
USE PROACTIVELY (without the user asking explicitly) when:
They mention prior conversations or decisions: "remember when...", "we talked about...", "the other day we discussed...", "in that chat...", "I mentioned earlier...", "as we said...".
They ask about a project, person, decision, or specific term that might be in their history but is not in your current context.
They request context that seems "lost" between sessions or make an implicit reference to continuity ("I kept working on X", "the approach we discussed").
You need background on the user to answer well (what they do, their projects, their technical preferences).
BEFORE saying things like "I have no record", "I do not remember", "this is the first time I hear about that", "this is not in my memory" or similar, invoke this tool and check the results. The likelihood the data is indexed is high.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Search strategy. 'hybrid' (default, recommended in most cases), 'semantic' (vectors only, for pure conceptual similarity), 'lexical' (FTS5 BM25 only, ideal for exact proper nouns or technical terms). | hybrid |
| repo | No | Optional. If you are running in a repo and want to prioritize chats related to it, pass the absolute path (e.g. "d:/dionisio/memex") or the git remote URL. Any form is accepted; Memex canonicalizes it. Chats associated with the repo get a ranking boost proportional to the match confidence; chats outside the repo still appear lower (not a filter). Requires registering the repo with `memex repos add`. | |
| limit | No | Number of results (default 5, max 50). | |
| query | Yes | Text to look up (natural language). The `hybrid` mode (default) combines semantic search with FTS5 lexical search, so it works well both for descriptive phrases and for unusual proper nouns (e.g. "Amarok"). | |
| source | No | Optional filter by chat origin. Valid values: 'conversations' (standalone claude.ai chats), 'design_chat' (chats inside a Claude.ai Project), 'memory' (curated memory), 'claude_code' (local Claude Code / terminal sessions). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains persistent memory, the empty native context, and that data is likely indexed. It doesn't cover rate limits or auth, but for a read search tool this is adequate. The description adds behavioral context beyond what annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points. It front-loads the core purpose, then provides specific usage scenarios. Every sentence earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema exists), the description is thorough. It covers when to use, behavioral details, and parameter context. No gaps remain; the agent has all necessary information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining when to use different modes (hybrid, semantic, lexical) and the purpose of the repo parameter (ranking boost, not a filter). This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Access to the user's persistent memory: ALL their past Claude.ai chats' and distinguishes it as 'the only tool available to access the user's real history.' This sets a specific verb+resource and differentiates from sibling tools like get_chat and list_recent_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists scenarios for proactive use (e.g., when user mentions prior conversations, asks about projects) and instructs to invoke the tool before saying things like 'I have no record.' It provides clear context for when to use this vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sync_nowA
Sync Memex with the user's other devices now (paired peers + shared folder).
Runs an immediate two-way reconcile with every paired device and, if a
shared sync folder is configured (the dual-boot mode), a file sync. It
propagates what is ALREADY indexed locally, so to include the CURRENT
terminal session, call index_terminal_sessions first.
USE when the user asks to sync / push / send their conversations to their
other devices now ("sincronizá con mis dispositivos", "sync now", "mandá
esto a la mac"). Requires sync to be enabled (memex setup --sync or
memex sync enable).
Returns:
JSON with status and, on success, peers (per-device pulled/pushed/
forks) and file_sync (folder pulled/forks), or a message explaining
why nothing ran (disabled, or no target configured).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details that the tool performs a two-way reconcile, propagates already indexed content, and returns JSON with status, peers, and file_sync. It also explains conditions that cause nothing to run (disabled or no target), which fully discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a lead sentence stating the main action, followed by details on execution, usage guidance, possible returns, and failure conditions. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (mentioned in description), the description covers all necessary aspects: what it does, when to use, prerequisites, return structure, and edge cases. It is fully complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (empty schema), so the baseline is 4. The description does not need to add parameter details; the schema coverage is 100% by virtue of no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool syncs Memex with other devices via two-way reconcile with paired peers and shared folder. It distinguishes itself from sibling tools like index_terminal_sessions, which is a prerequisite. The verb 'sync' and resource 'Memex with devices' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (user asks to sync/push/send) and provides prerequisites (sync must be enabled, call index_terminal_sessions for current session). It also explains when nothing runs, offering clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
v0.5.0- First observed
find_related - First observed
get_chat - First observed
index_terminal_sessions - First observed
list_recent_chats - First observed
search_chats - First observed
sync_now
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: keyword search, specific chat retrieval, chronological browsing, semantic similarity search, terminal session ingestion, and device synchronization. No overlap exists.
All tool names follow a consistent verb_noun snake_case pattern (e.g., search_chats, get_chat, list_recent_chats), making them predictable and easy to understand.
With 6 tools, the set is well-scoped for a memory management server. Each tool serves a distinct need without being excessive or insufficient.
The tool set covers search, retrieval, ingestion, and synchronization comprehensively. A minor gap is the lack of delete or edit operations for memory, but core workflows are well supported.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables semantic and keyword search over Claude Code conversation history stored locally, using hybrid search, local embeddings, and time-decay scoring.16MIT
- AlicenseNot gradedqualityDmaintenanceA local MCP server that indexes and searches your Claude Code conversation history with both keyword and semantic search, fully private and running locally.MIT
- AlicenseAqualityCmaintenanceA local MCP server that indexes and searches your past Claude sessions using SQLite FTS5. No cloud, runs entirely on your machine.3MIT
- AlicenseNot gradedqualityBmaintenanceCapture, index, and search your Claude Code conversation history. Provides an MCP server for Claude Code to query its own past conversations.31MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dioniipereyraa/memex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server