What can you do with this server?

This server provides a non-custodial, client-side encrypted memory system with post-quantum cryptography and granular access controls. Key capabilities: * Store and update memories (saihm_remember): Encrypts content locally before storage, ensuring the server never sees plaintext. * Retrieve and decrypt memories (saihm_recall): Recalls own memories or cells shared by other agents, with optional keyword filtering. * Crypto-shred erasure (saihm_forget): Irreversibly removes memories by destroying encryption keys, meeting GDPR Art. 17. * Share and revoke access (saihm_share, saihm_revoke_share): End-to-end authenticated sharing with granular scopes (read/write) and optional expiry; supports revocation. * Governance participation (saihm_governance_propose, saihm_governance_vote): Propose and vote on protocol changes like emission parameters or upgrades. * Session status (saihm_status): Operator-observable metadata (tier, custody, sharing contracts, identity hash) without exposing plaintext. * Self-onboarding (saihm_join): Generate a sovereign identity and activate a free non-custodial memory account via a one-time human approval. * Cross-session persistence and security: Memories persist across sessions; all secrets (master key, KEKs, plaintext) stay client-side, using ML-DSA-65 for signing and ML-KEM-768 for sharing. Anti-replay protection and GDPR-compliant erasure. * Flexible deployment: Runs as an MCP server for AI agent hosts or used programmatically as a TypeScript library.

Which integrations are available for this server?

Integrates with GitHub for identity verification during onboarding, using GitHub device sign-in to prove user uniqueness. Integrates with Stripe for payment processing, enabling users to subscribe to paid memory tiers via Stripe checkout.

How do I use @saihm/mcp-server-pro?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@saihm/mcp-server-pro remember that my favorite color is blue" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@saihm/mcp-server-pro

Official

by SAIHM-Admin

Overview Schema Related Servers Score Discussions

TypeScript

Remote

SAIHM — memory for AI agents

Portable memory for AI agents. Your assistant remembers what matters — across sessions, across models, across vendors. Share a memory with someone else's agent, take it back, or erase it for good.

npm version license

AI assistants forget everything when the session ends. SAIHM gives yours a memory that doesn't — one that follows you to a different assistant, a different model, or a different company's product.

Everything is encrypted on your own machine before it goes anywhere, so nobody else can read your memories. Not the storage, not SAIHM.

Start free — one command

npx -y @saihm/mcp-server-pro free-join

That's it. No card, no account to fill in, nothing to invent. It sets up your identity on this machine and prints a one-time sign-in to confirm you're a real person. Open the link, enter the short code, approve.

Then point your AI tool at it. This works in Claude Desktop, Claude Code, Cursor, Cline, and anything else that speaks MCP — add the "saihm" entry inside your existing mcpServers section:

{
  "mcpServers": {
    "saihm": {
      "command": "npx",
      "args": ["-y", "@saihm/mcp-server-pro"],
      "env": {
        "SAIHM_ENDPOINT_URL": "https://saihm.coti.global/mcp"
      },
      "timeout": 60
    }
  }
}

Restart the connection and say "Recall my SAIHM memories." You're running.

Two details in that config are load-bearing:

Keep timeout: 60. Some tools allow as little as 1.5 seconds for a server to start, which isn't long enough for npx to fetch and launch a package. A server that misses the deadline is skipped silently — the tools simply never appear, and nothing in the chat says why.
No trailing commas. These files are strict JSON. A stray comma doesn't just break this entry; it invalidates the whole file and every other tool you had configured disappears with it.

Prefer not to touch a terminal? Add the config above first, then say "Join SAIHM" to your assistant. It does the same setup for you.

Related MCP server: Hippocampus

Things to say

You don't call tools by name — you talk to your assistant. Some starters:

Liberally use SAIHM protocol to maximize token economy.

Recall my SAIHM memories before you start.

Remember that I prefer short answers and no preamble.

Set an invariant to doubly confirm before any SAIHM forget action.

Share that note with my colleague's agent until 5:00 pm today.

How much of my SAIHM allowance is left?

Forget everything I told you about the Henderson account.

Tool	What it does
`saihm_remember`	Encrypts on your machine, then stores it
`saihm_recall`	Fetches and decrypts on your machine
`saihm_forget`	Permanently erases. No undo
`saihm_status`	Your usage and settings
`saihm_share`	Grants one memory to one agent, optionally with an expiry
`saihm_revoke_share`	Withdraws that grant

