Read who Mnemosyne OS is and the rules you must honor when using it: its governance tenet, the vault protection model (NORMAL/MAXIMUM, mixableWith, isolated sandbox vaults), the spine model, and the do/don't behavior for an agent operating on a human's memory. The same briefing is delivered as the server instructions on connect — call this to re-read it, or if your client did not surface those instructions.

Raw chronicle search in a Mnemosyne OS vault. Returns the matching chronicles themselves (architecture notes, code, decisions, sessions, git history) for YOU to read, rank and cite — nothing is rewritten, so this is what to use when you need the source text verbatim, e.g. to quote it or to write documentation from it. Ranked by vector similarity fused with a local BM25 channel, weighted by spineType. ⚠️ If your goal is to FIND something rather than to quote it, prefer mnemosyne_ask even when you only want its sources: measured on 2026-08-31, ask surfaces notes on rare literal terms (proper nouns, identifiers, product names) that this tool misses, because it retrieves deeper and re-ranks. ⛔ And never read the score as confidence: a miss and a hit come back with indistinguishable scores, so judge the returned text, never the number beside it.

Ask Mnemosyne a question and get a SYNTHESIZED prose answer grounded in the vault, PLUS the chronicles it drew on. It runs the full local RAG pipeline — deeper retrieval, lexical fusion and a re-rank — so it is both the reasoning tool AND, measured on 2026-08-31, the better RETRIEVER: reach for it whenever you need to find something, and read the Sources list even if you ignore the prose. Best on "why / who / how" questions spanning many memories ("why was SQLite chosen over Postgres?", "who is and what do they own?"). Slower than mnemosyne_query (up to ~30s). ⚠️ The prose is a model rewording of the sources: never quote it as the words the memory holds — quote the sources, or fetch them with mnemosyne_query. Always check the sources before trusting the answer.

List the memory vaults this Mnemosyne OS exposes — each with its TOKEN, display name and chronicle count. Call this first when you are unsure which vault to query/ask/ingest against, or when the user refers to a memory store by a name you have not seen. Pass a returned token (bold, e.g. MNEMOSYNE_OS) as the vault argument to the other tools — NOT the id line, which is the host's internal path. Note: you can only read/write the vaults this MCP was configured for (MNEMO_VAULTS); others are flagged here and are refused until added.

Persist a memory into the Mnemosyne OS vault — a decision, an architecture note, a debug finding, or a session summary. Stored permanently and indexed for future semantic retrieval by any agent. Use this at the END of a meaningful work session, or whenever you reach a decision that future you (or other agents) would want to recall.

List active Resonances — cognitive workspaces tracking ongoing projects. Each resonance has a name, status (active/paused), last position (phase), and last activity timestamp. Use this to understand what projects are currently active and where each one stands.

Get the current position of a specific Resonance — the last known phase and description saved by an agent or the cockpit. Use this at the start of a session to know exactly where work left off.

Update the current position of a Resonance. Call this at the end of a session to record where you left off — phase, current state, next steps. This is persisted as a DECISION chronicle in the vault.

Get recent git commits from the Mnemosyne OS monorepo. Use this to understand what changed recently, which phase is active, and what features were shipped.

List the connections Mnemosyne's Dream State engine discovered between memories during its offline (idle-time) scans — "what did you dream about?". Each bridge links two chronicles (possibly across vaults) with a composite Dream Bridge Score (dbs, prime-aware) and a raw cosine similarity, plus a short excerpt of both sides. Use it to surface non-obvious associations the memory found on its own, to audit whether dreamed connections are insightful or noise, or to seed creative exploration. An empty list is normal — it means the dream engine has not produced bridges yet (it runs while the machine is idle, if enabled in Settings).

Inspect how Mnemosyne classified its memories: chronicle → spine assignments for a vault (newest first), whole-vault per-spine counts, and optionally the global spine taxonomy tree. Use it to audit auto-classification quality ("did memories land in the RIGHT spines?"), to see a vault's composition at a glance, or to discover the taxon ids to pass as spine_type_filter in mnemosyne_query.

What OTHER coding-agent sessions exist on this machine, read from the transcripts their harnesses already write to disk. Returns metadata only — conversation name, project, git branch, model, last tool, how many files were touched, and when a line was last written. Reads EVERY coding-agent harness installed on this machine, not just your own, so you can see a session from a different agent working in your repository. Use it before you touch shared state. NEVER reports that an agent is "working": a crashed agent and an idle one fall equally silent, so it reports when a line was last SEEN and you conclude. Works with Mnemosyne OS closed.

Are two agent sessions live in the SAME git working tree and branch right now, from ANY installed harness? This is the one to call before git add -A, before a commit, and before a rebase: the git index is shared by every process in one working tree, so a commit from one session picks up whatever the other has staged. Answers from transcript files on disk; needs neither Mnemosyne OS nor a token. Each recorded directory is resolved to its working tree first, because one cd into a subfolder would otherwise make two sessions in one repository look like two projects. A clean answer says only that nothing was found IN WHAT IS READABLE — an agent whose transcripts live elsewhere does not appear at all, and sessions whose harness records no directory are listed separately as unplaceable rather than guessed at.

Which FILES other agent sessions have written or edited recently, newest first, with the session each came from. Paths and timestamps only — never file contents. Each entry says how it is known: recorded means the harness logged a file-writing tool call, from a command means a redirection was read out of a shell command the session ran and may never have completed. Spans every installed harness, and each line names the session and the agent it came from. Use it to see what another session has already touched before you edit the same area.

