Skip to main content
Glama
SAIHM-Admin

saihm-mcp-server (standards client)

by SAIHM-Admin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

SAIHM MCP Server

The standards client for your own custodial SAIHM operator. It carries no cryptography of its own and expects an operator endpoint URL plus an operator token. If you just want memory working, free, in about a minute, use @saihm/mcp-server-pro and ask your agent to "Join SAIHM".

npm version OpenSSF Best Practices · Apache-2.0

New to SAIHM? Watch the 6-minute overview (captions and transcript), or read the SAIHM manual (PDF).

This package is the standards client: eight memory tools any MCP agent — Claude Code, Claude Desktop, Cursor, or your own — can call. It carries no cryptography of its own. It speaks the publicly documented SAIHM memory protocol over plain MCP and reaches whichever SAIHM operator you point it at.

Which package do I want?

  • You run, or subscribe to, your own SAIHM operator — this one. Being crypto-free and dependency-light is the point: it drops into a custodial operator that performs the cryptography server-side. → Install · Configure

  • You just want memory working, free, in about a minute — use @saihm/mcp-server-pro and ask your agent to "Join SAIHM". It seals cells on your own machine, so it can use the hosted non-custodial service — which this crypto-free package cannot. No card. → Free trial

Want to watch it work first? Runnable demos across every major model, offline, no account — See it run.

What this is

A Model Context Protocol server that exposes eight tools any MCP-capable AI agent (Claude Code, Claude Desktop, custom agents) can call to gain a persistent, encrypted memory layer the user owns:

  • saihm_remember — store an encrypted memory cell

  • saihm_recall — retrieve and decrypt your memories

  • saihm_forget — true cryptographic erasure (GDPR Art. 17)

  • saihm_status — your protocol-runtime stats and storage tier dashboard

  • saihm_share / saihm_revoke_share — selectively share a memory with another agent or user

  • saihm_governance_propose / saihm_governance_vote — protocol governance; not enabled by default, so expect an error unless your operator has turned it on

Each tool forwards to a SAIHM operator endpoint that runs the full protocol stack on COTI V2 mainnet. The server itself holds no crypto, no storage, and no protocol runtime — those live behind the operator endpoint.

Related MCP server: SharedContext

Tool reference

Tool

Title

Behavior

saihm_remember

Remember

writes a new memory cell

saihm_recall

Recall

read-only; safe to repeat

saihm_forget

Forget (GDPR erasure)

destructive — irreversible erasure

saihm_status

Status

read-only

saihm_share

Share

writes a sharing contract

saihm_revoke_share

Revoke share

withdraws a grant

saihm_governance_propose

Propose (governance)

forwards a proposal; not enabled by default

saihm_governance_vote

Vote (governance)

forwards a vote; not enabled by default

Each tool carries MCP annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and a human-readable title, so MCP hosts can gate confirmations and agents can select the right tool at reasoning time.

Companion package

This package speaks MCP and holds no cryptography, so it always needs an operator endpoint and token. Two companions cover the rest:

  • @saihm/mcp-server-pro — a drop-in MCP server that performs the client-side cryptography itself and can self-onboard, including the free tier. This is the package to use if you have no endpoint yet — see Free trial.

  • @saihm/client-pro — the same client-side cryptography as a library, for embedding in your own application: post-quantum sealing, authenticated sharing, and provable erasure performed on your own machine so the operator stays blind.

See it run

Runnable, one-command demos ground a memory you own in every major model — Claude, GPT, DeepSeek, Qwen, Kimi, GLM — then prove you can erase it, alongside drop-in adapters for LangChain, LlamaIndex, CrewAI, AutoGen, and LangGraph. Each runs offline in about a minute; no account needed.

Measured — up to ~86% fewer context tokens. Most agents re-send their entire transcript every turn, so context spend grows ~O(N²) over a session; recalling a bounded set of memory cells instead cut input tokens by 62.8%–85.9% across a realistic multi-session coding task. The benchmark is open, offline, and deterministic — reproduce the number rather than trust it:

git clone https://github.com/citw2/saihm-token-benchmark
cd saihm-token-benchmark && npm install && node benchmark.mjs

Install

npm install @saihm/mcp-server
# or run directly without install:
npx @saihm/mcp-server

Configure

The server needs two env vars:

SAIHM_ENDPOINT_URL=https://operator.example.com/mcp
SAIHM_AUTH_HEADER=Bearer <token-issued-by-your-operator>

Don't have an endpoint and token yet? They're issued by a SAIHM operator. This package is deliberately crypto-free, so it needs a custodial operator — one that performs cryptography server-side and returns plaintext.

The hosted SAIHM service at https://saihm.net is not one. It is non-custodial by design: it stores only ciphertext and never holds your keys, so cells sealed there can only be opened by a client that holds them. To use the hosted service — including the free trial (sign in with GitHub, no card) — use @saihm/mcp-server-pro, which seals and opens on your own machine. See Free trial and Join SAIHM below.

Use this package against a custodial operator you run or subscribe to. Until one is configured, the tools have nowhere to reach and will return an error.

  • SAIHM_ENDPOINT_URL — the endpoint of the custodial SAIHM operator you run or subscribe to. Not the hosted service at https://saihm.net, which is non-custodial — see the note above.

  • SAIHM_AUTH_HEADER — the Authorization header value the operator expects (typically a Bearer <token> issued to you after key-bound enrolment). The server is authentication-agnostic and never transmits raw private keys; the operator's enrolment flow keeps your signing key on your machine.

