@saihm/mcp-server-pro

Official

Overview Schema Source Related Servers Discussions Admin

Remember

saihm_remember

Store information in SAIHM persistent memory. Encryption happens in this process and the key never leaves it, so the server holds ciphertext it cannot read.

Instructions

Store information in SAIHM persistent memory. Encryption happens in this process and the key never leaves it, so the server holds ciphertext it cannot read. Use this when a fact, decision, or piece of context should outlive the current session. Pass an existing cellId to update that cell instead of adding a new one; when the endpoint reports that the update left shares of the cell on the previous version, they are re-issued for the new version and the result counts them, and a share that was not re-issued needs saihm_share again. Returns the cell id that saihm_forget takes. With warmStart "put", it instead stores an encrypted warm-start snapshot of the payload file named by token.

Input Schema

TableJSON Schema

Name	Required	Description
`token`	No	With warmStart: 16 to 32 characters from a-z and 0-9, chosen at random for this call. It names the payload file. Blank otherwise.
`cellId`	No	Existing cell id (hex) to update; omit to create a new cell
`content`	No	Information to remember. Required unless warmStart is "put".
`warmStart`	No	"put" stores the payload file warm-start/put-<token>.bin as an encrypted snapshot, then removes the file. Only coversThrough and token go with it. Leave it blank to remember content.
`coversThrough`	No	With warmStart "put": the change feed position the payload covers, the cursor of a position marker. Blank otherwise.

Output Schema

TableJSON Schema

Name	Required	Description
`at`	No
`seq`	No
`bytes`	No
`error`	No
`cellId`	No
`timing`	No
`shardId`	No
`createdAt`	No
`commitment`	No
`snapshotId`	No
`coversThrough`	No
`commitmentHash`	No	Deprecated: the same value as commitment, kept for existing readers.
`sharesReissued`	No
`sharesIncomplete`	No
`sharesNotReissued`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.14.1Oct 14, 2026

changedInput schema / properties / coversThrough / description

Previous value: -"With warmStart \"put\": the change feed position the payload covers, the cursor of a position marker."New value: +"With warmStart \"put\": the change feed position the payload covers, the cursor of a position marker. Blank otherwise."

changedInput schema / properties / coversThrough / pattern

Previous value: -"^[!-~]{1,64}$"New value: +"^$|^[!-~]{1,64}$"

changedInput schema / properties / token / description

Previous value: -"With warmStart: 16 to 32 characters from a-z and 0-9, chosen at random for this call. It names the payload file."New value: +"With warmStart: 16 to 32 characters from a-z and 0-9, chosen at random for this call. It names the payload file. Blank otherwise."

changedInput schema / properties / token / pattern

Previous value: -"^[a-z0-9]{16,32}$"New value: +"^$|^[a-z0-9]{16,32}$"

changedInput schema / properties / warmStart / description

Previous value: -"\"put\" stores the payload file warm-start/put-<token>.bin as an encrypted snapshot, then removes the file. Only coversThrough and token go with it."New value: +"\"put\" stores the payload file warm-start/put-<token>.bin as an encrypted snapshot, then removes the file. Only coversThrough and token go with it. Leave it blank to remember content."

changedInput schema / properties / warmStart / enum

Previous value: -[
-  "put"
-]New value: +[
+  "",
+  "put"
+]

Changed15 schema fields changedv0.13.0Oct 7, 2026

changedInput schema / properties / content / description

Previous value: -"Information to remember"New value: +"Information to remember. Required unless warmStart is \"put\"."

addedInput schema / properties / coversThrough

Added value: +{
+  "description": "With warmStart \"put\": the change feed position the payload covers, the cursor of a position marker.",
+  "pattern": "^[!-~]{1,64}$",
+  "type": "string"
+}

addedInput schema / properties / token

Added value: +{
+  "description": "With warmStart: 16 to 32 characters from a-z and 0-9, chosen at random for this call. It names the payload file.",
+  "pattern": "^[a-z0-9]{16,32}$",
+  "type": "string"
+}

addedInput schema / properties / warmStart

Added value: +{
+  "description": "\"put\" stores the payload file warm-start/put-<token>.bin as an encrypted snapshot, then removes the file. Only coversThrough and token go with it.",
+  "enum": [
+    "put"
+  ],
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "content"
-]
```

addedOutput schema / properties / at

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / bytes
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / commitment
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / commitmentHash / description

Added value: +"Deprecated: the same value as commitment, kept for existing readers."

addedOutput schema / properties / coversThrough
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / createdAt
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "code": {
+      "type": "string"
+    },
+    "status": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "code",
+    "status"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / snapshotId
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / timing

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "admission": {
+      "anyOf": [
+        {
+          "enum": [
+            "reserved",
+            "shared"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "serverMs": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "totalMs": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "serverMs",
+    "totalMs",
+    "admission"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "cellId",
-  "seq",
-  "shardId",
-  "commitmentHash",
-  "sharesReissued",
-  "sharesNotReissued",
-  "sharesIncomplete"
-]

Changed4 schema fields changedv0.10.0Sep 17, 2026

addedOutput schema / properties / sharesIncomplete

Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / sharesNotReissued

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / sharesReissued

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "cellId",
-  "seq",
-  "shardId",
-  "commitmentHash"
-]New value: +[
+  "cellId",
+  "seq",
+  "shardId",
+  "commitmentHash",
+  "sharesReissued",
+  "sharesNotReissued",
+  "sharesIncomplete"
+]

First observedv0.2.1Jul 29, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare write/openWorld/non-idempotent, and the description adds substantial context on top: the encryption model (key never leaves the process, server holds unreadable ciphertext), the share re-issue side effect on updates, and the warmStart snapshot behavior including file removal. This is genuinely useful behavioral disclosure 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.

Conciseness3/5

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

The purpose is correctly front-loaded, but the share re-issue clause is a dense run-on ('...they are re-issued for the new version and the result counts them, and a share that was not re-issued needs saihm_share again') that is hard to parse. The warmStart branch is tacked onto the end, making the single paragraph feel overloaded.

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 5-parameter tool with two operating modes (content store vs warmStart snapshot), the description covers both modes, the encryption guarantee, and cross-references saihm_forget/saihm_share. With an output schema present it need not detail return values, and it is largely complete, though the update/share interaction remains the least clear part.

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: it explains that cellId switches to update mode, that warmStart 'put' consumes token/coversThrough and stores a snapshot, and how shares interact with updates. It adds value over the schema rather than merely restating it.

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

Purpose4/5

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

The description opens with a specific verb+resource ('Store information in SAIHM persistent memory') and clarifies the create-vs-update mode via cellId, distinguishing it from the read sibling (saihm_recall) and the delete sibling (saihm_forget). It never explicitly names saihm_recall as the read counterpart, so full sibling differentiation is implied rather than stated.

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?

'Use this when a fact, decision, or piece of context should outlive the current session' gives a clear triggering condition, and it names saihm_share as the follow-up when a share is not re-issued. It lacks an explicit when-not statement (e.g., prefer saihm_recall to read), leaving one inference.

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

Deploy Server