Compartment

Overview Schema Source Related Servers Discussions Admin

Store a memory

memory_store

Save one durable fact, credential, preference, or decision to the user's persistent encrypted memory for future sessions. Returns an id, and supersedes older entries when updating.

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

TableJSON 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

TableJSON 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.7/5.0

Behavior5/5

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

Annotations only declare readOnly=false and destructive=false; the description adds substantial behavior: encryption and cross-session persistence, source stamping of date/expiry, opinion conflict semantics returning {'stored': false, 'conflicts': [...]}, reaffirmation behavior, and that superseded facts leave search but remain readable by id. This goes well beyond the annotations.

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 densely front-loaded: the store/don't-store rule leads, then per-parameter semantics follow in labeled blocks. Nearly every sentence carries operational detail, though the volume is heavy for a store tool and could be trimmed slightly.

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 0% schema coverage, the description is unusually complete on text/source/kind/importance/supersedes and explains the return shape even though an output schema exists. It stops short of documenting tags, namespace, and quarantined, which an agent cannot infer from the schema alone.

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 description coverage is 0%, so the description carries the full burden and does so for text (200-char limit, one claim, lists refused), kind, supersedes, source, discovered, expires, and importance with concrete defaults and examples. It omits any explanation of tags, namespace, and quarantined (3 of 10 params), leaving real gaps.

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 and resource ('Save ONE claim to the user's persistent... memory') and explicitly scopes it to a single claim, immediately contrasting with the sibling that handles multiple ('Several facts go through memory_store_many'). An agent can distinguish this from memory_store_many without opening either schema.

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 explicit inclusion criteria (names, credentials, preferences, durable decisions) and explicit exclusions (transient chatter, internet-available trivia, in-progress task details). It also names the alternative (memory_store_many) and the condition that selects it, so routing is unambiguous.

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

Deploy Server