Both are read from the process environment. This package loads no .env file — it has no dotenv dependency and never reads configuration from disk — so set them in the env block of your MCP host's server configuration, or export them in the shell that launches the server. If you keep them in a .env for your own convenience, source it yourself before launching, and keep it out of version control.

Free trial (sign in with GitHub)

Want to test SAIHM on real infrastructure before you pay? Start a free trial — for testing purposes, no card — by proving you're a unique person once through a GitHub device sign-in. It runs through the non-custodial @saihm/mcp-server-pro client, which seals cells on your own machine so the operator stays blind.

First generate your master secret — it never leaves your machine, and it is the only key to your memory:

openssl rand -hex 32 > saihm-master.key && chmod 600 saihm-master.key

Then activate:

SAIHM_ENDPOINT_URL=https://saihm.net/mcp \
SAIHM_MASTER_SECRET_FILE=./saihm-master.key \
SAIHM_TIER=FREE \
  npx -y @saihm/mcp-server-pro free-join

It prints a short code and a link: open https://github.com/login/device in your browser and enter the code. The sign-in stays in your browser — this client never sees or holds your GitHub token; it is exchanged server-side and kept ephemeral. When free-join returns, start the server normally (drop free-join) and it self-onboards on the free trial. No card, and nothing to cancel — it's a fixed, one-time allowance, not an auto-renewing subscription.

Ready for production? Upgrade in place to a monthly plan — same signing key, same memories, no re-onboarding.

What success looks like

Wiring the server in is not the same as using it. The moment that matters is the first recall that returns something — before that you have an empty store and an agent with no particular reason to reach for it.

Here is the whole product in miniature. Once the server is wired in (next section) and your host has restarted, say this to your agent, in two separate turns:

Remember that I take my coffee black, and that I'm building a Rust CLI called ferry.

...then, in a new turn:

What do you know about me?

The second turn should come back with both facts. It never saw the first turn — the memory is what carried them across. Check that round trip before you build anything on top of it.

If the recall comes back empty, it is nearly always one of these:

what you see

cause

fix

no SAIHM tools offered at all

the host never started the server

keep timeout in the JSON below, then restart the host

tools offered, but the agent never calls them

it has no standing instruction to

see Tell your agent to use it below — this is the common one

recall runs but comes back empty

nothing was stored on the first turn

ask for saihm_remember by name, then recall again

401 or 403, and your endpoint is saihm.net or saihm.coti.global

that service is non-custodial — this client cannot read it

use @saihm/mcp-server-pro instead; see the free trial above

401 or 403 from your own operator

no valid token

re-issue it with that operator

could not reach ...

endpoint wrong or unreachable

check SAIHM_ENDPOINT_URL; the message names the cause

Wire into Claude Code

{
  "mcpServers": {
    "saihm": {
      "command": "npx",
      "args": ["@saihm/mcp-server"],
      "env": {
        "SAIHM_ENDPOINT_URL": "https://operator.example.com/mcp",
        "SAIHM_AUTH_HEADER": "Bearer <token>"
      },
      "timeout": 60
    }
  }
}

Keep timeout, and keep the block as strict JSON with no trailing commas. Hosts that don't recognise timeout ignore it, but Cline allows a server only 1.5 s to start — too short for npx to resolve and launch a package — and a server that misses the deadline is skipped silently, with no error in the chat.

Tell your agent to use it

Wiring the server in makes the tools available; it does not make an agent reach for them. Say this once, and keep it in whatever persistent instructions your agent already reads:

Liberally use SAIHM protocol to maximize token economy. Use my SAIHM memory from now on. At the start of each session, recall what you already know about me. When I tell you something worth keeping — my preferences, decisions, or ongoing projects — remember it. To confirm it works right now: remember that I wired up SAIHM today, then recall it back to me.

Hosts that support MCP prompts can load the same rules on demand instead of pasting them: the server ships a saihm_session_bootstrap prompt carrying the full store, recall, share and erase guidance, fetched only when it is asked for rather than on every session.

Why this is the token-economical setting. Advertising the tools costs a fixed amount once per session, whether or not the agent uses them. Recall is what earns it back: one saihm_recall that replaces re-explaining your project, your preferences or last week's decisions saves more than the advertisement costs, and the saving compounds the longer the session runs and the more sessions you keep. An agent that never calls the tools pays the cost and collects none of the return — which is why the instruction above is worth setting explicitly rather than hoping the agent infers it.

What gets persisted, where

The server itself persists nothing. The operator endpoint runs the full protocol stack: cells are encrypted under a per-cell DEK, sealed by a per-agent KEK, persisted to the operator's configured durable storage, and audited on COTI V2 mainnet. See the operator's documentation for tier details, and Storage is the operator's responsibility (by design) below.

Storage is the operator's responsibility (by design)

For operators — read this first. SAIHM does not hard-wire your durable storage to any single provider, and it does not silently provision storage for you. Choosing and configuring where cells are persisted is your job, on purpose. This is a deliberate design choice for operator convenience and data sovereignty — not a missing feature. If memory writes fail with a storage error, it almost always means the backend has not been configured yet.