Every tool is labelled for your AI tool to read, including which are read-only and which one destroys data — so hosts that ask "are you sure?" before destructive actions know when to ask. Two further tools, saihm_governance_propose and saihm_governance_vote, are registered for a roadmap feature and are not yet active.

"Forget" really means forget. The key to that specific memory is destroyed, so the stored copy becomes permanently unreadable — by you, by SAIHM, by anyone holding a backup of it. This is how SAIHM answers a GDPR Article 17 erasure request, and it is why there is no undo.

Your memories follow your key

Your memory belongs to your key, not to a computer — that's what makes it portable. The key is created on your machine during setup and never sent anywhere, which is exactly why nobody else can read your memories. Keep a copy of the key file somewhere safe. SAIHM cannot make you another one.

Setup prints the file's location when it runs — that's the line to keep. The same key carries through if you upgrade to a paid plan: same identity, same memories, nothing migrated.

Using a second computer? Two ways:

Same memory, both machines — put your key file on the second machine, set up the config there, and say "Recall my SAIHM memories."
Work and personal kept apart — start fresh on the second machine and share across instead: "Share these notes with my work agent until 5:00 pm." A share can be revoked or given an expiry, so the two stay separate.

See it run

Live demos across every major model — offline, about a minute each, no account: https://citw2.github.io/saihm-demos/. Store a memory in Claude, GPT, DeepSeek, Qwen, Kimi, or GLM, then prove you can erase it.
Token benchmark — recalling a bounded set of memories instead of re-sending the whole conversation cut input tokens by 62.8%–85.9% across a realistic multi-session task. Open, offline, reproducible: https://github.com/citw2/saihm-token-benchmark.

What it costs

Start free. The free tier is a fixed, one-time allowance of writes, reads, and shares for trying SAIHM on real infrastructure — it doesn't reset or refill. No card, and nothing to cancel. Your assistant shows what's left and warns you as it runs low, so nothing fails by surprise.

Paid plans are monthly. Upgrading keeps the same key and every memory you already have:

SAIHM_MASTER_SECRET_FILE=$HOME/.saihm/free-identity.key \
SAIHM_TIER=FREE \
  npx -y @saihm/mcp-server-pro upgrade PRO

That prints a checkout link tied to your identity. Pay, then add two lines to your config's env block and restart:

"SAIHM_TIER": "PRO",
"SAIHM_PAYMENT_METHOD": "stripe"

Both are needed — a paid plan without SAIHM_PAYMENT_METHOD refuses to start, because that setting names which payment rail to check. stripe is one option; stablecoin is another, and your assistant can tell you what your operator accepts.

If something isn't working

What you see	Usual cause
No SAIHM tools appear, and no error anywhere	`timeout` too low — see the config above
Every other tool vanished too	A trailing comma broke the settings file
Tools appear but every call fails	`SAIHM_ENDPOINT_URL` unreachable
"no identity"	Setup hasn't run on this machine yet
A different memory than you expected	This machine has its own key rather than yours
`status` mentions `seq-state`	A small local safeguard file couldn't be read or written. Your memories are unaffected — see `SAIHM_SEQ_STATE_PATH` below

How it works

In plain terms. Everything is encrypted on your machine before it is sent, and decrypted on your machine after it comes back. What's stored is unreadable ciphertext and no key that opens it. To erase something, its key is destroyed — which is why erasure is immediate and final rather than a promise that a copy was deleted somewhere.

For the technically inclined.

Encrypt before send — remember encrypts client-side; recall decrypts client-side. Your plaintext, master secret, and key-encryption key never leave this process.
Post-quantum — ML-DSA-65 for identity and signing, ML-KEM-768 for authenticated sharing, via @saihm/client-pro.
Crypto-shred erasure — forget destroys the endpoint-side wrapped data-encryption key, rendering the cell undecryptable (GDPR Art. 17).
Standard transport — POST {method, params} with Authorization: Bearer <JWT>; the endpoint binds your tenant from the JWT. HTTPS only, with loopback http permitted for local development.
Self-onboarding — with no SAIHM_AUTH_HEADER set, the client proves control of your identity and mints its own short-lived token, refreshing transparently. You paste one config once and never re-paste a token. Cancelling a subscription stops the next refresh, so access ends naturally.

Security model

