# Mnemosyne OS (npm · @mnemosyne_os/mcp)

Memory the human governs, on their own machine, plus what other coding agents here wrote.

- Trust score: 72/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

## Components

- npm · `@mnemosyne_os/mcp`: 72/100 (this document), [markdown](https://verifymcp.io/servers/mnemosyne-os-mcp/mnemosyne-os-mcp.md), [page](https://verifymcp.io/servers/mnemosyne-os-mcp/mnemosyne-os-mcp)

## Channel facts

- Registry: `npm`
- Package: `@mnemosyne_os/mcp`
- Version: `2.0.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-25.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 96 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 2 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6797 tokens (~271/item across 25 items; 25 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 20/100
  - Stability check failed: the tool surface changed between 1.7.0 and 2.0.0: 8 tool removals, 0 breaking changes, 18 additions.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 26 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Mnemosyne OS MCP server?

Mnemosyne OS runs locally as an npm package, launched with npx -y @mnemosyne_os/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add mnemosyne-os-mcp -- npx -y @mnemosyne_os/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "mnemosyne-os-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@mnemosyne_os/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "mnemosyne-os-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@mnemosyne_os/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add mnemosyne-os-mcp -- npx -y @mnemosyne_os/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mnemosyne-os-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@mnemosyne_os/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add mnemosyne-os-mcp --command npx --arg -y --arg @mnemosyne_os/mcp
```

### Hermes

```yaml
mcp_servers:
  mnemosyne-os-mcp:
    command: "npx"
    args: ["-y", "@mnemosyne_os/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "mnemosyne-os-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@mnemosyne_os/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add mnemosyne-os-mcp -t stdio -c npx -a -y @mnemosyne_os/mcp
```

### Other

```json
{
  "mcpServers": {
    "mnemosyne-os-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@mnemosyne_os/mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-25 (score 72, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-23 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13.

### 2026-09-21 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7.

### 2026-09-17 (score 69, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-09-16 (score 54, −19)

- [security regression] Malware scan: pass → unverified
- [security regression] Stability: 0.40 → fail
- [functional] Destructive annotations: All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
- [functional] Package version: 1.10.0 → 2.0.0

### 2026-09-14 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-13 (score 72, +26)

- [security improvement] Malware scan: unverified → pass
- [security improvement] Known CVEs: unverified → pass
- [functional improvement] Dependency health: unverified → 0.84

### 2026-09-12 (score 46, −27)

- [security regression] Malware scan: pass → unverified
- [security regression] Known CVEs: pass → unverified
- [security regression] Stability: 0.27 → unverified
- [security regression] Tool safety: pass → unverified
- [functional regression] Schema quality: 4285 → 6528
- [functional regression] Schema quality: 4285 → 6137
- [functional regression] Dependency health: 0.84 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional] Schema quality: Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- [functional] Destructive annotations: pass → 0
- [functional] Package version: 1.7.0 → 1.10.0
- [functional] Package version: 1.7.0 → 1.9.0
- [functional] Package version: 1.4.5 → 1.9.0

## MCP tools (25)

### `mnemosyne_about` (~100 tokens)

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.

### `mnemosyne_memory_query` (~528 tokens)

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_memory_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.

Input parameters:

- `limit` (number): Max number of results (default: 10, max: 50)
- `max_content_chars` (number): Per-chronicle content snippet size in chars (default: 600). Each result is truncated to this length with a hint about total size. Raise to 2000+ when you genuinely need full file content, but be awar…
- `query` (string, required): The search query. Be specific. Examples: "Phase 51 auto-poll implementation", "SDK authentication bug", "why did we choose dual-vector dimensions".
- `spine_type_filter` (array): Optional whitelist of spineTypes: restricts results to those types only. Use ["ARCHITECTURE"] to surface design docs over code, ["GIT"] for commit history, ["BUGFIX","DEBUG"] for incident knowledge,…
- `vault` (string): Vault TOKEN to query (case-insensitive; the folder name uppercased, spaces and hyphens as underscores). The path-shaped `id` from mnemosyne_vault_list is also accepted and normalized. Mnemosyne OS ex…

### `mnemosyne_memory_ask` (~266 tokens)

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 <name> and what do they own?"). Slower than mnemosyne_memory_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_memory_query. Always check the sources before trusting the answer.

Input parameters:

- `question` (string, required): A natural-language question, as you would ask a knowledgeable colleague. Be specific.
- `vault` (string): Vault to reason over (case-insensitive). Default for this deployment: "DEV". A vault not declared to this MCP is refused with SCOPE_DENIED.

### `mnemosyne_vault_list` (~150 tokens)

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, never 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.

### `mnemosyne_memory_ingest` (~303 tokens)

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.

Input parameters:

- `content` (string, required): Content to persist (markdown supported). Be self-contained: include WHY the decision was made, not just WHAT.
- `spine_type` (string): Semantic type of the content. ARCHITECTURE is heavily boosted (×1.40) in SOURCE_CODE scope queries. Use it for design docs, big-picture decisions, structural choices. DECISION for narrower trade-offs…
- `vault` (string): Target vault TOKEN: the folder name uppercased, spaces and hyphens as underscores (e.g. MNEMOSYNE_OS). The path-shaped `id` from mnemosyne_vault_list is also accepted and normalized. Default for this…

### `mnemosyne_resonance_list` (~148 tokens)

List the Resonances recorded in the default vault, the cognitive workspaces tracking ongoing projects. Read-only: it queries memory and writes nothing. Each entry carries the resonance id, its last phase, how many minutes ago it moved, and the id of the chronicle behind it. There is no active/paused filter and no status field: you get every resonance the scan matched, in one vault, from at most 30 candidates. An empty result answers in words and means no resonance has been recorded yet, never that the call failed. Call mnemosyne_position_get with an id to read one in full, or mnemosyne_position_update to write a new one.

### `mnemosyne_position_get` (~163 tokens)

Read the last saved position of one Resonance: the phase and the free-text note an agent or the cockpit wrote when it stopped. Read-only: it queries memory and writes nothing. Returns the resonance id, when it was saved, the chronicle spineType, and the whole note. When nothing was ever saved under that id it answers in plain words and points at mnemosyne_position_update, never an error, so "never recorded" and "the call failed" do not look alike. Use it to resume work; call mnemosyne_resonance_list first when you do not know the id.

Input parameters:

- `resonance_id` (string, required): ID of the resonance (e.g. "agent-cockpit", "mnemosync-p2p")

### `mnemosyne_position_update` (~117 tokens)

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.

Input parameters:

- `phase` (string, required): Current phase label (e.g. "Phase 52", "v1.1.0 release")
- `position` (string, required): Description of the current position / what was done / what is next
- `resonance_id` (string, required): ID of the resonance to update

### `mnemosyne_git_log` (~176 tokens)

Read recent commits from the Mnemosyne OS monorepo. Read-only: it reads the repository and writes nothing. Each commit carries an 8-character hash, the subject line, the author and the date, newest first. The repository path is fixed on the OS side, so this cannot be pointed at another checkout, and it needs the monorepo:read scope; when either is missing it answers with a message naming what is missing instead of an empty list that would read as "no commits". Use it for what changed and when, and mnemosyne_memory_query for the reasoning behind a change.

Input parameters:

- `limit` (number): Number of commits to return (default: 20)
- `since` (string): Time range (e.g. "7 days ago", "2024-01-01")

### `mnemosyne_dream_bridges` (~230 tokens)

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).

Input parameters:

- `chronicle_id` (number): Only bridges touching this chronicle id (either endpoint).
- `limit` (number): Max bridges to return, strongest (highest dbs) first (default: 50, server cap: 200).
- `min_dbs` (number): Only bridges with a Dream Bridge Score at or above this value (0-1).
- `session_id` (string): Restrict to one dream scan session.

### `mnemosyne_spine_assignments` (~219 tokens)

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_memory_query.

Input parameters:

- `include_taxonomy` (boolean): Also return the global spine taxonomy tree (natures → sub-spines).
- `limit` (number): Max assignments returned (default: 25 to stay context-friendly, server cap: 500).
- `offset` (number): Pagination offset (default: 0).
- `spine_type` (string): Restrict the assignment page to one spine taxon id (e.g. "DOCUMENT", "GIT"). Counts stay whole-vault.
- `vault` (string): Vault to inspect (case-insensitive). Default for this deployment: "DEV".

### `mnemosyne_agent_list` (~275 tokens)

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.

Input parameters:

- `limit` (number): How many transcripts to open PER HARNESS, newest first (default 40, max 200). Capping the merged total instead would let a chatty agent push a quiet one off the end, and the quiet one is the session…
- `live_only` (boolean): Only sessions that wrote a line recently (see the window printed in the answer). Default false, which lists the most recent sessions whether or not they moved lately.
- `project` (string): Keep only sessions whose project path contains this string. Pass the repository folder name to scope the answer to the repo you are working in.

### `mnemosyne_agent_collisions` (~228 tokens)

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.

Input parameters:

- `project` (string): Restrict to one working tree, matched exactly (separators and case are normalised). Pass the output of `git rev-parse --show-toplevel`. Omit to check every project on the machine.

### `mnemosyne_agent_files` (~186 tokens)

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.

Input parameters:

- `contains` (string): Keep only paths containing this string. A folder name works as well as a file name.
- `limit` (number): Max files to return (default 40, max 200).
- `project` (string): Keep only files from sessions whose project path contains this string.

### `mnemosyne_cockpit_update` (~364 tokens)

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.

Input parameters:

- `attention` (boolean): Ask for the human's eye even in "working"/"done" (the card pulses, the taskbar flashes). "waiting" and "blocked" ask on their own.
- `detail` (array): Up to 4 short lines under the status (files, a branch, a count). Optional.
- `session` (string): Only when the harness publishes no CLAUDE_CODE_SESSION_ID: a stable id for this conversation, reused on every call.
- `state` (string, required): "working" = on it; "waiting" = you asked the human something and stopped; "done" = the task is finished; "blocked" = you cannot continue without them; "closed" = this conversation is over (removes th…
- `status` (string): One line: what you are doing right now, or what you need. 160 characters max.
- `title` (string): What this conversation is about, in a few words (the card's title). Give it at least once; later calls may omit it.

### `mnemosyne_pheme_watch` (~184 tokens)

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.

Input parameters:

- `ops` (array, required): The changes, in order. Up to 50.

### `mnemosyne_pheme_radar` (~207 tokens)

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.

Input parameters:

- `limit` (number): How many threads at most (default 30, max 100).
- `tier` (string): Only threads of this tier. Omit for all (unranked ones included, last).

### `mnemosyne_todo_add` (~392 tokens)

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_categories.

Input parameters:

- `color` (string): Hex colour (#rrggbb) for a list being created. Optional; the host picks the next swatch otherwise.
- `create_list` (boolean): Create the list named in "list" when it does not exist. Default false: an agent must not invent lists in someone's backlog without saying so.
- `list` (string): Displayed name of the destination list (case-insensitive), e.g. "En cours", "WIP", or a list the human created. Omitted = the first original list. Unknown name + create_list false = refused with the…
- `tasks` (array, required): The tasks, in execution order. Each item is a string, or {"text": string, "group": string} where group is the STEP the task belongs to (e.g. "Step 1 · Mockup"); tasks with the same group are shown un…

### `mnemosyne_todo_list` (~268 tokens)

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.

Input parameters:

- `include_done` (boolean): Include tasks already checked off. Default false: the open ones are what almost every question is actually about. Tasks moved to the ARCHIVE are never listed, only counted.
- `limit` (number): Maximum tasks returned (default and ceiling: 300). The answer always says how many matched and how many were cut.
- `list` (string): Only this list, by displayed name (case-insensitive) or by the key shown in brackets. Omitted = every list. A name that matches nothing returns NO tasks rather than silently widening to all of them.

### `mnemosyne_todo_update` (~179 tokens)

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.

Input parameters:

- `ops` (array, required): The changes, applied in order. Up to 100 per call.

### `mnemosyne_todo_categories` (~191 tokens)

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.

Input parameters:

- `ops` (array, required): The changes, applied in order - so you can create a list and rename another in one call.

### `mnemosyne_agenda_list` (~280 tokens)

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.

Input parameters:

- `from` (string): ISO 8601 date-time (or epoch ms). Only appointments with an occurrence at or after this. Omitted = now.
- `include_past` (boolean): Include appointments with no occurrence left. Default false. Those ones come back with no "next" date rather than with their original start dressed up as a future one.
- `limit` (number): Maximum appointments returned (default and ceiling: 200).
- `to` (string): ISO 8601 date-time (or epoch ms). Only appointments with an occurrence at or before this. Omitted = no upper bound, which for a repeating event means it always counts.

### `mnemosyne_agenda_update` (~174 tokens)

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.

Input parameters:

- `changes` (array, required): One entry per appointment. Up to 50 per call.

### `mnemosyne_agenda_remove` (~187 tokens)

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.

Input parameters:

- `event_ids` (array, required): The appointment ids to remove, exactly as mnemosyne_agenda_list printed them in brackets. Up to 50.

### `mnemosyne_agenda_add` (~155 tokens)

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.

Input parameters:

- `events` (array, required): One or more appointments to add.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/mnemosyne-os-mcp/mnemosyne-os-mcp#diagnostics

## Score history

- 2026-09-25: 72
- 2026-09-24: 71
- 2026-09-23: 71
- 2026-09-22: 70
- 2026-09-21: 70
- 2026-09-20: 69
- 2026-09-19: 69
- 2026-09-18: 69
- 2026-09-17: 69
- 2026-09-16: 54
- 2026-09-15: 73
- 2026-09-14: 73
- 2026-09-13: 72
- 2026-09-12: 46
- 2026-09-11: 73
- 2026-09-10: 69
- 2026-09-09: 69
- 2026-09-08: 69
- 2026-09-07: 69
- 2026-09-06: 69
- 2026-09-05: 69
- 2026-09-04: 69
- 2026-09-03: 69
- 2026-09-02: 39
- 2026-09-01: 39
- 2026-08-31: 39
- 2026-08-30: 39
- 2026-08-29: 39

## Common questions

### What is the Mnemosyne OS MCP server?

Mnemosyne OS is an MCP server listed in the public MCP registry as io.github.Mnemosyne-OS/mcp. Memory the human governs, on their own machine, plus what other coding agents here wrote. This page covers its npm package (@mnemosyne_os/mcp).

### Is the Mnemosyne OS MCP server safe to use?

Mnemosyne OS scores 72 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Mnemosyne OS MCP server expose?

Mnemosyne OS exposes 25 tools: mnemosyne_about, mnemosyne_memory_query, mnemosyne_memory_ask, mnemosyne_vault_list, mnemosyne_memory_ingest, and 20 more. Their descriptions and schemas cost roughly 5,670 tokens of context every time the server is loaded.

### Is the Mnemosyne OS MCP server still maintained?

Mnemosyne OS is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Mnemosyne OS MCP server under?

Mnemosyne OS declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@mnemosyne_os/mcp
- Socket report: https://socket.dev/npm/package/@mnemosyne_os/mcp
- Repository: https://github.com/Mnemosyne-OS/Mnemosyne-Neural-OS
- Website: https://mnemosyne-os.io/
- Changelog RSS feed: https://verifymcp.io/servers/mnemosyne-os-mcp/mnemosyne-os-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/mnemosyne-os-mcp/mnemosyne-os-mcp.json
- HTML version of this page: https://verifymcp.io/servers/mnemosyne-os-mcp/mnemosyne-os-mcp