Compartment

by MaxFreedomPollard

Overview Schema Source Related Servers Discussions Admin

Python

Local

Store a memory

memory_store

Persist one important claim—fact, preference, or credential—to an encrypted vault for cross-session recall.

Instructions

Save ONE claim to the user's persistent, encrypted, cross-session memory: anything worth recalling later that is not common public knowledge

names, addresses, contacts, account IDs, passwords, API keys and other credentials, file paths, configuration, preferences, and durable facts or decisions. Call it the moment such information appears; do not store transient chatter or one-off trivia.

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?

Beyond the basic annotations, the description discloses rich behavior: opinions update instead of accumulate, conflicts return a structured response, supersedes replaces or retains records, source is stamped, and near-duplicates return an existing id. This goes well beyond what the annotations alone convey and gives the agent an accurate model of side effects.

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?

The description is long but densely packed and logically organized by parameter. Every section earns its place for a tool with 10 parameters, and the use of backticked parameter names makes it scannable. It is slightly verbose, but the complexity justifies the length.

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?

The description covers the core parameters, expected return values, conflict behavior, and the tool's memory semantics. It is incomplete only in omitting 'tags', 'namespace', and 'quarantined', which an agent might need to set correctly. Given the tool's complexity and 0% schema coverage, these omissions prevent a perfect completeness score.

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 for parameter meaning. It thoroughly explains text length and format constraints, kind semantics, source requirements, discovered/expires formats, importance values, and supersedes behavior. However, 'tags', 'namespace', and 'quarantined' are never explained, leaving three parameters semantically undocumented.

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?

The description opens with a specific verb and resource: 'Save ONE claim to the user's persistent, encrypted, cross-session memory.' It also clearly scopes what belongs in memory ('names, addresses, contacts...') and distinguishes itself from memory_store_many by emphasizing singular claims. This makes the tool's purpose unmistakable.

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?

The description gives explicit when-to-use guidance: 'Call it the moment such information appears; do not store transient chatter or one-off trivia.' It also names the alternative directly: 'Several facts go through memory_store_many, one record each, in one call.' This is strong directional guidance for an agent choosing among sibling tools.

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

Deploy Server