Property	Guarantee
Confidentiality vs the endpoint	The endpoint holds ciphertext, wrapped DEKs, and public keys only — no key able to decrypt.
Integrity / authenticity	Every cell is ML-DSA-65-signed over its contents, including the sequence number.
Anti-replay	The signed monotonic sequence is rejected by the endpoint if it does not strictly increase.
Tenant isolation	Your `agentIdHash` (the JWT `sub`) namespaces your state; a write whose signed identity differs from the JWT is rejected.
Authenticated sharing	Grantee public keys are pinned out-of-band and verified before any secret is bound to them; on the recipient side, `recallShared` pins the sharer's key and verifies the cell signature before returning any plaintext.
Erasure	Destroying the endpoint-side wrapped DEK crypto-shreds the cell.

Where encrypted cells are stored

This client encrypts cells and hands the ciphertext to whichever operator endpoint SAIHM_ENDPOINT_URL points at; that operator chooses and configures the durable storage behind it — typically a local IPFS / Kubo node first, then a Filecoin deep-archive provider. Storage is operator-configured by design: the protocol never locks anyone to a single provider. Running your own endpoint means provisioning that storage yourself.

Prefer not to run storage at all? The hosted operator at https://saihm.coti.global provides durable storage and is non-custodial — because this client encrypts every cell locally, the hosted operator only ever stores ciphertext and never holds a key.

Configuration

Most people need none of this: the setup above sets one variable and the rest have working defaults.

Env	Required	Meaning
`SAIHM_ENDPOINT_URL`	no	`https://…/mcp` (or `http://` for `127.0.0.1`/`localhost` only). Defaults to `https://saihm.coti.global/mcp` — set it only to reach a different operator.
`SAIHM_MASTER_SECRET_FILE`	see note	Path to a mode-600 file holding the hex master secret. The preferred way to supply a key, because it keeps the key out of a config file that may be synced or shared. Takes precedence over `SAIHM_MASTER_SECRET_HEX`.
`SAIHM_MASTER_SECRET_HEX`	see note	The master secret inline, ≥ 64 hex characters (≥ 32 bytes), high-entropy, client-held, never sent. Prefer the file form: anything inline lands in the config file itself.
`SAIHM_SELF_JOIN`	no	Controls the `saihm_join` onboarding tool — the one that answers "Join SAIHM". On by default; set to `0` to remove it and expose only the canonical eight tools.
`SAIHM_HOME`	no	Where the identity file lives (`$SAIHM_HOME/free-identity.key`, mode 600) and where per-restart bookkeeping is kept. Defaults to `~/.saihm`.
`SAIHM_AUTH_HEADER`	no	`Bearer <JWT>`, used verbatim. Omit to self-onboard (recommended) — the client mints and refreshes its own token, so there is nothing to paste or re-paste.
`SAIHM_TIER`	self-onboard only	Plan label recorded in encrypted metadata (`FREE`, `PRO`, …). Required when self-onboarding; otherwise resolved via `status()`.
`SAIHM_PAYMENT_METHOD`	paid self-onboard	Entitlement rail (`stripe`, `stablecoin`, …) for a paid plan. Not used by the free tier. Ignored when `SAIHM_AUTH_HEADER` is set.
`SAIHM_SEQ_STATE_PATH`	no	Overrides where the anti-rollback bookkeeping is written. Running as an MCP server this is on by default at `$SAIHM_HOME/seq.<id>.json`; set it only to relocate it. The default location is ours to manage: if it can't be written, the tally stays in memory for the session and `status` says so. A location you set is yours: if it can't be written, calls fail and name the path, so a safeguard you asked for never goes quiet without telling you. `status` reports this as `seq-state=…` followed by `rollback-guard=persisting` (writes still work, so the next one rewrites the file) or `memory-only-this-run` (it retries at the next restart). Either way, if the file couldn't be READ at startup the safeguard starts from scratch and rebuilds as each memory is next read — so an older copy of a memory would not be caught during that window. At the default location that window is about accidental corruption rather than an attacker: writing to that file takes the same access that reads the identity key sitting beside it. Somewhere you relocate it to, that no longer follows — give it the protection you give `$SAIHM_HOME`.
`SAIHM_STATE_DIR`	no	Where transient operator state (such as `checkout-url.txt`) is written. Does not relocate your identity or its bookkeeping.

Note: a master secret is required, from one source or the other — but setup creates and configures it for you, which is why the config above has neither.

For developers

npm install @saihm/mcp-server-pro

import { SaihmProClient } from '@saihm/mcp-server-pro';

// Boot from env: SAIHM_ENDPOINT_URL, SAIHM_MASTER_SECRET_FILE (or _HEX)
//   self-onboard (recommended): + SAIHM_PAYMENT_METHOD + SAIHM_TIER (omit SAIHM_AUTH_HEADER)
//   static token (advanced):    + SAIHM_AUTH_HEADER="Bearer <JWT>"
const saihm = SaihmProClient.bootFromEnv();

