Mnemoverse Memory

memory_write

Store durable long-term memories that persist across sessions and connected AI tools, so preferences, decisions, and lessons stay available. Avoid transient or sensitive data.

Instructions

Store a long-term memory that persists across sessions and across every AI tool the user has connected to Mnemoverse (Claude, ChatGPT, Cursor, VS Code). Suited to durable information: a stated preference, a decision, a fact about people, roles or project setup, a lesson learned; transient chatter that only matters this turn does not belong here. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records. Behavior: an importance gate may filter low-value writes, so the result tells you whether the memory was stored or filtered. Write content as a self-contained statement that still makes sense when recalled out of context.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	No	Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme'). Matched byte-for-byte — a leading space, a different case, or an invisible character opens a SEPARATE, permanent store, so reuse an exact name from memory_stats rather than retyping one. To write into a shared room, pass its address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms.
`content`	Yes	The memory to store as a self-contained statement, e.g. 'User prefers TypeScript strict mode' or 'Decided to deploy the API on Cloudflare Workers (2026-06)'.
`concepts`	No	Key concepts for linking related memories (e.g. ['deploy', 'friday', 'staging'])

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	No	The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. "Below importance threshold (0.047 < 0.1)". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display, and the value is capped at 400 characters. Absent when the service sent no explanation, or when nothing remains after that normalization.
`stored`	Yes	Whether the memory passed the novelty gate and was stored.
`memory_id`	Yes	Identifier of the stored memory, or null when it was not stored.
`importance`	No	Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. Outside shared rooms, a write that scores below the service's importance threshold is not stored, and `reason` says why when the service sends one. The score is approximate and can read lower for non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.14.2Oct 1, 2026

changedOutput schema / properties / importance / description

Previous value: -"Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. A first-generation metric UNDER ACTIVE DEVELOPMENT and known to be unreliable — the same content has measured ~0.08 in Russian against ~0.55 in English, so it under-reads non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score."New value: +"Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. Outside shared rooms, a write that scores below the service's importance threshold is not stored, and `reason` says why when the service sends one. The score is approximate and can read lower for non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score."

Changed3 schema fields changedv0.11.0Sep 23, 2026

addedInput schema / properties / concepts / maxItems
```
Added value: +256
```
addedInput schema / properties / domain / maxLength
```
Added value: +100
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "importance": {
+      "description": "Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. A first-generation metric UNDER ACTIVE DEVELOPMENT and known to be unreliable — the same content has measured ~0.08 in Russian against ~0.55 in English, so it under-reads non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score.",
+      "type": "number"
+    },
+    "memory_id": {
+      "description": "Identifier of the stored memory, or null when it was not stored.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reason": {
+      "description": "The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. \"Below importance threshold (0.047 < 0.1)\". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display, and the value is capped at 400 characters. Absent when the service sent no explanation, or when nothing remains after that normalization.",
+      "type": "string"
+    },
+    "stored": {
+      "description": "Whether the memory passed the novelty gate and was stored.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "stored",
+    "memory_id"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.10.0Sep 16, 2026

changedInput schema / properties / domain / description

Previous value: -"Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme')"New value: +"Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme'). Matched byte-for-byte — a leading space, a different case, or an invisible character opens a SEPARATE, permanent store, so reuse an exact name from memory_stats rather than retyping one. To write into a shared room, pass its address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms."

First observedv0.3.7Jun 17, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly=false, destructive=false, idempotent=false. The description adds meaningful behavior beyond that: an importance gate may silently filter low-value writes and the response reports stored vs filtered, plus a hard prohibition list (passwords, keys, payment, MFA, IDs, health records). This is exactly the context an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: purpose first, then suitability, then prohibitions, then behavior. Every sentence earns its place, though the multi-clause structure is heavier than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so returns need not be described, yet the description still flags that the result signals stored-or-filtered. Combined with privacy constraints and content-quality guidance, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for `content` — it must be a self-contained statement that survives recall out of context — which the schema does not state. Domain/concepts semantics are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (store) and resource (long-term memory) plus scope: persistence across sessions and across every connected AI tool. This clearly separates it from read/list/stats siblings like memory_read and memory_list_recent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit inclusion criteria (stated preference, decision, fact, lesson learned) and an exclusion (transient chatter that only matters this turn). It does not name an alternative tool, but no sibling offers competing write semantics, so routing guidance is effectively complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server