Why it works this way:

  • Provider sovereignty. You decide where your tenants' encrypted cells live. The protocol never locks you to one vendor or one network.

  • Local-first, then deep-archive. A typical operator routes writes to a local IPFS (Kubo) node first — fast, authoritative, and under your own control — and then asynchronously to a Filecoin deep-archive provider such as Pinata, Synapse, or Lighthouse. The same content addressing spans both tiers.

  • Your memory and your tenants' take the same path. Whatever backend you configure serves both the operator's own memory and every tenant's — there is no separate hidden sink hard-coded to one provider.

What you configure (your operator deployment guide lists the exact settings):

  • a reachable IPFS / Kubo endpoint (a local node is recommended) for the authoritative low-latency tier, and

  • credentials for at least one Filecoin / IPFS pinning provider for durable deep-archive.

If neither is configured, the endpoint has nowhere durable to put cells and will reject writes rather than lose data. That refusal is intentional.

Prefer not to run storage yourself? Join SAIHM.

You have two paths, and either is fine:

  1. Run your own operator endpoint and configure the storage backend as described above — full sovereignty, your infrastructure.

  2. Join the hosted SAIHM operator and let it provide durable storage for you. It runs blind / non-custodial: paired with client-side sealing (see @saihm/client-pro and @saihm/mcp-server-pro), it only ever stores ciphertext and never holds your keys — so you get managed storage without giving up custody. Enrol via Join SAIHM at https://saihm.net (a paid hosted service).

Reporting engine

A reporting library is bundled as a sub-export, so operators can compose the eight MCP calls into bespoke reports with their own tooling (no extra dependency, no extra service):

import {
  validateBespokeTemplate,
  registerTemplate,
  generateRegistryAttestation,
  StubPublicRegistry,
  InMemoryReportingRuntime,
  GDPR_ART15_FIELDS,
  REGISTRY_ATTESTATION_FIELDS,
  type BespokeReportTemplate,
} from "@saihm/mcp-server/reporting";

The package is ESM-only — "type": "module", and the exports map declares an import condition with no require one. From a CommonJS project require("@saihm/mcp-server/reporting") therefore fails with ERR_PACKAGE_PATH_NOT_EXPORTED, which reads as though the sub-export does not exist; it does, and the module system is the reason. Both entry points behave this way — the root and /reporting alike. A newer Node does not help: current Node 20.x can require() an ES module, but that only takes effect once a require condition matches, and this package declares none, so the failure is the same on every supported version. Use import, or load it from CJS with a dynamic await import().

What it covers

  • Field universe (FIELD_UNIVERSE) — 280 fields (262 framework + 18 ledger). Templates that project a field outside this set are rejected at validation. Check the split before you plan against the count: the 12 GDPR Art.15, 11 GDPR Art.17 and 18 ledger fields are verbatim canonical names with sub-clause citations, and the other 239 — SOC 2 Type 1 and 2, ISO 27001, and all four AML sub-prefixes — are deterministic structural placeholders (iso27001_F01, aml_ctr_item_01, and so on) that you map to your own canonical names. They are enforced projection slots, not a regulatory enumeration, so selecting iso27001 gets you 31 validated slots rather than 31 named ISO 27001 fields. Replacing them with verbatim names against the primary sources is future work.

  • Bespoke template schema — zod validator + universe-membership check + scope/cap enforcement.

  • Authorization path validators — 4 paths: public / self / operator-self / operator-for-downstream. These check structure — shape, hex formats, replay windows, kind-vs-auth coupling. Signature verification is done by callbacks you inject; see Wiring signature verifiers before using them to gate anything.

  • Receipt emission — 6 sub-kinds (report_generated / report_rejected / template_registered / template_superseded / erasure_chain_broken / rate_limit_exceeded) under a stable, domain-separated receipt namespace.

  • Framework smoke — registry-attestation (public auth) for end-to-end plumbing verification.

Constraints

  • Every fieldProjections[] entry MUST be in FIELD_UNIVERSE.

  • scope.customerIdHashes 64-hex; max 10,000 per template.

  • scope.timeRange window ≤ 366 days.

  • fieldProjections length 1–200.

  • framework ∈ {gdpr-art-15, gdpr-art-17, soc2-t1, soc2-t2, iso27001, aml, audit-export, billing-history, registry-attestation}.

  • format ∈ {pdfa3, json, csv}.

Worked example

const template: BespokeReportTemplate = {
  templateId: "acme-q1-summary",
  templateVersion: 1,
  operatorIdHash: "ab".repeat(32),
  scope: {
    customerIdHashes: ["cd".repeat(32)],
    timeRange: { from: "2026-01-01T00:00:00Z", to: "2026-04-01T00:00:00Z" },
  },
  framework: "gdpr-art-15",
  fieldProjections: [GDPR_ART15_FIELDS[0], GDPR_ART15_FIELDS[1]],
  format: "pdfa3",
};
const v = validateBespokeTemplate(template);
if (!v.valid) throw new Error(v.errors.join(", "));

const runtime = new InMemoryReportingRuntime(); // replace with your audit-ledger runtime
const reg = await registerTemplate(template, runtime);
if (reg.ok) console.log("registered:", reg.templateHash);

In production, replace InMemoryReportingRuntime with a runtime that persists audit payloads to your operator's audit ledger.