// Store — encrypted before it leaves the process.
const { cellId } = await saihm.remember('remember this');

// Recall — decrypted after it returns.
const cell = await saihm.recallOne(cellId);
console.log(cell?.plaintext); // 'remember this'

// Recall everything (client-side keyword filter; the endpoint has no plaintext to filter on).
const matches = await saihm.recall('this');

// Update an existing cell (a fresh monotonic sequence is issued automatically).
await saihm.remember('new contents', { cellId });

// Forget — crypto-shred.
await saihm.forget(cellId);

// Share a cell with another agent, end-to-end authenticated. Pin the grantee's agentIdHash
// out-of-band; the library rejects directory key-substitution.
await saihm.share({
  cellId,
  recipientRecord, // the grantee's published identity record (hex)
  recipientPinnedAgentIdHashHex, // pinned out-of-band
  expiryEpoch, // optional; omit or null for no time bound
});
await saihm.revokeShare(cellId, recipientPinnedAgentIdHashHex);

// Read a cell another agent shared TO you (the recipient side of `share`). Pin the
// sharer's agentIdHash out-of-band; the library verifies the sharer's signature and
// returns null when there is no live grant (e.g. revoked, or the sharer crypto-shredded it).
const shared = await saihm.recallShared({
  sharerPinnedAgentIdHashHex, // the sharer's agentIdHash, pinned out-of-band
  sharerRecord, // the sharer's published identity record (hex)
  cellId,
});
console.log(shared?.plaintext);

// Operator-observable metadata only (no plaintext).
const status = await saihm.status();

The derived saihm.agentIdHash is the sub the endpoint binds your tenant to — when self-onboarding the client proves it via ML-DSA; with a static SAIHM_AUTH_HEADER it must equal the JWT sub. Publish saihm.identityRecord so other agents can share to you.

Constructing SaihmProClient directly writes nothing to your home directory; the per-restart bookkeeping is opted into by the MCP server's boot path, or by setting SAIHM_SEQ_STATE_PATH explicitly.

Errors. Non-2xx responses throw SaihmEndpointError carrying status and a typed code (e.g. BLIND_BAD_EXPIRY, BLIND_STALE_SEQ, governance_unavailable). Branch on the code rather than the message.

License

Apache-2.0 © SAIHM

Available Tools

9 tools

saihm_forgetForget (GDPR erasure)A

DestructiveIdempotent

Cryptographically erase one memory by its cell id (GDPR Art. 17). Destroying the wrapped key leaves the content unreadable to everyone, the operator included. Irreversible: use it when erasure is the intent, not to tidy a working set.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Memory cell id (hex) to erase

TDQS

A4.5/5.0

Behavior5/5

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

Adds significant behavioral detail beyond the destructiveHint annotation: the key destruction makes content unreadable even to the operator, and the operation is irreversible. This fully informs the agent of consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three short sentences each carry unique information: the action, the cryptographic consequence, and the usage caveat. No filler or repetition of schema details.

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

Completeness5/5

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

For a one-parameter destructive tool with no output schema, the description fully covers what it does, why it is irreversible, and when to invoke it. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already describes the single parameter as 'Memory cell id (hex) to erase.' The description echoes 'cell id' without adding format, source, or validation details, so baseline 3 is appropriate.

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 ('cryptographically erase'), a specific resource ('one memory by its cell id'), and legal context (GDPR Art. 17). Clearly distinguishes from sibling tools that remember, recall, share, or revoke.

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?

Explicitly says to use it only when erasure is intended and not 'to tidy a working set,' which guides when NOT to use it. It does not name a specific alternative like saihm_revoke_share, but the exclusion is actionable enough.

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

saihm_governance_proposePropose (governance)A

Open a protocol governance proposal: set scope to 'emission_param' or 'protocol_upgrade', and for 'emission_param' also pass paramKey and proposedValue. Protocol governance is not enabled for this client yet — the tool is present so the surface stays stable, and calling it returns a 'governance unavailable' error rather than opening a vote.

ParametersJSON Schema

Name	Required	Description
`scope`	Yes	Governable scope
`paramKey`	No	Parameter key (when scope=emission_param)
`proposedValue`	No	Proposed value as string

TDQS

A4.9/5.0

Behavior5/5

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

Annotations indicate it is not read-only (readOnlyHint=false), but the description adds crucial behavior: the tool is a stub and will return a 'governance unavailable' error. This goes beyond the annotations and sets correct expectations for the agent's action. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two compact sentences front-load the main purpose and conditional parameters, then immediately note the limitation. No wasted words, and the critical caveat is placed at the end without obscuring the primary intent.

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