Your own status card on the human's canvas (the cockpit). Call it when you START a task ("working" + a short title and status), when you NEED the human ("waiting" — the card pulses and the taskbar flashes), when you are stuck ("blocked"), and when you are DONE ("done"). The state is what you declare; the host prints it next to the time since your last call, so keep calling at real milestones or the card goes quiet. The answer carries any message the human left on your card — read it and act on it. Needs the app window open. Nothing is stored in memory; this is a card, not a note.

Put a subreddit, a Hacker News search query or a topic on the human's Pheme radar (their reputation cartridge, which finds fresh threads worth a genuine reply), or take one off. The lists are THEIRS: an op that would empty a list is refused, every op reports its own outcome (done / already there / not there / refused), and the human sees a receipt in Pheme naming this agent and what changed. Use it when a conversation has found a community worth watching ("we answered a thread in r/hermesagent, keep an eye on it"). It does not scan and it does not post — nothing here posts anywhere; the human posts. Needs the app running (Pheme's settings mirror lives in it); Pheme itself may be closed.

Read what the human's Pheme radar last found: fresh threads in the subreddits and Hacker News queries they watch, each with a topic score and, when the human has run the Mnemosyne pass, a tier (high / mid / low = how much substance THEY can bring to that thread). The answer leads with WHEN the scan ran — it is as fresh as the last time the human opened Pheme and pressed Scan, never fresher. Use it to find threads to draft a reply for; the human posts the reply. "No radar" means no scan has been projected yet, not that nothing was found: ask the human to open Pheme and scan. Needs the app running; Pheme itself may be closed.

Put tasks into the human's To-do backlog (the To-do widget on their canvas) — in order, optionally under named steps. Use it when a conversation has settled WHAT to do: "make tasks out of everything we said we would do". Name the list ("list") — call once without it to be told the lists that exist on a LIST_NOT_FOUND answer — or pass create_list: true to make a new one. Never assume a default list. The host routes the write through the widget's own store, so what you file is exactly what the human sees. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. To read the backlog back or change what is in it, see mnemosyne_todo_list, mnemosyne_todo_update and mnemosyne_todo_lists.

Read the human's To-do backlog back: the lists that exist and the tasks in them, each with the ID you must use to change it. Call this BEFORE mnemosyne_todo_update - that tool names tasks by id and never by text, because "delete the task about the invoice" is how the wrong task goes, in a sentence that reads perfectly either way. Also the way to answer "what is on my plate" or to check whether something is already filed before adding a duplicate. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. Scope todo:read.

CHANGE the human's To-do backlog: edit a task, tick it off, move it to another list, or take it out. Every operation names a task by the id from mnemosyne_todo_list - call that first. Removing a task ARCHIVES it by default (it leaves the list and can be restored); pass permanent: true only when the human asked for it to be deleted outright. The whole batch is applied in order as ONE save, and each operation reports its own outcome, so a stale id does not sink the ones around it. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. Scope todo:write.

Manage the LISTS of the human's To-do backlog: create one, rename or recolour one, remove an empty one. Separate from mnemosyne_todo_update because these change the shape of someone's workspace rather than the work in it. Two refusals worth knowing before you call: a list that still HOLDS tasks is never removed (you are told how many are in the way - move them first, the host will not pick a destination on someone's behalf), and the three original lists can be renamed but never removed, because their contents are what make the file readable at all. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. Scope todo:write.

Read the human's calendar back: the appointments in a time window, each with the ID you must use to change or remove it. Call this BEFORE mnemosyne_agenda_update or mnemosyne_agenda_remove - both name appointments by id and never by title or date, because the calendar has no archive and a removal cannot be undone. A repeating event appears ONCE, with its cadence and the date of its next occurrence. Times in the answer are the human's machine local time. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. Scope agenda:read.

CHANGE an appointment already in the human's calendar: move it, rename it, add or drop a reminder, start or stop it repeating. Names appointments by the id from mnemosyne_agenda_list - call that first. A field you leave out is left alone; passing null CLEARS it. A start or end time that cannot be read REFUSES the change rather than leaving the old one silently in place, and a cadence that is not one of daily/weekly/monthly/yearly is refused rather than quietly turned into a one-off. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. Scope agenda:write.

REMOVE appointments from the human's calendar. Read them with mnemosyne_agenda_list first and pass the ids: this tool never matches by title or by date, because "remove my meetings on Thursday" is how an agent removes the wrong Thursday. THERE IS NO ARCHIVE - unlike a To-do task, a removed appointment is gone, so the answer names each one it removed by title and start time, for the human to check. A repeating appointment is removed as the whole SERIES; the calendar has no way to cancel a single occurrence. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. Scope agenda:write.

Put appointments or deadlines into the human's calendar (the Agenda widget on their canvas). Use it when a conversation names a specific date/time to remember — "add this to my calendar", a deadline, a meeting. The host routes the write through the widget's own store, so what you file is exactly what the human sees. Works with the app closed on a dev install (the headless daemon reads the file); an npm install has no daemon and needs the app running. To read the calendar back, change or remove an appointment, see mnemosyne_agenda_list, mnemosyne_agenda_update and mnemosyne_agenda_remove.