Wiring signature verifiers

The validators do not verify signatures themselves. Cryptography is injected, so the package can stay EVM-free and let you choose your own libraries — but that means the default posture is deliberate and must not be mistaken for enforcement:

  • With no verifier wired, the validators are shape-only. They check structure and return ok: true without any signature having been checked. This is a legitimate smoke-test posture; it is not authorization. Do not gate a disclosure on a validator result until you have injected verifiers.

  • Unverified results say so — with one of three markers. A path that returns ok: true without a signature having been checked appends a marker to its chainSummary, which generateRegistryAttestation copies into the receipt as authChainSummary, so a smoke run stays distinguishable from a verified disclosure after the fact. self and operator-self append /UNVERIFIED-shape-only; operator-for-downstream reports its two halves separately as /operator-sig-unverified and /customer-sig-unverified. Audit with the exported chainSummaryIsUnverified() rather than matching a substring by hand — a case-sensitive substring test for the upper-case marker matches only the first of the three and reads a wholly unverified downstream disclosure as verified.

  • Once you wire any verifier, every path that cannot be covered is refused. Wiring any one of the three callbacks is what distinguishes a live deployment from a smoke run, so from that point on a path whose own verifier is missing is rejected instead of returned as shape-only. On self the caller supplies surface and surface selects the verifier (web → verifyEip712, mcp → verifyMlDsa), so wiring only one means a request naming the other surface is refused — otherwise the caller could pick the surface you left unwired and skip verification entirely. operator-self and the operator half of operator-for-downstream both require verifyMlDsa on the same terms: wire verifyEip712 alone and every operator-path request is refused rather than authorized unchecked. The one deliberate exception is the customer half of a customer-grant, which stays a marker rather than a refusal because grants may be authenticated out of band — see verifyCustomerGrant, and expect /customer-sig-unverified in the chainSummary when you leave it undefined.

  • Sign the same bytes this package verifies. selfChallengeMessage, operatorSelfChallengeMessage, operatorDownstreamMessage and customerGrantMessage are exported for exactly this: each path is domain-tagged, and a signature over anything else will not verify.

Use pure-crypto libraries for the verifiers (@noble/curves for EIP-712, @noble/post-quantum for FIPS 204 ML-DSA) — the package itself bundles no EVM tooling.

const verifiers: AuthVerifiers = {
  verifyMlDsa: async (signature, message, publicKeyHash) => {
    /* your FIPS 204 verify over exactly `message` */
  },
};
const result = await validateAuthForKind("audit-export", auth, verifiers);
if (!result.ok) throw new Error(result.reason);
if (chainSummaryIsUnverified(result.chainSummary)) throw new Error("not actually verified");

Security

The server enforces a small set of defaults so misconfiguration cannot leak the Authorization header in transit:

  • HTTPS-only endpoints, held across the whole call. SAIHM_ENDPOINT_URL must use https://. Plain http:// is rejected at construction time, except for 127.0.0.1 and localhost (so a local operator endpoint works during development). Because that check covers the configured URL and nothing past it, requests also set redirect: 'error' — an endpoint cannot redirect the call, and the request body with it, to a host that was never validated.

  • Per-call abort window. Each request runs under an AbortController that aborts after 30s, preventing a hung endpoint from starving the MCP server.

  • Response-size cap. 16 MB, enforced twice. A Content-Length over the cap is rejected before the body is read at all; independently, the body is measured while it streams and the read is aborted the moment it exceeds the cap. The cap therefore does not depend on the sender declaring an honest Content-Length, or any at all.

  • No header echo. Authorization is never included in thrown error messages or stdout.

  • No configuration or user data read from disk. Configuration flows entirely through env vars, and nothing is ever written to disk. The package opens exactly one file: its own package.json, once at startup, so serverInfo.version matches the published version (falling back to 0.0.0-dev if it cannot be read). No credential, cell, or user-data path touches the filesystem.

  • Zero EVM tooling. No ethers, no eth_*, no Solidity. If operators inject signature verifiers via AuthVerifiers, they should use pure-crypto libraries (@noble/curves, @noble/post-quantum).

Trust model: this client trusts whatever endpoint the operator configures. Cell IDs, audit anchors, and report receipts returned from that endpoint are surfaced to the agent verbatim — operators are the authority for content shown via saihm_recall. Verifying receipts against COTI V2 mainnet anchors is out of scope for this server; consume the cellId and auditCellId fields and verify against your own SAIHM mainnet read path.

For distribution integrity, each release carries the npm registry signature; verify with npm audit signatures (and inspect npm view @saihm/mcp-server --json | jq .dist).

Dependencies

The published npm package has a minimal runtime surface:

Dependency

License

Role

Node.js (≥ 20.x)

MIT

Runtime

@modelcontextprotocol/sdk

MIT

Runtime; MCP SDK, binds the eight-tool surface

zod

MIT

Runtime; validates tool inputs and report templates

@noble/hashes

MIT

Runtime; SHA-256 for content digests only — a template's templateHash and a report's outputSha256. No key material passes through it; see HARDENING.md §"Surface minimization"

TypeScript

Apache-2.0

Build-time only — not installed by npm install @saihm/mcp-server

tsx

MIT

Build-time only; TypeScript runner for tests + CLI