Completeness5/5

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

Given the tool's conditional parameters and non-functional status, the description covers every piece an agent needs: which scope is required, what extra parameters are needed for each scope, and the exact failure behavior. It is complete and self-contained.

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% and paramKey's schema description already mentions 'when scope=emission_param'. However, the description also clarifies that proposedValue is also conditional on emission_param, which the schema does not explicitly state. This adds meaningful conditional logic beyond what is in the schema.

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 ('open') and a clear resource ('protocol governance proposal'), and distinguishes its function from the sibling vote tool. It explicitly states the two scopes and the conditional parameters, and even clarifies the current non-functional state, so an agent knows exactly what the tool is meant to do.

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 instructions: set scope to 'emission_param' or 'protocol_upgrade' and, for 'emission_param', also pass paramKey and proposedValue. It also explicitly warns the tool is not enabled and will return an error, effectively telling the agent not to rely on it. This is clear and complete.

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

saihm_governance_voteVote (governance)A

Cast a vote on an open protocol governance proposal by its proposalId, with approve set to true to approve or false to reject. Protocol governance is not enabled for this client yet — the tool is present so the surface stays stable, and calling it returns a 'governance unavailable' error rather than recording a vote.

ParametersJSON Schema

Name	Required	Description	Default
`approve`	Yes	true = approve, false = reject
`proposalId`	Yes	Hex proposalId

TDQS

A4.5/5.0

Behavior5/5

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

Discloses a critical behavioral trait beyond annotations: despite appearing write-oriented, the tool is stubbed and returns a 'governance unavailable' error without recording a vote. This adds important context beyond the readOnly/idempotent/destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences with no fluff. The primary action is stated first, and the critical unavailable-error behavior is front-loaded in the second sentence before any unnecessary detail.

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

Completeness5/5

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

For a simple two-parameter tool with full schema coverage, the description fully covers invocation, parameter semantics, and the actual behavioral outcome. No output schema exists, but the description explicitly discloses the error response, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, with both proposalId and approve documented. The description restates the approve true/false semantics and ties the action to proposalId, but adds little beyond what the schema already provides.

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: cast a vote on an open protocol governance proposal by proposalId. It clearly differentiates the voting action from the sibling propose tool and explains the approve semantics.

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?

Clearly indicates that casting a vote is the intended action and that governance is not enabled, so calling the tool will return an error rather than succeed. It does not explicitly name alternatives, but the purpose and current non-functional status make appropriate usage unambiguous.

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

saihm_joinJoin SAIHM (activate free memory)A

Activate free SAIHM persistent memory for this agent. Call this when the user asks to join, sign up for, or set up SAIHM. It self-generates a sovereign memory key on this device and starts a one-time human approval — the tool returns a URL and short code for the user to open and enter. After the user approves, call saihm_join again to finish; the memory tools then work. No payment and no website visit.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations: it explains the two-step process with human approval, generation of a sovereign key, and the return of a URL/code. This complements the openWorldHint and idempotentFalse annotations. However, it does not mention potential side effects (e.g., calling again after joining), though that is minor given the setup nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is four sentences long, front-loading the core action. Every sentence adds value: function, when to call, step-by-step process, and a note about no payment. It is well-structured and free of fluff.

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?

Given no output schema and no parameters, the description covers the activation process completely: triggers, human approval, return value, and post-approval steps. It could mention error states (e.g., if approval fails), but overall it is sufficiently complete for agent use.

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?

The input schema has zero parameters and schema coverage is 100%, so the description does not need to add parameter info. According to guidelines, 0 parameters yields a baseline of 4, which is appropriate here as there is no missing information.

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 clearly states the tool's purpose: 'Activate free SAIHM persistent memory for this agent.' It uses a specific verb ('Activate'/'Join') and resource ('SAIHM persistent memory'), and the context of sibling tools (e.g., saihm_remember, saihm_forget) distinguishes this as the setup/join tool, making it unambiguous.

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?

The description explicitly says 'Call this when the user asks to join, sign up for, or set up SAIHM,' providing clear when-to-use guidance. It also outlines a two-step process (call first, then after approval call again). It does not explicitly state when not to use (e.g., if already joined), but the scenario is well-defined and distinct from siblings.

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

saihm_recallRecallA

Read-onlyIdempotent

