Re-read the server instructions: the governance tenet, the vault protection model (NORMAL and MAXIMUM, mixableWith, isolated sandbox vaults), the spine model, and the rules for an agent working on someone else's memory. Most clients show this text on connect. Call it if yours did not, or to read it again.

Search a vault and get the matching memories back word for word: notes, code, decisions, session summaries, commit history. Nothing is rewritten, so use this when you need the source text itself, to quote it or to write documentation from it. Ranking is vector similarity fused with a local BM25 channel, weighted by spine type. To FIND something rather than quote it, prefer mnemosyne_memory_ask, even when you only want its sources. It retrieves deeper and re-ranks, so it catches rare literal terms this tool misses: proper nouns, identifiers, product names. The score is not a confidence value. A hit and a miss come back with similar numbers, so judge the text, not the number beside it.

Ask a question and get a prose answer grounded in the vault, plus the memories it drew on. It runs the full local RAG pipeline: deeper retrieval, lexical fusion and a re-rank. That also makes it the better retriever, so reach for it whenever you need to find something, and read the Sources list even if you ignore the prose. It is at its best on why, who and how questions that span many memories. It takes up to about 30 seconds. The prose is a model rewording of the sources, so quote the sources instead, or fetch them with mnemosyne_memory_query. Check them before you trust the answer.

List the memory vaults this Mnemosyne OS exposes, each with its token, display name and memory count. Call it first when you are unsure which vault to work against, or when the user names a store you have not seen. Pass the bold token as the vault argument of the other tools. The id line is a local path and the other tools do not take it. Vaults this server was not configured for are flagged here and refused until the user adds them.

Write a memory into a vault: a decision, an architecture note, a debug finding, a session summary. It is stored permanently and indexed for every future agent to retrieve. Use it at the end of a meaningful work session, or whenever a decision is reached that someone will want to recall later.

List the resonances recorded in the default vault. A resonance is a workspace that tracks one ongoing project. Each entry carries its id, its last phase, how many minutes ago it moved, and the id of the memory behind it. Read-only. There is no status filter, so you get every resonance the scan matched in one vault, from at most 30 candidates. An empty result is written in words and means no resonance has been recorded yet. Read one in full with mnemosyne_position_get, or write a new one with mnemosyne_position_update.

Read where one resonance was left: the phase, and the free-text note an agent or the cockpit wrote when it stopped. Read-only. It returns the resonance id, when it was saved, the spine type of the memory, and the whole note. An id nothing was ever saved under answers in plain words and points at mnemosyne_position_update, so a blank history and a failed call do not look alike. Call mnemosyne_resonance_list when you do not know the id.

Record where you left off on a resonance: phase, current state, next steps. Call it at the end of a session. It is stored as a DECISION memory in the vault.

Read recent commits from the git repository this Mnemosyne OS is configured to read. Read-only. Each commit carries an 8-character hash, the subject line, the author and the date, newest first. The path is set on the app side, so this cannot be pointed at another checkout, and it needs the monorepo:read scope. When either is missing the answer names what is missing, rather than returning an empty list that would read as "no commits". Use mnemosyne_memory_query for the reasoning behind a change.

List the connections the Dream State engine found between memories while the machine was idle. Each bridge links two memories, sometimes from different vaults, with a Dream Bridge Score, a raw cosine similarity, and a short excerpt of both sides. Use it to surface associations the memory made on its own, to audit whether they are insightful or noise, or to seed creative exploration. An empty list is normal and means the engine has not produced bridges yet. It runs on idle time, when the user enables it in Settings.

See how Mnemosyne classified its memories. It returns the memory-to-spine assignments for one vault, newest first, and the per-spine counts for the whole vault. Use it to check whether memories landed in the right spines, to read a vault's composition at a glance, or to find the taxon ids to pass as spine_type_filter in mnemosyne_memory_query. Set include_taxonomy to also get the global spine tree.

List the other coding-agent sessions on this machine, read from the transcript files their harnesses already write to disk. Metadata only: conversation name, project, git branch, model, last tool, how many files were touched, and when a line was last written. It reads every harness installed here, 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. It reports when a line was last seen and you draw the conclusion: a crashed session and an idle one fall equally silent, so nothing here can tell you an agent is working. Works with the Mnemosyne OS app closed.

