Compartment

Overview Schema Source Related Servers Discussions Admin

Store a memory

memory_store

Save one durable fact, preference, decision, credential, or configuration to encrypted cross-session memory for future recall. Provide a source so each stored claim records how it was established.

Instructions

Save ONE claim to the user's persistent, encrypted, cross-session memory.

STORE anything worth referencing again in future work: names, addresses, contacts, account IDs, passwords, API keys and other credentials, lasting file locations and configuration, preferences, and every durable fact or decision reached. Not transient chatter, one-off trivia, things freely available on the internet, or the working details of a task in progress, such as run results, errors, log contents and temporary paths or settings.

text is ONE claim, at most 200 characters (the max_memory_chars default) - enforced, and lists, headings and paragraphs are refused with it. Several facts go through memory_store_many, one record each, in one call.

kind is "fact" (default) or "opinion". Opinions - preferences, stances, judgement calls, recommendations - UPDATE instead of accumulate: storing one that resembles a live opinion returns {"stored": false, "conflicts": [old records]} instead of inserting. Resend with supersedes=[old id] to replace (send a merged text to keep parts of both), or supersedes=[] to deliberately hold both. Restating a live opinion refreshes its date and returns {"reaffirmed": true}. Put the why inside the claim ("advised X: reason"). supersedes also works on facts, to correct one: the replaced record leaves search but stays readable by id.

source is REQUIRED: how the fact was established, in a few words - "web search", "read from pyproject.toml", "from chat". Never invent one. compartment stamps it, the discovery date and any expiry onto the text as "[web search, 2026-08-01]", so never write them into the text yourself. discovered (YYYY-MM-DD) is only for a fact established before today. expires is only for a fact that knows its last true day: 2026-09-03, or 14d / 2w / 3m / 1y, that day inclusive.

importance, 0.0-1.0 (default 0.5, out-of-range clamped): 0.90 decisions, consent, "remember this"; 0.80 personal facts and preferences; 0.75 the user's machine and configuration; 0.55 other substantive statements; 0.20 pleasantries.

Returns the id (an existing id if a near-duplicate), with the stamped date.

Input Schema

Name	Required	Default
`kind`	No	fact
`tags`	No
`text`	Yes
`source`	Yes
`expires`	No
`namespace`	No
`discovered`	No
`importance`	No
`supersedes`	No
`quarantined`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv4.9.5Sep 3, 2026

addedInput schema / properties / kind

Added value: +{
+  "default": "fact",
+  "enum": [
+    "fact",
+    "opinion"
+  ],
+  "title": "Kind",
+  "type": "string"
+}

addedInput schema / properties / supersedes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Supersedes"
+}

Changed1 schema field changedv4.8.0Aug 26, 2026

addedInput schema / properties / expires

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Expires"
+}

Changed3 schema fields changedv4.5.0Aug 2, 2026

addedInput schema / properties / discovered

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Discovered"
+}

addedInput schema / properties / source

Added value: +{
+  "title": "Source",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "text"
-]New value: +[
+  "text",
+  "source"
+]

First observedJul 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false/destructiveHint=false, so the description carries most of the load and does so well: the 200-character limit is described as enforced with lists and paragraphs refused, opinion writes may return {stored: false, conflicts: [...]}, reaffirmation returns {reaffirmed: true}, and superseded records leave search but remain readable by id. The one gap is that `quarantined` is never explained, so an agent can't know what that side effect does.

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?

Long but dense and well front-loaded: what to store, what not to store, then per-parameter rules in the order an agent would fill them. Nearly every sentence carries a rule or a return shape, though the conflict/supersedes block is somewhat convoluted and could be tighter.

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

Completeness4/5

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

For a 10-parameter mutation tool with no annotations covering behavior, the description supplies refusal modes, conflict handling, stamping behavior, and importance heuristics, and an output schema means return values needn't be restated. The remaining deficiencies are the undocumented `tags`, `namespace`, and especially `quarantined`, which is a behaviorally meaningful flag.

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 0%, so the description must compensate and largely does: it defines `text` (one claim, 200 chars, lists refused), `kind` with its fact/opinion behavior, `source` as REQUIRED plus its stamping format, `discovered` and `expires` formats, `importance` with a concrete rubric, and `supersedes` with the []-to-keep-both nuance. It says nothing about `tags`, `namespace`, or `quarantined`, leaving three of ten parameters undocumented anywhere.

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 precise verb and resource ("Save ONE claim to the user's persistent, encrypted, cross-session memory") and immediately scopes it to exactly one claim, distinguishing it from memory_store_many which handles several facts in one call. An agent can tell from the first two sentences which memory-writing sibling to pick.

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

Usage Guidelines5/5

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

Gives an explicit inclusion list (names, contacts, credentials, preferences, durable decisions) and an explicit exclusion list (transient chatter, one-off trivia, internet-available facts, in-progress task details such as run results and logs). It also names the alternative tool and the condition selecting it: "Several facts go through memory_store_many, one record each, in one call."

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

Deploy Server