No copyleft, no proprietary dependencies. Cryptographic primitives at the operator-endpoint layer (ML-DSA-65 / Ed25519 / key derivation) are not bundled into this MCP server; operators implementing the protocol stack are recommended to use @noble/post-quantum and @noble/curves (MIT) rather than rolling custom code.

Achievements

  • OpenSSF Best Practices Passing badge — project 12898, 100% Passing criteria (2026-05-19). https://www.bestpractices.dev/projects/12898

  • IETF — draft-saihm-memory-protocol-01 (2026-05-27) was submitted to the Independent Submission Stream; on 2026-07-25 the ISE concluded its consideration and released it from the queue (datatracker stream now None), directing the work toward IETF working-group activity (the agentproto effort). It is not an Internet Standard, is not endorsed by the IETF, and has no formal standing in the IETF standards process. The -01 draft remains available on the datatracker as the current reference text. https://datatracker.ietf.org/doc/draft-saihm-memory-protocol/

  • npm registry — releases from 0.3.6 (2026-06-30) onward are published from GitHub Actions over OIDC trusted publishing and carry an npm sigstore provenance attestation; 0.3.6–0.3.10 all do, and the ten earlier versions (0.1.0–0.3.5), published by hand, do not — see HARDENING.md §"Distribution integrity", which also records that no release tag is signed. 0.3.4 (2026-06-22) adds a conspicuous "Storage is the operator's responsibility (by design)" section — documenting BYO storage and the Join-SAIHM hosted, non-custodial option. 0.3.3 (2026-06-22) was a documentation release that states the Independent-Submission status precisely (no implied IETF endorsement) and cross-references the companion package @saihm/client-pro. 0.3.2 (2026-06-22) corrected the documented operator-endpoint path to /mcp (the canonical SAIHM_ENDPOINT_URL path) across the README and client comments. 0.3.1 (2026-05-28) was a metadata patch that sources the MCP serverInfo.version from package.json (was hardcoded "0.1.0" from 0.1.0 through 0.3.0). 0.3.0 (also 2026-05-28) aligned the saihm_status response shape with draft-saihm-memory-protocol-01 §3.4 (full eight-field schema: prs, bfsi, bfsi_window_start_ts, bfsi_R, bfsi_M, shards, contracts, governance). 0.2.0 (also 2026-05-28) aligned the cell-tuple response shape with §2.1; The OpenSSF Best Practices Passing badge was achieved on 2026-05-19 alongside the governance and assurance files; those files first reached npm in 0.2.0 (2026-05-28), as the 0.1.3 version they were prepared under was never published.

  • MCP Registry / Glama — server listed for discovery (2026-05-16).

Roadmap

A 12-month roadmap is maintained in the project's AAIF proposal and is published at https://saihm.net/roadmap. Near-term tracks:

  • 2026-Q2 (closed — one gap carried forward) — Of the OpenSSF Silver pursuit, governance, code-of-conduct, DCO sign-off, coverage tooling and the assurance case all landed. Release-tag signing did not; GOVERNANCE.md §"Releases" and HARDENING.md §"Distribution integrity" both record it as an open gap, and it is carried into the Silver track below.

  • 2026-Q3 — First 2–3 external organization deployments; formal AAIF Project Proposal submission when adoption blockers clear.

  • 2026-Q4 — NIST AI RMF crosswalk public review; EU AI Act compliance-checklist generator. OpenSSF Silver award (target).

  • 2027-Q1 — v1.0 reference implementation. The specification's standards path is open: the ISE route closed on 2026-07-25, and the intent is to re-anchor the normative reference on an IETF working-group document once one exists that can be cited. No publication date is being claimed for that, because none is in the project's gift.

Support

SAIHM is developed and maintained by a solo founder. If it's useful to you or your organization, please consider sponsoring the project — it funds continued protocol, client, and open-standards work and keeps this open reference implementation maintained.

License

Apache-2.0 — see LICENSE.

Project

Available Tools

8 tools
saihm_forgetForget (GDPR erasure)A
DestructiveIdempotent

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

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesMemory entry ID (hex cellId) to erase

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds critical behavioral detail: key destruction makes the content unreadable to everyone including the operator, and the operation is irreversible. This goes beyond what annotations express and properly warns an agent about 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 with a distinct job: state the action, describe the cryptographic consequence, and give the usage rule. There is no filler and no repetition of what the schema already provides.

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 single-parameter destructive tool with destructive/readOnly/idempotent annotations already present, the description covers purpose, irreversibility, and when to use it. With no output schema, return-value documentation is not required here.

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%, with the id parameter already described as 'Memory entry ID (hex cellId) to erase.' The description reinforces 'by its cell id' but adds no additional syntax or format details, so the baseline 3 applies.

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 'Cryptographically erase one memory by its cell id' — a specific verb, resource, and scope that clearly distinguishes it from the remember/recall/share siblings. The GDPR Art. 17 framing reinforces that this is a true erasure operation, not a soft delete.

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?

It explicitly states when to use it ('use it when erasure is the intent') and provides an exclusion ('not to tidy a working set'). It does not name a concrete alternative sibling, so the routing guidance stops just short of a fully explicit 5.

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 by default. The call is forwarded to the operator endpoint you configured, so expect an error rather than an open vote unless that operator has turned governance on. Where it is enabled it returns a hex proposalId that saihm_governance_vote takes, and it starts a vote rather than changing a setting.

