Persistent, self-evolving memory for Claude Code. Stop re-explaining your project every session.
For LLM/AI tool discovery, see llms.txt.
███╗ ███╗███████╗███╗ ███╗███████╗███╗ ███╗
████╗ ████║██╔════╝████╗ ████║██╔════╝████╗ ████║
██╔████╔██║█████╗ ██╔████╔██║█████╗ ██╔████╔██║
██║╚██╔╝██║██╔══╝ ██║╚██╔╝██║██╔══╝ ██║╚██╔╝██║
██║ ╚═╝ ██║███████╗██║ ╚═╝ ██║███████╗██║ ╚═╝ ██║
╚═╝ ╚═╝╚══════╝╚═╝ ╚═╝╚══════╝╚═╝ ╚═╝
persistent memory for Claude Codememem is a Claude Code plugin that gives Claude persistent memory across sessions. A background miner extracts durable lessons (decisions, conventions, bug fixes, preferences) from your completed sessions, stores them as markdown in an Obsidian vault, and automatically surfaces relevant ones as an Active Memory Slice working state. An explicit narrative assembly path still exists, but the default runtime context is slice-first.
It's local-first: no cloud services, no API keys required, no vendor lock-in. Everything lives in ~/obsidian-brain/memem/memories/ as human-readable markdown.
Layered memory becomes real end-to-end. Every memory now lives in one of four layers (L0/L1/L2/L3) at save time, not just at mining time. memory_save accepts an optional layer param (Claude can override) and auto-classifies otherwise. The slice engine pins L0 (project identity) on every prompt and gates L3 (rare archival) behind explicit search.
Slice as universal recall format. memory_search, memory_get, memory_timeline, memory_recall, and context_assemble all return slice-formatted output via a single render_slice_markdown dispatcher. context_assemble composes via active_memory_slice rather than rolling its own briefing.
A 16-module refactor closed the entire spawn-storm class of bugs that had previously taken down hosts. The miner now uses start_new_session=True + os.killpg for process-group cleanup on timeout, an inverted TransientError/PermanentError taxonomy with PermanentError as default, persisted attempt counters with DLQ at MAX_FAILURES, a SIGTERM-drained graceful shutdown, SQLite WAL state storage, a hand-rolled circuit breaker, structured JSON logs with RotatingFileHandler, and a 5-in-60s wrapper crash guard.
Related MCP server: acheron-mcp-server
Use memem if:
You use Claude Code daily and keep re-explaining your project to every new session
You want durable memory you can browse and edit as markdown
You like local-first tools with zero vendor lock-in
You already use Obsidian (memem plugs straight into your vault)
CLAUDE.md is a single hand-edited file per project. memem gives you:
Automatic extraction — no manual note-taking, the miner captures lessons from every completed session
Query-aware context — only the memories relevant to your current question get injected, not a static dump
Self-evolving — memories merge, update, and deprecate automatically as your project evolves
Cross-project — works across every Claude Code project you use, not scoped to one repo
Security scanning — every write is scanned for prompt injection and credential exfiltration
Browsable — Obsidian vault with graph view and backlinks for free
memem uses layered recall plus a slice-first runtime kernel inspired by claude-mem and mem0. Instead of treating memory as one big briefing, it first turns recall results into an explicit working state:
Session start / user prompt
┌─────────────────────────────┐
│ Candidate generation │
│ • memories / graph │
│ • playbooks │
│ • runtime environment │
│ • current artifacts │
└──────────┬──────────────────┘
│
▼
┌─────────────────────────────┐
│ Activation judgement │
│ • goals │
│ • constraints │
│ • decisions / failures │
│ • artifacts / tensions │
└─────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ Active Memory Slice │ → rendered markdown working state
│ generate_prompt_context() │ used by hooks, MCP, and CLI
└─────────────────────────────┘The lower-level recall tools still exist for explicit drilling:
memory_search(query) -> compact index
memory_get(ids=[...]) -> full content
memory_timeline(id) -> chronological thread
context_assemble(query, project) -> optional secondary narrative briefing
Memory layers (auto-classified at save AND mining time; Claude can override):
Layer | Purpose | Slice behavior |
L0 | Project identity — tech stack, repo structure, core conventions | Always pinned in every active slice for that project (anchor score 0.95) |
L1 | Generic conventions — testing, style, commit patterns | Ranked + scored alongside L2 |
L2 | Domain-specific — most memories (default) | Ranked + scored (default search hits) |
L3 | Rare/archival — niche failure modes, one-off lessons | Excluded from auto-recall; only via explicit |
A heuristic (mining.py:classify_layer) assigns layers based on importance, structural tags, content length, and the per-project L0 cap. memory_save(content, ..., layer=N) accepts an explicit override (0-3) when Claude judges better than the heuristic.
Token efficiency: session start injects L0 verbatim plus a compact index for L1-L2 (~50 tokens per entry: ID + L + title + snippet). Claude drills into specific memories via memory_get(ids=[...]) only when it needs full detail.
Active Memory Slice runtime kernel:
For ongoing work, active_memory_slice(query, scope_id, ...) is the default
runtime path. It uses memory_search/FTS/graph/playbooks/transcripts plus
runtime environment and current artifacts as candidate generation, then
activates a structured working state:
Memory Vault
→ Candidate Generation
→ Activation Judgement
→ Active Memory Slice
→ Delta Proposals
→ Memory VaultThe slice explicitly separates goals, constraints, background, decisions,
preferences, failure patterns, artifacts, open tensions, and candidate deltas.
If you pass session_id together with runtime context such as task_mode and
repo_path, memem also carries forward continuity across slices and records
slice history under ~/.memem/.
Default runtime behavior is still non-mutating. Delta proposals are validated
and surfaced in the slice, but safe writeback only runs when you opt in via
writeback_preview=True or auto_commit_safe=True.
Opt-in features:
MEMEM_SHOW_BANNER=1 — show a one-line status banner at session start (off by default)
MEMEM_PRETOOL_GATING=1 — enrich Read tool calls with memories about the target file (off by default)
MEMEM_TOPIC_SHIFT_THRESHOLD=0.3 — keyword overlap threshold for topic-shift re-firing (default 0.3)
Copy-paste:
claude plugin marketplace add TT-Wang/memem
claude plugin install memem@memem-marketplaceIf you already added the marketplace once, future installs only need the second command.
Then:
restart Claude Code if it was already open
open any project
send your first normal message
memem will show a welcome/status message and offer the mining options
That's it. On first run, bootstrap.sh self-heals everything:
Verifies Python ≥ 3.11 — or installs it via uv python install 3.11 if your system Python is too old
Installs uv if missing (via the official Astral installer)
Syncs deps into a plugin-local .venv (hash-cached against uv.lock)
Creates and canary-tests ~/.memem/ and ~/obsidian-brain/
Writes ~/.memem/.capabilities (used for degraded-mode decisions)
Execs the real MCP server
First run: ~5 seconds. Every run after: ~100ms. No separate pip install step.
Nothing mines until you opt in. memem is strictly opt-in as of v0.9.0 — install does not start the miner or touch your sessions. Type /memem to see status and choose what to do next. You can start mining two ways:
/memem-mine — mine new sessions only (from now on)
/memem-mine-history — mine everything, including past history (uses Haiku API credits)
Or just tell Claude "start mining new sessions" / "start mining everything including history" — it knows what to do.
choose /memem-mine if you only want memory from new sessions going forward
choose /memem-mine-history if you want memem to process your old Claude Code sessions too
If you are unsure, start with /memem-mine. It is the safer and cheaper default.
At session start, the SessionStart hook tries to prime a slice-first working state for the current project scope. On each user prompt, the UserPromptSubmit hook regenerates the slice for the current query. If you just installed memem and have no relevant context yet, the hooks stay quiet and Claude proceeds normally.
You work normally. The miner daemon runs silently in the background. When your session ends and settles for 5 minutes, the miner extracts memories from the transcript using Claude Haiku and writes them to your vault.
During the session: every user prompt goes through active_memory_slice, which builds a structured working-state briefing from the relevant memories, playbooks, transcripts, graph neighbors, environment facts, and current artifacts. The hooks automatically pass session id and working directory, and the prompt hook infers a task mode when the host does not provide one, so ongoing work can carry constraints, artifacts, and tensions forward across slices. You see an active slice prompt with goals, constraints, background, decisions, failure patterns, open tensions, and artifacts. Claude starts with the current working state instead of a generic briefing.
claude plugin marketplace add TT-Wang/memem
claude plugin install memem@memem-marketplaceThen in Claude Code:
/mememAnd choose one:
/memem-mineor
/memem-mine-historyIt saves durable knowledge, not session logs:
Architecture decisions with rationale ("we use RS256 JWTs because HS256 can't be verified by third parties without sharing the secret")
Conventions ("tests go in tests/ not spec/", "commit messages use imperative mood", "never import from internal/ outside its package")
Bug fixes you might forget ("bcrypt.compare is async — must await", "timezone math must use dayjs.utc() or DST shifts the result by an hour")
User preferences ("prefer single commits, not stacked PRs", "terse responses — no trailing summaries", "ask before running migrations in prod")
Known issues & workarounds ("JWT_SECRET defaults to 'secret' if unset — tracked in #123", "pnpm install hangs on corporate VPN, use --network-timeout=600000")
Environment & tooling facts ("project uses Poetry, not pip", "CI runs on Node 20 but local defaults to 22 — pin with nvm use", "Redis must be running on :6380 not :6379")
Project structure & invariants ("auth middleware requires Redis", "all DB writes go through repo/ layer, never raw SQL in handlers")
Failure patterns & post-mortems ("mocking the DB hid a broken migration last quarter — integration tests must hit a real DB", "don't ship on Fridays after the 2025-11 rollback incident")
Third-party quirks ("Stripe webhooks retry for 3 days — idempotency key is mandatory", "OpenAI streaming drops the final token if client closes early")
Domain knowledge ("a 'merchant' in our schema is what the legal team calls a 'counterparty'", "revenue is recognized at ship time, not order time")
It does NOT save:
Raw session transcripts (those are searchable via transcript_search, not stored as memories)
Trivial or obvious facts
Session outcomes ("today I worked on X")
Store | Path | Purpose |
Memories |
| Source of truth (human-readable markdown) |
Playbooks |
| Per-project curated briefings |
Search DB |
| SQLite FTS5 index (machine-fast lookup) |
Graph DB |
| Rebuildable typed/scored memory-edge index |
Telemetry |
| Access tracking (atomic writes) |
Event log |
| Append-only audit trail |
Capabilities |
| Degraded-mode flags written by bootstrap |
Bootstrap log |
| First-run diagnostics |
You can point memem elsewhere via MEMEM_DIR and MEMEM_OBSIDIAN_VAULT env vars.
All recall tools return slice-formatted markdown via a unified render_slice_markdown dispatcher (introduced in v1.1) so output structure is consistent across tools.
Tool | What it does |
| Store a lesson. Security-scanned for prompt injection and credential exfil before writing. |
| [L1] Compact index slice — IDs + layer + title + 1-line snippet. Use first to narrow candidates. |
| [L2] Full content slice for specific memory IDs. Use after |
| [L3] Chronological thread via |
| Legacy alias — search + full content in one slice. |
| List all memories with stats, grouped by project. |
| Bulk import from files, directories, or chat exports. |
| Search raw Claude Code session JSONL logs (not the mined memories). |
| Composite briefing: calls |
| Inspect typed/scored graph neighbors for one memory. |
| Report graph quality issues: orphans, dead links, hubs, stale edges. |
| Rebuild the graph side index from the Obsidian vault. |
| Build a structured runtime working state for current work, with optional continuity and controlled writeback. |
Use the CLI when you want raw slice JSON, continuity debugging, or explicit writeback preview:
python3 -m memem.server slice "continue auth rollout" --scope memem --session-id sess-42 --cwd "$PWD" --task-mode coding --json --no-llm
python3 -m memem.server slice "continue auth rollout" --scope memem --session-id sess-42 --cwd "$PWD" --task-mode coding --writeback-preview --json --no-llm
python3 -m memem.server slice "continue auth rollout" --scope memem --session-id sess-42 --cwd "$PWD" --task-mode coding --auto-commit-safe --json --no-llmSemantics:
default slice is read-side and non-mutating
--writeback-preview runs the delta pipeline in dry-run mode
--auto-commit-safe commits only deltas classified as auto-safe
/memem — welcome, status, help
/memem-status — memory count, projects, search DB size, miner health
/memem-doctor — preflight health check with fix instructions for any blocker
/memem-mine — start the miner daemon manually (normally auto-starts)
/memem-mine-history — opt-in: mine all your pre-install Claude Code sessions
claude CLI isn't on my PATH?memem enters degraded mode — it still works, just without Haiku-powered context assembly and smart recall. You get FTS-only keyword recall instead of query-tailored briefings. Every session shows [memem] N memories · miner OK · assembly degraded (claude CLI missing — FTS-only recall) at the top of the context, so you know why.
This is by design: missing optional dependencies should degrade, not fail.
Run /memem-doctor. It runs the same preflight the bootstrap shim runs (Python version, mcp importable, claude CLI on PATH, directory writability, uv available), then prints a report labelled HEALTHY, DEGRADED, or FAILING with explicit fix instructions for each blocker.
For deeper debugging:
tail -f ~/.memem/bootstrap.log # first-run shim log
tail -f ~/.memem/miner.log # miner daemon log
cat ~/.memem/events.jsonl # memory operation audit trail
python3 -m memem.server --status # detailed status dumpSession ends → miner daemon sees the JSONL file in ~/.claude/projects/
→ Waits 5 minutes for the file to "settle" (no more writes)
→ Filters to human messages + assistant prose (strips tool calls, system reminders)
→ One Haiku call with the full context: "extract durable lessons"
→ Haiku returns JSON array of memory candidates
→ Each candidate runs: security scan → dedup check → contradiction detection → save
→ Index rebuilt, per-project playbooks grown and refined
→ Session marked COMPLETE in ~/.memem/.mined_sessionsFirst message in a new session → auto-recall.sh hook fires
→ Reads ~/.memem/.capabilities for status banner
→ Builds an active memory slice from recall candidates + graph/playbook/transcript context
→ Emits a structured "Active Memory Slice" prompt block
→ If the slice engine is unavailable → falls back to compact recall
→ Either way, Claude starts its reply with active work-state context already loadedmemem is split into small, focused modules:
models.py — data types, path constants
security.py — prompt injection + credential exfil scanning
telemetry.py — access tracking, event log (atomic writes, fcntl-locked)
search_index.py — SQLite FTS5 index
graph_index.py — typed/scored related-memory graph side index
active_slice.py — MemoryItem + ActiveMemorySlice schemas, render_slice_markdown dispatcher
activation.py — heuristic + bounded LLM activation judgement
boundaries.py — scope/deprecated/budget/redundancy filters
delta.py — non-mutating candidate delta proposals
active_slice_engine.py — candidate generation, layer-aware (L0 anchors + L3 gating), build_slice public entry
obsidian_store.py — memory I/O, dedup scoring, contradiction detection, layer auto-classification on save
recall.py — slice-format recall tools (memory_search/memory_get/memory_timeline/memory_recall)
playbook.py — per-project playbook grow + refine
assembly.py — context_assemble composes via active_memory_slice
capabilities.py — runtime feature detection for degraded mode
storage.py — server-lifecycle helpers (PID management, miner auto-start)
server.py — thin MCP entrypoint (FastMCP imported lazily)
cli.py — command dispatcher for non-MCP entrypoints
mining.py — session mining pipeline (Haiku extraction)
miner_daemon.py — long-running daemon with structlog JSON output, semaphore concurrency cap, heartbeat
miner_protocol.py — exit codes (FATAL=75 / TRANSIENT=20) and status constants
miner_errors.py — TransientError / PermanentError taxonomy (PermanentError default)
miner_circuit_breaker.py — hand-rolled CB; opens after 5 consecutive PermanentErrors, 5min cooldown
session_state.py / session_state_db.py — SQLite WAL state for the miner (auto-migrates from JSONL on first run)
Multi-signal recall scoring:
50% FTS relevance
15% recency (0.995^hours decay)
15% access history (usage reinforcement)
20% importance (1-5 scale from Haiku)
Related-memory graph:
The Obsidian markdown files remain the source of truth. The related: [...]
frontmatter stays intentionally simple so memories are portable and readable.
memem also builds ~/.memem/graph.db, a local SQLite side index with typed,
scored edges such as same_topic, supports, depends_on, supersedes, and
contradicts. Recall uses this graph when available and falls back to the
Markdown related field if the graph has not been built yet.
Useful maintenance commands:
memem graph rebuild
memem graph audit
memem graph stats
memem graph neighbors <memory-id>Memory schema (markdown frontmatter):
---
id: uuid
schema_version: 1
title: "descriptive title"
project: project-name
tags: [mined, project-name]
related: [id1, id2, id3]
created: 2026-04-13
updated: 2026-04-13
source_type: mined | user | import
source_session: abc12345
importance: 1-5
status: active | deprecated
valid_to: # set when deprecated
contradicts: [id1] # flagged conflicts
---Env var | Default | Purpose |
|
| State directory (PID files, search DB, logs) |
|
| Vault location |
| (none) | Colon-separated extra session dirs to mine |
|
| Seconds to wait before mining a completed session |
|
| Bootstrap skips |
memem works without Obsidian — it just writes markdown. But Obsidian gives you graph view and backlinks for free:
Download: https://obsidian.md (free)
Open ~/obsidian-brain as a vault
Memories appear in memem/memories/, playbooks in memem/playbooks/
Use Graph View to see how memories link via the related field
Claude Code
Python ≥ 3.11
uv (auto-installed by bootstrap.sh on first run)
claude CLI on PATH (optional — required for Haiku-powered assembly; degraded mode works without it)
git clone https://github.com/TT-Wang/memem.git
cd memem
pip install -e ".[dev]"
pytest # 428 tests
ruff check . # lint
mypy memem # type checkSee CONTRIBUTING.md for the PR process and CHANGELOG.md for version history.
forge — Structured planning,
parallel execution, and deep validation for Claude Code. memem + forge
is the recommended pairing: forge plans and executes multi-file
changes, memem remembers what worked across runs. Forge's
memory_save patterns land in memem's recall index, so next week's
run starts with last week's lessons already loaded.
MIT
Assemble a query-tailored context briefing from all available knowledge.
This is the highest-value Cortex tool. It gathers the relevant subset of memories, the project's playbook, and related session transcripts, then uses Claude Haiku to synthesise a focused markdown briefing for the given query. The result is a ready-to-read summary, NOT a raw memory dump — usually 300-800 tokens of distilled relevant knowledge.
Behaviour:
Read-only with respect to the Cortex memory store. Bumps access
telemetry on memories it reads (same as memory_recall).
No authentication required by Cortex itself. The optional
Haiku synthesis step shells out to the local claude CLI,
which may use Claude Code credentials the user already has
signed in — Cortex does not handle those credentials directly.
Rate limits: depend on the claude CLI backend in the healthy
path. In degraded mode (claude CLI missing), there are no
rate limits at all — Cortex just returns raw materials.
Data access scope: reads ~/obsidian-brain/cortex/memories/,
~/obsidian-brain/cortex/playbooks/.md, ~/.cortex/search.db,
and ~/.claude/projects/ transcripts. If the claude CLI is
invoked, the gathered materials (up to 50KB) are sent to Haiku
via that subprocess — which in turn sends them to Anthropic's
API under the user's existing Claude Code session. In degraded
mode nothing leaves the machine.
Latency: 3-15 seconds with Haiku; <500ms in degraded mode.
Not idempotent at the Haiku level: the same query can produce slightly different briefings across calls due to Haiku sampling. The underlying memory retrieval step IS deterministic.
Failure modes: returns "" on genuinely empty vaults. Never raises to the caller; Haiku failures silently fall back to returning the raw materials.
Use context_assemble when:
Starting a new session and you want the assistant loaded with context
before the first real question (the auto-recall hook does this on
UserPromptSubmit, but you can also call it manually)
Onboarding to a project mid-session — ask "what do I know about X?"
Before making a decision in an area where prior decisions exist
Do NOT use for:
Simple keyword lookups (use memory_recall — faster, no LLM call)
Listing memories (use memory_list)
Finding a specific past conversation (use transcript_search)
Degraded mode: if the claude CLI is not available on the host,
this tool falls back to returning the raw materials (playbook +
ranked memories) without Haiku synthesis, so it always returns
SOMETHING useful.
Returns: A markdown briefing tailored to the query. Length is typically 300-800 tokens, with headers, bullet lists, and cross-references to memory IDs where relevant.
Example: context_assemble( query="help me fix the auth flow on staging", project="my-webapp", ) → returns a brief covering: the RS256 JWT decision, the known bcrypt.compare gotcha, a link to the staging-specific env var issue from last month, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The question or task you want context for. Typically this is the user's first message in a new session — the assembler will pull relevant memories and synthesise a focused briefing tailored to what they asked. | |
| project | No | Project scope for the assembly. "default" pulls from cross-project memories. A specific project name pulls that project's playbook + memories + session history. | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: read-only nature, telemetry bumps, authentication details, rate limits, data access scope, latency, idempotency, failure modes. This level of detail exceeds what annotations would typically 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 well-structured with sections, bullet points, and an example. It is front-loaded with a clear one-sentence summary. Every sentence adds essential information, matching the tool's complexity without unnecessary verbosity.
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?
The description covers all essential aspects: purpose, usage guidelines, behavioral details, parameters with example, return value specification, failure modes, and degraded mode. An output schema exists, but the description still provides necessary context on return format and typical content length.
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?
Input schema has 100% coverage with clear descriptions for both parameters. The description adds value by providing usage context, an example call, and clarifying the 'project' parameter's default behavior. However, the schema already does most of the work, so a 4 is appropriate.
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's purpose: 'Assemble a query-tailored context briefing from all available knowledge.' It distinguishes from sibling tools by explaining it gathers memories, playbook, and transcripts, then synthesizes with Haiku. The verb 'assemble' and resource 'context briefing' are specific and unique.
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 guidance on when to use (starting a session, onboarding, decision-making) and when not to use (simple keyword lookups → memory_recall, listing memories → memory_list, finding past conversation → transcript_search). Also mentions degraded mode behavior, ensuring the agent knows the tool always returns something useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk-import memories from a file, directory, or chat export.
Use this to seed Cortex with existing notes, CLAUDE.md content,
documentation excerpts, or chat logs you want to make searchable.
Each imported item runs through the same security scan and deduplication
as memory_save, so clean imports even from messy sources.
Behaviour:
MUTATION. Writes one or more memory markdown files, updates
FTS5 index, _index.md, and events.jsonl. Same atomic +
fcntl-locked write path as memory_save.
No authentication required.
No rate limits, but latency scales with source size — importing a 100-item directory can take several seconds.
Data access scope: reads the supplied source_path from the
local filesystem. Guarded against path traversal: the resolved
path must be inside $HOME; anything outside is rejected.
Nothing is sent over the network.
Not idempotent: re-importing the same source triggers the dedup check, which rejects duplicates with a summary count.
Failure modes: invalid or non-existent source paths return a string error. Individual rejected items are counted in the summary and do not abort the whole import.
Use memory_import for:
Initial bootstrap from an existing CLAUDE.md or notes folder
Absorbing a team-wide decision log into a project scope
One-off batch captures from a conversation export
Do NOT use for:
Incremental per-conversation saves (use memory_save for single items)
Mining Claude Code session logs (the background miner handles that automatically; no manual import needed)
Returns: A summary like "Imported 12 memories from 18 candidates (rejected 6 duplicates)". Errors are returned as human-readable messages.
Example: memory_import( source_path="/home/alice/notes/team-decisions.md", scope_id="my-webapp", )
| Name | Required | Description | Default |
|---|---|---|---|
| scope_id | No | Project scope to tag imported memories with. Defaults to "default" (cross-project). Use a specific project name to scope the import. | default |
| source_path | Yes | Absolute path to a file or directory containing content to import as memories. Supported formats: plain text files (.txt, .md) treated as single memories, directories recursively scanned, and structured exports (JSONL chat logs). Must be under $HOME for path-traversal safety. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly describes mutation, atomic writes, security (path traversal guards), failure modes, dedup, idempotency, and latency. No annotations provided, so full burden is carried.
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 sections, lists, and examples. Slightly verbose but each part justifies its length. Not overly terse.
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?
For a mutation tool with 2 parameters and an output schema (mentioned), description covers behavior, usage, failure modes, return format, and example. Very complete given context signals.
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 covers 100% of parameters with descriptions. Description adds context on source_path formats, scope_id default, and examples, going beyond 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 bulk import from file/directory/chat export. Distinguishes from sibling memory_save for single items and notes for incremental saves.
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 (initial bootstrap, absorbing decision logs, batch captures) and when not to use (incremental saves, session log mining). Names alternatives: memory_save and background miner.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every memory in a scope, with counts and source breakdown.
Use this when you want to see the full inventory of what Cortex has stored — e.g. to audit which projects have the most memories, to check if a specific memory you wrote earlier is still present, or to find a memory whose exact title you remember but whose keywords are ambiguous.
Behaviour:
Read-only. No mutations at all, not even telemetry bumps.
No authentication required.
No rate limits. Latency scales linearly with memory count; typical sub-second on corpora up to ~10k.
Data access scope: reads ~/obsidian-brain/cortex/memories/ markdown files via filesystem glob. Nothing leaves the machine.
Idempotent and deterministic for a given filesystem state.
Failure modes: returns "No memories in scope: " for an empty scope. Never raises.
Use memory_list when:
You want to see everything, not a ranked subset
You need to audit the current memory inventory
You're about to run a cleanup/purge operation and want a preflight
You suspect memory_recall is missing something and want to confirm
Do NOT use for:
Searching for specific content (use memory_recall — faster, ranked)
Assembling a context briefing (use context_assemble)
Returns: A markdown listing with the total memory count, source type breakdown (mined/user/import), and one line per memory showing its short ID, title, and project. Memories are sorted newest-first by creation date.
Example output: 47 memories Sources: mined:32, user:12, import:3
- [63d6570e] JWT algorithm — RS256 only in prod | project:my-webapp
- [a8b12c44] Pytest fixtures must use tmp_path | project:default
- ...
| Name | Required | Description | Default |
|---|---|---|---|
| scope_id | No | Project scope to list. "default" lists every memory across all projects. A specific project name lists only memories tagged with that project. | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides extensive behavioral details: read-only, no auth, no rate limits, linear latency, filesystem access scope, idempotency, failure modes. No annotations provided, so description carries full burden and exceeds it.
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 clear sections. Front-loaded with purpose and usage. Every sentence adds value. Appropriate length for the complexity.
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?
Covers all aspects: purpose, usage guidance, behavioral transparency, parameter semantics, output format with example. Complete for a simple tool with one optional parameter.
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% and description adds meaning: clarifies default scope lists all projects, specific project name filters. The extra context elevates beyond baseline.
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 the tool lists memories in a scope with counts and source breakdown. Differentiates from siblings like memory_recall and context_assemble. Describes specific use cases.
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 states when to use (audit, check existence, preflight for cleanup) and when not to (searching, context briefing) with alternative tool names. Provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Cortex memories for durable knowledge relevant to a query.
Use this when you need to recall prior decisions, conventions, bug fixes, user preferences, or lessons learned from past Claude Code sessions. It searches the full Obsidian-backed memory store via SQLite FTS5, ranks results with a multi-signal scorer (relevance + recency + usage + importance), and expands related-memory links.
Behaviour:
Read-only. Does not modify any memory, index, or sidecar file. Only side effect is a bump to the access-count telemetry sidecar (~/.cortex/telemetry.json), which influences future ranking.
No authentication required. Cortex is local-first; there are no credentials, tokens, or API keys.
No rate limits. Typical latency is under 100ms on corpora up to ~10k memories; pathological queries can take up to ~500ms.
Data access scope: reads from ~/obsidian-brain/cortex/memories/ and ~/.cortex/search.db. Nothing leaves the local machine.
Idempotent: calling twice with the same query returns the same results (modulo the access-count telemetry bump).
Failure modes: returns "No memories found for: " on empty result sets. Never raises to the caller; internal errors fall back to a slower file-scan path.
Use memory_recall when:
You need specific facts ("what auth library did we pick?")
You want to check if a topic has prior context before making a decision
You're debugging and want to find if this bug was fixed before
Do NOT use for:
Session-level what-I-did-today logs (use transcript_search instead)
On-demand query-tailored briefings (use context_assemble instead)
Listing every memory (use memory_list instead)
Returns: Markdown-formatted memory entries, grouped under a "### Memories" header. Each entry has the memory title and body excerpt. If no matches are found, returns "No memories found for: ".
Example: memory_recall(query="jwt auth algorithm", limit=5) → returns the top 5 memories mentioning JWT auth, such as a memory documenting the decision to use RS256 in production.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of top-ranked memories to return. Results are ranked by 50% FTS relevance + 15% recency + 15% access history + 20% importance. Linked memories may be expanded beyond this limit. | |
| query | Yes | Natural-language query describing what you want to find. Can be a question ("how did we handle auth?"), a topic ("jwt rotation"), or a fragment of a decision you vaguely remember. Keyword match is fuzzy (FTS5 + synonym expansion) so approximate terms work. | |
| scope_id | No | Project scope to search within. Defaults to "default" which searches across all projects. Pass a specific project name to narrow the search to that project's memories only. | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description thoroughly covers behavior: read-only, no auth, no rate limits, idempotence, data scope, failure modes, and the minor side effect of access-count telemetry. It fully discloses all behavioral traits an agent needs.
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 well-structured with clear sections and an example. It is fairly long but every sentence adds value. Minor redundancy could be trimmed, but overall it is efficient and front-loaded.
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 tool's moderate complexity (3 parameters, output schema implied), the description covers purpose, usage, behavior, return value, failure mode, and an example. No gaps remain for an agent to infer.
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%, but the description adds significant value: explains the ranking formula for 'limit', fuzzy matching and synonym expansion for 'query', and project narrowing for 'scope_id'. This goes well beyond the schema 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 the tool searches Cortex memories for relevant knowledge, with a specific verb 'Search' and a precise resource 'Cortex memories'. It differentiates from siblings by listing concrete use cases and explicitly naming alternative tools for different scenarios.
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 includes explicit guidance on when to use (specific facts, prior context, debugging) and when not to use, with clear references to sibling tools 'transcript_search', 'context_assemble', and 'memory_list'. This helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a durable lesson, decision, or convention to persistent memory.
Use this to capture knowledge that should survive across Claude Code sessions: user preferences, architecture decisions with rationale, environment quirks, non-obvious bug fixes, or anything you'd otherwise have to re-explain in the next session.
Behaviour:
MUTATION. Writes a new markdown file under
/obsidian-brain/cortex/memories/, appends to the FTS5 index
(/.cortex/search.db), updates ~/obsidian-brain/cortex/_index.md,
and writes an append-only entry to ~/.cortex/events.jsonl.
Writes are atomic (tmp + fsync + os.replace) and fcntl-locked.
No authentication required. Local-first; no credentials.
No rate limits. Typical latency 50-200ms including the security scan, dedup check, and write sync.
Data access scope: writes stay entirely on the local filesystem. Nothing is sent over the network.
Not idempotent: calling twice with identical content triggers the dedup check and the second call returns a "Memory already exists" error instead of a duplicate write.
Failure modes: rejected inputs return a string error ("Memory already exists", "Memory rejected: "); they never raise to the caller.
Every save goes through:
Prompt-injection + credential-exfil security scan (rejects matches)
Fuzzy deduplication against existing memories (word+bigram+trigram overlap — rejects near-duplicates with clear reason)
Automatic related-memory linking (adds related frontmatter field)
Write to Obsidian markdown file + FTS5 index + _index.md
Use memory_save for:
"We decided to use X because Y" (decision + rationale)
"User prefers small focused PRs, not big bundled ones" (preference)
"Database connection pool must be at least 20 for prod" (invariant)
"bcrypt.compare is async — always await" (gotcha)
Do NOT use for:
"Today I worked on X" (session logs — use transcript_search to find those)
Trivial facts easily re-discovered from reading code
Speculative or unverified claims
Duplicates of existing memories (the dedup check will reject them anyway)
Returns: A confirmation like "Memory saved: 63d6570e... 'JWT auth uses RS256'" on success, or an error message (starting with "Memory already exists" or "Memory rejected") on failure.
Example: memory_save( content="Use RS256 (not HS256) for JWT in production. HS256 " "requires sharing the signing secret across services " "which leaked via an env var export last quarter (#1247).", title="JWT algorithm — RS256 only in prod", tags="auth,jwt,security,postmortem", scope_id="my-webapp", )
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Comma-separated tag list (e.g. "auth,jwt,security"). Tags are used for filtering in `memory_list` and contribute to recall scoring. Keep them lowercase and topical. | |
| title | No | Short descriptive title, <120 characters. If empty, the first 60 chars of content are used. A good title is a declarative summary ("Use RS256 JWTs in prod"), not a question. | |
| content | Yes | The full memory body, written as natural-language prose. Should be atomic (one idea per save): capture ONE decision, convention, lesson, or preference with enough context to be useful in a future session. Include the rationale, not just the outcome. Max ~2000 characters recommended. | |
| scope_id | No | Project scope for the memory. "default" for cross-project global memories (user preferences, general lessons). A specific project name for project-scoped memories (e.g. "cortex-plugin", "my-webapp"). | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses mutation behavior, security scan, dedup process, error handling, local-only data flow, atomic writes, and typical latency. It covers all important behavioral traits an agent needs to anticipate outcomes.
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 fairly long but well-structured with sections (Behaviour, Use for, Do NOT use for, Returns, Example). Every sentence adds value, though a few details could be tighter. Front-loaded with purpose, which is good for scanning.
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 tool's complexity (4 parameters, multiple behavioral aspects, return values), the description covers everything an agent needs: input constraints, processing steps, output format, error messages, and a complete example. No gaps remain.
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%, but description adds meaning beyond the schema: explains tags are used for filtering and recall scoring, suggests title format and character limits, describes content as atomic prose with rationale, and clarifies scope_id semantics. This exceeds the baseline of 3.
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 begins with a clear verb+resource pair: 'Save a durable lesson, decision, or convention to persistent memory.' It distinguishes from siblings like 'transcript_search' and provides concrete examples, leaving no ambiguity about the tool's purpose.
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 (decisions, preferences, invariants, gotchas) and when NOT to use (session logs, trivial facts, speculative claims, duplicates). It also names an alternative (transcript_search) and explains what happens with duplicates, giving the agent clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search raw Claude Code session transcripts for past conversation excerpts.
This is the DIFFERENT from memory_recall — it searches the raw session
JSONL files under ~/.claude/projects/, not the mined memory corpus.
Use it when you need to find the actual back-and-forth of a prior
conversation, not the distilled lesson from it.
Behaviour:
Read-only. Does not modify transcripts, memories, or any index.
No authentication required.
No rate limits. Latency scales with transcript corpus size; typical 100-500ms across a year of daily sessions.
Data access scope: reads ~/.claude/projects/**/*.jsonl via
direct filesystem access. Does NOT read ~/obsidian-brain/
(that's what memory_recall and memory_list are for).
Nothing is sent over the network.
Idempotent and deterministic for a given filesystem state.
Failure modes: returns "No matching sessions" on empty result sets. Sessions older than Claude Code's 30-day retention window are not searchable (they've been deleted).
Use transcript_search when:
You want to recall "what did I actually say three weeks ago about X"
A mined memory references a session and you want the full context
You want to find all sessions that touched a specific file or topic
You're verifying a memory's source_session or debugging extraction
Do NOT use for:
Looking up durable knowledge (use memory_recall — mined, ranked, faster)
Listing memories (use memory_list)
Query-tailored context briefings (use context_assemble)
Returns: Markdown-formatted session excerpts with the session id, date, and matched text, or "No matching sessions" if nothing matches. Transcripts older than Claude Code's 30-day retention are not searchable.
Example: transcript_search(query="redis connection pool size", limit=3)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of session excerpts to return. Each excerpt is a short quote with the session id and date. | |
| query | Yes | Search phrase or keyword list. Matches against the raw Claude Code session JSONL transcripts (not the mined memory corpus). Use this for session-level context recovery, not durable knowledge lookup. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: read-only, no auth required, no rate limits, data access scope (reads ~/.claude/projects/**), idempotent, failure modes, retention window. Highly transparent.
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 clear sections, but somewhat lengthy. Could be slightly more concise without losing clarity, but overall effective.
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 tool's complexity and lack of annotations, description covers all necessary aspects: purpose, usage, behavior, parameters, return format, and failure modes. Output schema exists but description still adequately describes return format.
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 useful context beyond schema: explains that query matches against raw session files, and limit controls number of excerpts returned. Provides example usage.
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 searches raw Claude Code session transcripts for conversation excerpts. Distinguishes from sibling tool memory_recall by specifying it searches raw JSONL files, not the mined memory corpus.
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 (e.g., recalling past conversations, verifying memory sources) and when not to use (e.g., durable knowledge lookup, listing memories), with specific alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2context_assemble4 fields changedInput schema / properties / project / descriptionAdded value: +"Project scope for the assembly. \"default\" pulls from cross-project memories. A specific project name pulls that project's playbook + memories + session history."Input schema / properties / query / descriptionAdded value: +"The question or task you want context for. Typically this is the user's first message in a new session — the assembler will pull relevant memories and synthesise a focused briefing tailored to what they asked."Input schema / properties / query / maxLengthAdded value: +2000Input schema / properties / query / minLengthAdded value: +1memory_import3 fields changedInput schema / properties / scope_id / descriptionAdded value: +"Project scope to tag imported memories with. Defaults to \"default\" (cross-project). Use a specific project name to scope the import."Input schema / properties / source_path / descriptionAdded value: +"Absolute path to a file or directory containing content to import as memories. Supported formats: plain text files (.txt, .md) treated as single memories, directories recursively scanned, and structured exports (JSONL chat logs). Must be under $HOME for path-traversal safety."Input schema / properties / source_path / minLengthAdded value: +1memory_list1 field changedInput schema / properties / scope_id / descriptionAdded value: +"Project scope to list. \"default\" lists every memory across all projects. A specific project name lists only memories tagged with that project."memory_recall7 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of top-ranked memories to return. Results are ranked by 50% FTS relevance + 15% recency + 15% access history + 20% importance. Linked memories may be expanded beyond this limit."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionAdded value: +"Natural-language query describing what you want to find. Can be a question (\"how did we handle auth?\"), a topic (\"jwt rotation\"), or a fragment of a decision you vaguely remember. Keyword match is fuzzy (FTS5 + synonym expansion) so approximate terms work."Input schema / properties / query / maxLengthAdded value: +500Input schema / properties / query / minLengthAdded value: +1Input schema / properties / scope_id / descriptionAdded value: +"Project scope to search within. Defaults to \"default\" which searches across all projects. Pass a specific project name to narrow the search to that project's memories only."memory_save7 fields changedInput schema / properties / content / descriptionAdded value: +"The full memory body, written as natural-language prose. Should be atomic (one idea per save): capture ONE decision, convention, lesson, or preference with enough context to be useful in a future session. Include the rationale, not just the outcome. Max ~2000 characters recommended."Input schema / properties / content / maxLengthAdded value: +5000Input schema / properties / content / minLengthAdded value: +10Input schema / properties / scope_id / descriptionAdded value: +"Project scope for the memory. \"default\" for cross-project global memories (user preferences, general lessons). A specific project name for project-scoped memories (e.g. \"cortex-plugin\", \"my-webapp\")."Input schema / properties / tags / descriptionAdded value: +"Comma-separated tag list (e.g. \"auth,jwt,security\"). Tags are used for filtering in `memory_list` and contribute to recall scoring. Keep them lowercase and topical."Input schema / properties / title / descriptionAdded value: +"Short descriptive title, <120 characters. If empty, the first 60 chars of content are used. A good title is a declarative summary (\"Use RS256 JWTs in prod\"), not a question."Input schema / properties / title / maxLengthAdded value: +120transcript_search6 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of session excerpts to return. Each excerpt is a short quote with the session id and date."Input schema / properties / limit / maximumAdded value: +20Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionAdded value: +"Search phrase or keyword list. Matches against the raw Claude Code session JSONL transcripts (not the mined memory corpus). Use this for session-level context recovery, not durable knowledge lookup."Input schema / properties / query / maxLengthAdded value: +500Input schema / properties / query / minLengthAdded value: +1v0.1.0context_assemblememory_importmemory_listmemory_recallmemory_savetranscript_searchScored across 6 tools
Each tool has a distinct purpose: context_assemble synthesizes briefings, memory_import bulk-imports, memory_list lists, memory_recall searches, memory_save saves, and transcript_search searches transcripts. They are clearly differentiated with no overlap.
All tool names follow a consistent pattern: [domain]_[action] using snake_case (e.g., memory_save, memory_recall, context_assemble). The naming is predictable and uniform.
With 6 tools, the server covers core functionalities (save, search, list, import, context assembly, transcript search) without being excessive or minimal. The scope is well-balanced.
The tool set covers creation, search, listing, and import, but lacks explicit update or delete operations for memories. While this may be intentional, it's a minor gap that could cause agent limitations.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Portable AI memory you own. Keep memories and notes across Claude, ChatGPT, and other AI tools.
Give your AI agent persistent, governed memory for every project. At task start it recalls the approved decisions, conventions, risks and architecture (semantic search, ranked by importance); at close it proposes what was learned as typed memories that you review and approve — governance, not a notes dump. Agents propose, humans govern: edits go back to pending and deletion is human-only by design. Connect Claude Code, Cursor, Claude Desktop or any MCP client in two minutes with just your API key — hosted (nothing to install) or locally via `uvx solucortex-mcp`. Built by SoluAI and dogfooded daily: SoluCortex is developed using its own living memory.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