Check whether two agent sessions are live in the same git working tree and branch right now, across every installed harness. Call it before git add -A, before a commit, and before a rebase: one working tree shares one git index, so a commit from one session picks up whatever the other has staged. It answers from transcript files on disk and needs neither Mnemosyne OS nor a token. Each recorded directory is resolved to its working tree first, because one cd into a subfolder would make two sessions in one repository look like two projects. A clean answer covers what is readable: a session whose transcripts live elsewhere does not appear at all, and sessions whose harness records no directory are listed separately as unplaceable.

List the files other agent sessions wrote or edited recently, newest first, with the session each one came from. Paths and timestamps only. 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, which may never have completed. It spans every installed harness and names the agent each line came from. Use it to see what another session has already touched before you edit the same area.

Update your own status card on the user's canvas, the cockpit. Call it when you start a task ("working", with a short title and status), when you need the user ("waiting"), when you are stuck ("blocked"), and when you finish ("done"). "waiting" and "blocked" make the card pulse and the taskbar flash. Send "waiting" IN THE SAME TURN as the question you ask the user, right before you stop: the harness only knows to say "waiting" for a permission prompt, and a question asked in the chat is otherwise just the end of a turn — the user never sees that you are waiting for them. Your "waiting" survives the harness saying the turn ended. You declare the state; the app 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 user left on your card. Read it and act on it. Needs the app window open. This is a card, so nothing is stored in memory.

Add a subreddit, a Hacker News search query or a topic to the user's Pheme radar, or take one off. Pheme is their reputation cartridge: it finds fresh threads worth a genuine reply. The lists belong to them. An operation that would empty one is refused. Every operation reports its own outcome: done, already there, not there, refused. The user gets a receipt in Pheme naming this agent and what changed. Use it when a conversation finds a community worth watching. It scans nothing and posts nothing; the user posts. Needs the app running, though Pheme itself can be closed.

Read what the user's Pheme radar last found: fresh threads in the subreddits and Hacker News queries they watch. Each thread carries a topic score, and a tier once they have run the Mnemosyne pass. The tier says how much substance they can bring to that thread. The answer leads with when the scan ran, because it is only as fresh as the last time they opened Pheme and pressed Scan. Use it to find threads to draft a reply for; the user posts it. "No radar" means no scan has been projected yet, so ask them to open Pheme and scan. Needs the app running, though Pheme itself can be closed.

Put tasks into the user's To-do backlog, the To-do widget on their canvas, in order and optionally under named steps. Use it when a conversation has settled what to do. Name the destination list in "list": call once without it to get the existing lists back on a LIST_NOT_FOUND answer, or pass create_list: true to make a new one. Always name a list. The app routes the write through the widget's own store, so what you file is what the user 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_categories.

Read the user's To-do backlog back: the lists that exist and the tasks in them, each with the id you need to change it. Call this before mnemosyne_todo_update, which names tasks by id. A phrase like "delete the task about the invoice" reads perfectly and can still match the wrong task. This is also the way to answer "what is on my plate", or to check whether something is already filed before you add 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 user'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, so call that first. Removing a task archives it by default, and it can be restored. Pass permanent: true only when the user 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 user's To-do backlog: create one, rename or recolour one, remove an empty one. It is separate from mnemosyne_todo_update because these change the shape of a workspace rather than the work in it. Two refusals are worth knowing before you call. A list that still holds tasks is never removed, and you are told how many are in the way: move them first, since the app will not pick a destination on someone's behalf. The three original lists can be renamed, never removed, because their contents are what make the file readable. 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 user's calendar back: the appointments in a time window, each with the id you need to change or remove it. Call this before mnemosyne_agenda_update and mnemosyne_agenda_remove, which both name appointments by id. 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 user'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 user's calendar: move it, rename it, add or drop a reminder, start or stop it repeating. It names appointments by the id from mnemosyne_agenda_list, so call that first. A field you leave out is left alone, and passing null clears it. A start or end time that cannot be read refuses the change rather than leaving the old one quietly in place. A cadence outside daily, weekly, monthly and yearly is refused rather than 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 user's calendar. Read them with mnemosyne_agenda_list first and pass the ids. This tool matches by id only, 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 user to check. A repeating appointment is removed as a whole series, since the calendar cannot 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 user's calendar, the Agenda widget on their canvas. Use it when a conversation names a date and time to remember: a meeting, a deadline, "add this to my calendar". The app routes the write through the widget's own store, so what you file is what the user 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.