ParametersJSON Schema
NameRequiredDescriptionDefault
scopeYesGovernable scope
paramKeyNoParameter key (when scope=emission_param)
proposedValueNoProposed value as string

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: it is forwarded to an operator endpoint, governance is disabled by default, the call may error, it returns a hex proposalId, and it starts a vote rather than mutating settings. These details meaningfully complement readOnlyHint=false and idempotentHint=false without contradicting them.

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 four sentences with purposeful structure: purpose and parameter guidance first, then operational caveats, then return value and side effect. It is slightly longer than the bare minimum, but every sentence contributes information an agent needs before calling the tool.

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 mutating tool with no output schema, the description covers the return value (hex proposalId), the side effect (starts a vote), the precondition (governance enabled), and the likely error mode. An agent has enough context to decide whether to call this tool and what to do with the result.

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 met by the schema alone. The description adds value by specifying the conditional relationship: paramKey and proposedValue are required when scope=emission_param, implying they are unnecessary for protocol_upgrade. It does not enumerate valid paramKey values or formats, but that goes beyond what the schema itself 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?

The description states a specific action ('Open a protocol governance proposal') and immediately narrows it to two scopes with conditional parameters. It also distinguishes itself from saihm_governance_vote by explaining that it returns a proposalId for voting, and the phrase 'starts a vote rather than changing a setting' removes ambiguity about 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 explains when the tool will work (when the operator has governance enabled), what to expect when it won't, and that the returned proposalId is consumed by saihm_governance_vote. It does not explicitly list alternative tools for other operations, but the relationship with the only relevant sibling 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_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 by default. The call is forwarded to the operator endpoint you configured, so expect an error rather than a recorded vote unless that operator has turned governance on. Where it is enabled, vote weight derives from the governance-token balance held at the proposal snapshot epoch, not the balance at the time of voting.

ParametersJSON Schema
NameRequiredDescriptionDefault
approveYestrue = approve, false = reject
proposalIdYesHex proposalId returned by saihm_governance_propose

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark readOnly=false and idempotent=false, and the description adds non-obvious behavior: the call is forwarded to the operator endpoint, failures occur when governance is disabled, and vote weight is based on snapshot-epoch balance rather than current balance. This materially helps an agent predict outcomes.

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, front-loaded with the action and parameter semantics, with caveats following. There is no filler, repetition of annotation data, or unnecessary detail.

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 purpose, parameters, failure mode, and the voting-weight caveat, which is substantial for a two-parameter tool. It does not describe the success or failure return payload, but with no output schema this is a minor gap given the behavioral caveats are covered.

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?

The input schema fully documents both required parameters with descriptions, so the baseline is 3. The description repeats the approve polarity and references proposalId but adds no new parameter-level syntax or constraints beyond the 'open proposal' context.

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 names a specific action ('Cast a vote'), the resource (an open protocol governance proposal), and identifies the proposal by proposalId. It also clarifies the approve boolean's polarity, so an agent can distinguish this from proposal-creation sibling saihm_governance_propose.

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 gives clear invocation context: the proposal must be open, the approve flag expresses support or rejection, and governance may be disabled at the operator endpoint so an error is expected unless enabled. It does not explicitly name sibling alternatives or state when not to vote, but the context is sufficient for correct use.

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 memories from the SAIHM encrypted store; the operator decrypts and returns plaintext, and this client holds no keys. Use at the start of a session, or whenever past context is needed. Pass a keyword to filter, or leave empty to load all.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoFilter by keyword (empty = all)

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYes
memoriesYes

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety and mutation behavior are covered. The description adds meaningful context beyond annotations: the operator performs decryption and the client holds no keys. This clarifies an important architectural behavior 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?

Three concise sentences cover purpose, usage context, and parameter behavior. The description is front-loaded with the core action and wastes no words on irrelevant 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 tool with one optional parameter, rich annotations, and an output schema, the description is complete. It states what the tool does, when to use it, how to control scope with the query parameter, and a key security-relevant behavioral detail about key handling.

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%, and the single query parameter is documented as "Filter by keyword (empty = all)." The description restates this guidance almost exactly without adding new semantic information, so it meets the baseline but does not exceed it.

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 identifies the operation: "Retrieve memories from the SAIHM encrypted store." It also distinguishes this from sibling tools like saihm_remember and saihm_forget by focusing on retrieval of stored context. The added detail about operator decryption and plaintext return makes the purpose even more concrete.

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 explicit timing guidance: "Use at the start of a session, or whenever past context is needed." It does not explicitly name alternatives or state when not to use it, but the usage context is clear enough for an agent to select it appropriately among siblings.

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 encrypted memory. Use this when a fact, decision, or piece of context should outlive the current session. Returns the cell id that saihm_forget takes.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesInformation to remember

Output Schema

ParametersJSON Schema
NameRequiredDescription
tierNo
epochNo
cellIdYes
feeNcotiNo
cellNonceNo
kekVersionNo
signaturePrefixNo

TDQS

A4.5/5.0
Behavior4/5

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