Retrieve your memories from SAIHM and decrypt them in this process; the server never sees plaintext. Use this at the start of a session, or whenever past context is needed. Pass query to filter by keyword, or leave it out to load everything. To read a single cell another agent shared with you, pass their sharerPinnedAgentIdHashHex and sharerRecord together with the cellId; that path is read-only.

ParametersJSON Schema

Name	Required	Description
`query`	No	Filter your OWN memories by keyword (empty = all). Ignored when reading a shared cell.
`cellId`	No	The shared cell id to read. Required when reading a shared cell.
`sharerRecord`	No	The SHARER's published identity record (hex fields). Required with sharerPinnedAgentIdHashHex.
`sharerPinnedAgentIdHashHex`	No	Read a cell shared TO you: the SHARER's agentIdHash (hex), pinned out-of-band. When set, sharerRecord and cellId are also required.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`shared`	Yes
`memories`	Yes
`sharedTruncated`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: decryption happens locally ('the server never sees plaintext'), query is ignored when reading a shared cell, and the shared-cell path is explicitly read-only. These details meaningfully inform an agent's expectations without contradicting 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.

Conciseness5/5

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

The description is three sentences with no filler: core purpose and privacy are front-loaded, followed by usage timing, then parameter guidance. Every sentence earns its place and the structure mirrors an agent's likely decision flow.

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

Completeness5/5

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

Given four parameters, a nested sharerRecord, and the presence of an output schema, the description covers both invocation modes, the parameter relationships, and the privacy-sensitive decryption behavior. No critical operational detail is missing; safety is already covered by annotations and return content by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% and the baseline is 3, the description enriches parameter meaning substantially. It explains that query filters by keyword, empty means all, and is ignored in shared-cell mode. It also ties sharerPinnedAgentIdHashHex, sharerRecord, and cellId together as a coherent shared-read path, which the schema alone does not make explicit.

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 'Retrieve your memories from SAIHM and decrypt them,' naming the verb and resource with precision. It distinguishes itself from siblings like saihm_remember and saihm_forget by focusing on retrieval, and it explicitly describes two operating modes (filtered recall of own memories and reading a shared cell), so an agent can clearly understand what the tool does.

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?

The description provides clear context: 'Use this at the start of a session, or whenever past context is needed.' It also explains when to pass or omit query and how the shared-cell path works. However, it does not explicitly name sibling alternatives to avoid (e.g., saihm_remember for writes), so it falls just short of full alternative-based guidance.

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

saihm_rememberRememberA

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. Returns the cell id that saihm_forget takes.

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
`seq`	Yes
`cellId`	Yes
`shardId`	Yes
`commitmentHash`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses a significant behavioral trait: encryption happens in the process, the key never leaves it, and the server only holds unreadable ciphertext. It also explains that the returned cell id is the one saihm_forget consumes, which is useful operational context. No contradiction with the readOnlyHint=false, destructiveHint=false annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is compact: it leads with the core purpose, adds the security-critical encryption detail, states the primary usage trigger, explains cell update behavior, and closes with the return-value relationship. Every sentence earns its place with no redundant filler.

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

Completeness5/5

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

For a two-parameter tool with an output schema and annotations, the description is complete. It covers when to use, how to update, the security boundary, and what the caller receives. Missing details like storage limits or beyond-session semantics are not necessary for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 enriches 'content' as fact/decision/context and clarifies the cellId update-vs-create behavior, but these mostly restate or lightly extend the schema rather than adding substantial new meaning.

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 create from update behavior, and even ties the return value to the saihm_forget tool, making its role among sibling tools unambiguous.

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?

The description states when to use the tool: when a fact, decision, or piece of context should outlive the current session. It also gives concrete guidance for updating an existing cell by passing a cellId. It does not explicitly list when not to use sibling tools like recall or forget, but the usage context is clear enough.

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

saihm_revoke_shareRevoke shareA

Idempotent

Withdraw a grant made with saihm_share, naming the same cellId and the recipient's recipientHex. It applies to future reads and cannot retract what the recipient has already read. Use it to end access; the memory itself remains, and saihm_forget is what erases.

ParametersJSON Schema

Name	Required	Description	Default
`cellId`	Yes	The shared cell id
`recipientHex`	Yes	The grantee's agentIdHash (hex) to revoke

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description adds the critical limitation 'It applies to future reads and cannot retract what the recipient has already read' and clarifies that the memory itself survives. These details meaningfully shape an agent's expectations about side effects and are not present in the schema or annotations. There is no contradiction with 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.

Conciseness5/5

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

