@saihm/mcp-server-pro

Official

Overview Schema Source Related Servers Discussions Admin

Remember

saihm_remember

Persistently store facts, decisions, or context with client-side encryption, so data survives sessions and remains unreadable to the server. Update existing entries by passing their cell ID.

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cellId`	No	Existing cell id (hex) to update; omit to create a new cell
`content`	Yes	Information to remember

Output Schema

TableJSON Schema

Name	Required	Description	Default
`seq`	Yes
`cellId`	Yes
`shardId`	Yes
`commitmentHash`	Yes
`sharesReissued`	Yes
`sharesIncomplete`	Yes
`sharesNotReissued`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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

Behavior4/5

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

The description discloses important behavioral traits beyond the annotations: encryption happens in-process, the key never leaves, the server holds ciphertext it cannot read, and the update behavior around re-issued shares. It also notes that a share not re-issued needs saihm_share again. The annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, and the description adds meaningful context about the encryption and share re-issuance behavior. It doesn't contradict the annotations. A 4 is appropriate because it adds rich behavioral context, though it doesn't cover every possible edge case.

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 a single paragraph that front-loads the core purpose and then provides necessary detail about encryption and update behavior. It is somewhat dense and could be split into clearer sentences, but every sentence earns its place. The structure is acceptable, though the share re-issuance explanation is a bit convoluted.

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 purpose, encryption behavior, update semantics, and the relationship to saihm_share and saihm_forget. It mentions the return value (cell id that saihm_forget takes). With an output schema present and annotations covering safety, the description is fairly complete. It could be slightly clearer about the exact conditions for re-issuance, but overall it provides enough context for an agent to call the tool 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 description coverage is 100%, so the schema already documents both parameters. The description adds meaning by explaining that cellId is for updating an existing cell and that omitting it creates a new cell, and it explains the update behavior around shares. This goes beyond the schema's simple descriptions, so a 4 is justified.

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: 'Store information in SAIHM persistent memory.' It clearly distinguishes the tool from siblings by stating it is for facts/decisions/context that should outlive the session, and it explicitly mentions updating an existing cell via cellId. This is a clear, specific purpose that an agent can act on.

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 explicitly states when to use the tool: 'Use this when a fact, decision, or piece of context should outlive the current session.' It also provides guidance on when to pass an existing cellId to update rather than create, and it mentions the relationship to saihm_share and saihm_forget. This is strong usage guidance with clear conditions and alternatives.

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

Deploy Server