The description adds context beyond annotations by revealing that the memory is persistent and encrypted, and that the tool returns a cell id usable by saihm_forget. The annotations already cover safety hints (readOnlyHint=false, destructiveHint=false), so the description's additional behavioral detail is valuable but not exhaustive.

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 with no filler. The main purpose is front-loaded, the usage guideline follows immediately, and the return value is mentioned because it directly enables the sibling forget operation.

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 single-parameter write tool with an output schema and safety annotations, the description is complete. It specifies what to store, when to use it, and what it returns, including the link to saihm_forget for removal.

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 schema covers the only parameter with 'Information to remember,' and the description complements this by clarifying acceptable content types: facts, decisions, or context that should outlive the session. This adds practical meaning beyond the bare schema definition.

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 ('Store') and resource ('SAIHM persistent encrypted memory'), making the tool's function immediately clear. It also distinguishes itself from siblings by indicating this is the write operation, while saihm_forget is the delete operation and saihm_recall is presumably the read operation.

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 states when to use the tool: when a fact, decision, or piece of context should outlive the current session. It does not provide explicit when-not-to-use guidance or name alternatives, but the use case is clear and sufficient for this simple tool.

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

Revoke a sharing contract by its contractId, withdrawing access granted with saihm_share. It applies to future reads and cannot retract what a grantee has already read. Use it to end access; the memory itself remains, and saihm_forget is what erases.

ParametersJSON Schema
NameRequiredDescriptionDefault
contractIdYesSharing contract ID to revoke

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral nuance: it applies only to future reads, cannot retract already-read data, and the memory persists. These details are consistent with the annotations and deepen the agent's understanding beyond what structured fields convey.

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, each adding distinct information: action, limitation, and routing. The main action is front-loaded, and there is no filler or repetition. The structure is efficient and immediately scannable.

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?

This is a simple tool with one parameter, no output schema, and existing annotations. The description covers purpose, when to use, limitations, and sibling distinctions. Nothing an agent needs to call it correctly 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?

The input schema has 100% coverage for the single parameter (contractId with its own description). The tool description merely references the parameter ('by its contractId') without adding extra semantics like format, provenance, or usage context, so the baseline 3 applies.

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 uses a specific verb ('revoke') and resource ('sharing contract'), and immediately distinguishes itself from siblings by referencing saihm_share (the granting tool) and saihm_forget (the erasure tool). It clearly answers what the tool does and how it differs from alternatives.

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?

Explicitly states when to use it ('Use it to end access') and when not to ('saihm_forget is what erases'), and notes the future-read limitation. This gives clear guidance on selecting this tool over its siblings without ambiguity.

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

saihm_shareShareA

Grant other agents access to specific memory shards. Set type to 'temporary', 'permanent' or 'syndicate', and scope to 'read', 'write' or 'readwrite'. Grantees are hex agent-id hashes, not names, and shardIds lists exactly what is shared: nothing outside it is exposed, and sharing does not copy the memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesContract type
scopeYesAccess scope
shardIdsYesShard IDs to include in the contract
expiryEpochNoOptional expiry epoch (decimal string)
granteeIdHashesHexYesHex-encoded grantee agent ID hashes

TDQS

A4.3/5.0
Behavior4/5

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

Adds meaningful behavior beyond the annotations: grantees must be hashes, not names; only listed shardIds are exposed; and sharing does not copy the memory. This clarifies important side-effect semantics without contradicting any annotation.

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?

Three sentences, front-loaded with the core action and then the most important caveats. There is minor redundancy with the schema's enum descriptions, but no filler or vague wording.

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?

All required parameters are effectively covered, and the no-copy/exhaustive-sharing caveat closes the most important semantic gap. With no output schema, return-value details are unspecified, but that is low risk for a sharing action.

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%, but the description adds value by interpreting the enums into actionable instructions and clarifying that shardIds is an exhaustive allowlist, not a loose filter. The optional expiryEpoch is left to the schema, which documents it adequately.

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 action ('Grant ... access') against a specific resource ('specific memory shards'), making it clearly distinct from remember, forget, recall, and revoke_share. The mention of type and scope further anchors 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?