Three sentences with zero filler: the first states the operation, the second discloses the main behavioral caveat, and the third gives the usage alternative. The key action is front-loaded.

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

Completeness5/5

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

For a two-parameter tool with no output schema and no nested objects, this description covers the operation, the exact parameter relationship, the temporal limitation, and the sibling tool to use instead. Nothing an agent needs to invoke it correctly is missing.

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. The description adds relational meaning by instructing the caller to reuse the same cellId and recipientHex from the original saihm_share call, which is not explicitly stated in the schema descriptions. This small but valuable addition justifies a 4.

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 states a specific verb and resource: 'Withdraw a grant made with saihm_share'. It clearly differentiates itself from saihm_forget by noting 'the memory itself remains, and saihm_forget is what erases', so an agent can distinguish revoking access from erasing memory without opening schemas.

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 an explicit when-to-use instruction: 'Use it to end access'. It also names the alternative saihm_forget and the condition for erasure, and it tells the agent to name 'the same cellId and the recipient's recipientHex', tying usage to the original grant.

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

saihm_shareShareA

Grant one other agent access to a single memory cell, named by cellId. Identify the recipient by their recipientPinnedAgentIdHashHex, pinned out-of-band, and their recipientRecord. Set scope to 'read', 'write' or 'readwrite'. Only that one cell is exposed, and sharing re-wraps its key rather than copying the memory.

ParametersJSON Schema

Name	Required	Description
`scope`	No	Access scope (default read)
`cellId`	Yes	The cell to share
`expiryEpoch`	No	Optional expiry as a UNIX-epoch count (decimal string)
`recipientRecord`	Yes	The grantee's published identity record (hex fields)
`recipientPinnedAgentIdHashHex`	Yes	The grantee's agentIdHash (hex), pinned out-of-band

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already signal a mutating, non-destructive, open-world operation. The description adds useful behavioral detail beyond the annotations: 'Only that one cell is exposed' and 'sharing re-wraps its key rather than copying the memory.' There is no contradiction with 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?

The description is front-loaded with the core action and is reasonably compact. Each clause adds relevant detail, though some restatement of schema fields such as scope values and recipient identifiers makes it slightly less tight than it could be.

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 mutating share operation with five parameters and no output schema, the description covers recipient identity requirements, scope choices, the single-cell scope, and the key-rewrap side effect. The schema covers expiry. It lacks explicit alternative routing and response/error behavior, but the essentials for a correct call are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description mostly restates schema facts such as the recipient being pinned out-of-band and the scope enum values, rather than adding new parameter-level meaning. It does not materially extend the schema's parameter documentation.

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 names a specific verb and resource: 'Grant one other agent access to a single memory cell, named by cellId.' It also clarifies recipient identification and scope values. It does not explicitly distinguish itself from sibling tools like saihm_revoke_share, but the grant-vs-revoke action is sufficiently clear.

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

Usage Guidelines3/5

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

The description clearly conveys the mechanics of sharing and how to identify the recipient, but it does not state when to use this tool over alternatives such as saihm_revoke_share, saihm_remember, or saihm_recall. Usage context is implied rather than explicitly framed.

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

saihm_statusStatusA

Read-onlyIdempotent

Show the current SAIHM session: the agent identity, which this client derives locally, plus the tier, custody mode, shard and sharing counts, and bfsi score the server reports. No plaintext appears, because the server holds none. Use it to check which identity is active and what is stored and shared.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`bfsi`	Yes
`tier`	Yes
`custody`	Yes
`agentIdHash`	Yes
`snapshotEpoch`	Yes
`activeShardCount`	Yes
`seqStateDegraded`	Yes
`activeSharingContracts`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond that: no plaintext is returned because the server holds none, and it clarifies that the identity is derived locally while counts/tier/bfsi come from the server. This helps an agent predict response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences with no filler. The primary action and result are front-loaded, and the follow-up sentences add only essential behavioral and usage context.

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

Completeness5/5

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

For a zero-parameter, read-only status tool with a rich annotation set and an output schema, the description covers everything an agent needs: what is shown, what is safe, and why no plaintext appears. Nothing meaningful is missing.

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?

The tool has zero parameters, so the schema already fully covers them (100% coverage). The description needs to do no parameter work, making the baseline 4 appropriate.

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 states a specific verb ('Show') and a well-defined resource ('current SAIHM session'), then enumerates the exact contents: agent identity, tier, custody mode, shard and sharing counts, and bfsi score. This clearly distinguishes it from the mutation-focused sibling tools (join, share, forget, recall, vote).

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?

The description explicitly says 'Use it to check which identity is active and what is stored and shared,' which gives clear context for when this tool is appropriate. It does not explicitly name alternatives or exclusions, but among siblings that all perform actions, the read-only status role is unambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.2.2Aug 31, 2026

Changedsaihm_recall3 fields changed

addedOutput schema / properties / shared

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "cellId": {
+        "type": "string"
+      },
+      "expiryEpoch": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "scope": {
+        "type": "string"
+      },
+      "sharer": {
+        "type": "string"
+      },
+      "verified": {
+        "const": false,
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "sharer",
+      "cellId",
+      "scope",
+      "expiryEpoch",
+      "verified"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / sharedTruncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "count",
-  "memories"
-]New value: +[
+  "count",
+  "memories",
+  "shared",
+  "sharedTruncated"
+]

Changedsaihm_status5 fields changed

changedOutput schema / properties / activeShardCount / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / activeSharingContracts / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / bfsi / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

addedOutput schema / properties / seqStateDegraded

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

changedOutput schema / required

Previous value: -[
-  "agentIdHash",
-  "tier",
-  "custody",
-  "activeShardCount",
-  "activeSharingContracts",
-  "bfsi",
-  "snapshotEpoch"
-]New value: +[
+  "agentIdHash",
+  "tier",
+  "custody",
+  "activeShardCount",
+  "activeSharingContracts",
+  "bfsi",
+  "snapshotEpoch",
+  "seqStateDegraded"
+]

9 tool updatesv0.2.1Jul 29, 2026
- First observedsaihm_forget
- First observedsaihm_governance_propose
- First observedsaihm_governance_vote
- First observedsaihm_join
- First observedsaihm_recall
- First observedsaihm_remember
- First observedsaihm_revoke_share
- First observedsaihm_share
- First observedsaihm_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: join, remember, recall, forget, status, share, revoke_share, and the two governance actions. Even the governance pair is unambiguous because one proposes and one votes, and the descriptions explicitly call out their placeholder status.

Naming Consistency5/5

All tool names follow the same lowercase snake_case convention with a consistent saihm_ prefix and a verb-driven pattern. The governance tools add a subdomain qualifier (saihm_governance_vote/propose) without breaking the overall naming scheme.

Tool Count5/5

Nine tools is a well-scoped surface for a persistent memory server with sharing and governance concerns. Each tool covers a distinct operation, and the count is neither bloated nor too thin.

Completeness4/5

The core memory lifecycle is complete: create/update via saihm_remember, read via saihm_recall, delete via saihm_forget, plus session status and sharing/revocation. The only notable gap is that the governance tools are explicitly unavailable stubs, so that portion of the surface is not actually functional yet.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Tempreon — Personal AI Memory
com.tempreon
Person-owned AI memory that learns, not just stores — portable context for any MCP client.
Knowledge & Memory Autonomous Agents
2
Living Memory
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
JustOnce
ai.justonce
Persistent memory for AI assistants — one shared, OAuth-secured vault for every MCP client.
Knowledge & Memory Security
1
BrainboxOAuth
dev.thexi
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Knowledge & Memory AI & Machine Learning
2

Related MCP Servers

pce-memory
Knowledge & Memory RAG Systems
CAPHTECH
A
license
Not graded
quality
C
maintenance
MCP server for context-aware memory and retrieval with hybrid search, dual-phase memory, and boundary-first security.
Updated 5 months ago (2026-04-01 03:09 UTC)
3
MIT
Hippocampus
Knowledge & Memory Search
karrolcia
A
license
Not graded
quality
A
maintenance
Open-source MCP memory server providing persistent, cross-platform context for AI tools via a knowledge graph with encrypted storage.
Updated 3 days ago (2026-09-03 02:37 UTC)
4
13
AGPL 3.0
Engram
Knowledge & Memory Search
Kalyan-Deva
A
license
Not graded
quality
B
maintenance
A local-first memory MCP server that enables storing, searching, and managing personal memories with hybrid keyword and semantic recall, all on-device.
Updated 3 months ago (2026-06-20 05:15 UTC)
21
MIT
Universal Memory MCP Server
Knowledge & Memory Autonomous Agents AI & Machine Learning
DevMinions
A
license
Not graded
quality
D
maintenance
A portable MCP server providing a shared intelligent memory system for any MCP-compatible AI tool, enabling storage, retrieval, extraction, and governance of memories across sessions.
Updated 5 months ago (2026-03-30 07:00 UTC)
10
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SAIHM-Admin/saihm-mcp-server-pro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server