Gives clear context for when to use it: granting other agents access to memory shards. It does not explicitly name alternatives or say when not to use it, so it stops short of full alternative routing.

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: agent identity, tier, the prs and bfsi scores, storage by tier, and sharing state, as far as the operator reports them — a non-custodial operator cannot see stored-byte totals. Use it to check the agent identity, custody mode, and what the operator reports about storage and sharing.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
phiNo
custodyNo
prsLevelNo
prsScoreNo
bfsiScoreNo
agentIdHashYes
snapshotEpochNo
feeDiscountPctNo
activeShardCountNo
activeSharingContractsNo

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already convey readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds meaningful behavioral context beyond these: results are limited 'as far as the operator reports them,' and a 'non-custodial operator cannot see stored-byte totals.' This discloses a real data-availability limitation that annotations alone would not communicate.

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 purpose and enumerates the status fields in a compact list. The second sentence is slightly redundant with the first, restating identity, custody mode, and operator-reported storage/sharing, but it does reinforce the intended use case without excessive length.

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 an output schema and strong annotations, the description covers what the tool reports, the reliability boundary (operator-reported), and the custodial limitation. Nothing essential is missing for an agent to decide to invoke it and interpret its results.

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 is empty with 0 parameters and 100% schema coverage, so the baseline is 4. There are no parameter semantics for the description to add, and the description correctly focuses on the output and behavioral caveats instead of inventing parameter details.

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 resource ('the current SAIHM session'), enumerating the exact contents: agent identity, tier, prs and bfsi scores, storage by tier, and sharing state. It also distinguishes itself from sibling tools, which are all actions (remember, forget, recall, share, etc.), by clearly being a read-only status inspection.

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 the agent identity, custody mode, and what the operator reports about storage and sharing,' giving clear when-to-use guidance. It does not name alternatives or exclusions, but among the siblings this is the only status/session-inspection tool, so the absence of explicit alternatives is not a material gap.

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.

  1. 3 tool updatesv0.3.10
    • Changedsaihm_recall1 field changed
      • changedOutput schema / properties / memories / items / required
        Previous value: -[
-  "cellId",
-  "kekVersion",
-  "cellNonce",
-  "timestamp",
-  "tier",
-  "plaintext"
-]New value: +[
+  "cellId",
+  "plaintext"
+]
    • Changedsaihm_remember1 field changed
      • changedOutput schema / required
        Previous value: -[
-  "cellId",
-  "cellNonce",
-  "tier",
-  "kekVersion",
-  "epoch",
-  "feeNcoti",
-  "signaturePrefix"
-]New value: +[
+  "cellId"
+]
    • Changedsaihm_status2 fields changed
      • addedOutput schema / properties / custody
        Added value: +{
+  "type": "string"
+}
      • changedOutput schema / required
        Previous value: -[
-  "agentIdHash",
-  "prsScore",
-  "prsLevel",
-  "bfsiScore",
-  "feeDiscountPct",
-  "activeShardCount",
-  "activeSharingContracts",
-  "phi",
-  "snapshotEpoch"
-]New value: +[
+  "agentIdHash"
+]
  2. 3 tool updatesv0.3.6
    • Changedsaihm_recall1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "memories": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "cellId": {
+            "type": "string"
+          },
+          "cellNonce": {
+            "type": "string"
+          },
+          "kekVersion": {
+            "type": "string"
+          },
+          "plaintext": {
+            "type": "string"
+          },
+          "tier": {
+            "type": "string"
+          },
+          "timestamp": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "cellId",
+          "kekVersion",
+          "cellNonce",
+          "timestamp",
+          "tier",
+          "plaintext"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "memories"
+  ],
+  "type": "object"
+}
    • Changedsaihm_remember1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "cellId": {
+      "type": "string"
+    },
+    "cellNonce": {
+      "type": "string"
+    },
+    "epoch": {
+      "type": "string"
+    },
+    "feeNcoti": {
+      "type": "string"
+    },
+    "kekVersion": {
+      "type": "string"
+    },
+    "signaturePrefix": {
+      "type": "string"
+    },
+    "tier": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "cellId",
+    "cellNonce",
+    "tier",
+    "kekVersion",
+    "epoch",
+    "feeNcoti",
+    "signaturePrefix"
+  ],
+  "type": "object"
+}
    • Changedsaihm_status1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "activeShardCount": {
+      "type": "number"
+    },
+    "activeSharingContracts": {
+      "type": "number"
+    },
+    "agentIdHash": {
+      "type": "string"
+    },
+    "bfsiScore": {
+      "type": "number"
+    },
+    "feeDiscountPct": {
+      "type": "number"
+    },
+    "phi": {
+      "type": "number"
+    },
+    "prsLevel": {
+      "type": "string"
+    },
+    "prsScore": {
+      "type": "string"
+    },
+    "snapshotEpoch": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "agentIdHash",
+    "prsScore",
+    "prsLevel",
+    "bfsiScore",
+    "feeDiscountPct",
+    "activeShardCount",
+    "activeSharingContracts",
+    "phi",
+    "snapshotEpoch"
+  ],
+  "type": "object"
+}
  3. 7 tool updatesv0.3.1
    • Changedsaihm_forget1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsaihm_governance_propose1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsaihm_governance_vote1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsaihm_recall1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsaihm_remember1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsaihm_revoke_share1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsaihm_share1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  4. 8 tool updatesv0.1.2
    • First observedsaihm_forget
    • First observedsaihm_governance_propose
    • First observedsaihm_governance_vote
    • First observedsaihm_recall
    • First observedsaihm_remember
    • First observedsaihm_revoke_share
    • First observedsaihm_share
    • First observedsaihm_status
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 8 tools

Disambiguation5/5

Each tool maps to a distinct action: remember/forget/recall cover the memory lifecycle, share/revoke_share cover sharing, and governance_propose/vote cover governance, while status is uniquely diagnostic. There is no meaningful overlap between any pair of tools.

Naming Consistency4/5

All tools share the saihm_ prefix and use snake_case, but the suffix pattern is uneven: some are bare verbs (remember, forget, recall, share), others are object-first (governance_propose, governance_vote), and one is verb-object (revoke_share). This is readable and predictable enough, though not perfectly consistent.

Tool Count5/5

With 8 tools, the server is well-scoped and each tool has a clear role across three related subdomains: persistent memory, sharing, and governance. This is a comfortable size that avoids both bloat and thinness.

Completeness4/5

The memory lifecycle is essentially covered (create/read/delete), and sharing has both grant and revoke. The governance portion lacks a way to list or inspect open proposals, and there is no direct get-memory-by-id, but agents can work around these gaps using recall or status.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers