MCP memory
The Model Context Protocol gives your agent a standard way to call a memory server. It says nothing about where that memory lives, who can read it, or what happens when you ask for it to be deleted. Those are the choices that matter.
What an MCP memory server is
The Model Context Protocol is an open standard for connecting AI agents to outside capabilities. An MCP server advertises a set of tools; an MCP client — the agent, or the application hosting it — discovers those tools and calls them during a conversation. The agent decides when to call; the server decides what the call does.
An MCP memory server is that pattern applied to remembering. Instead of tools that read files or query an API, it exposes tools that store something, retrieve something, and remove something. The agent gains a place to put facts that outlive the conversation, and a way to look them up at the start of the next one.
This turns out to be one of the highest-value things you can connect an agent to, because it fixes the failure everyone notices first: an agent that is capable within a session and amnesiac between them. You explain your stack, your constraints, your preferences and your history. The session ends. The next one starts from nothing, and you explain it all again.
It is also the connection with the largest and least examined blast radius. A memory server accumulates, by design, the most concentrated record of your work that exists anywhere — not one document, but the running summary of what you are doing and why. Wiring one up is a two-minute job. Choosing which one is a custody decision.
What MCP standardizes — and what it deliberately leaves open
It is worth being precise about the division of labor, because a great deal of confusion in this space comes from expecting the protocol to have settled questions it never addressed.
MCP standardizes the wiring. How a client discovers a server. How tools declare their inputs. How calls and results are framed. How a server is launched and spoken to over a transport. This is genuinely valuable and it is why an agent written against MCP can use a memory server the author never heard of.
MCP does not standardize custody. Nothing in the protocol says where the stored content lives, whether the party running the server can read it, whether it is bound to you or to the application, or what a deletion tool actually does to the bytes. Two servers can present an identical tool surface — the same names, the same parameters, indistinguishable to the agent — while one holds your memories as plaintext in a database an operator can query and the other holds ciphertext it has no key for.
The agent cannot tell the difference. Neither can the tool list. That is not a defect in MCP; a transport protocol is not the right layer to settle data governance. It does mean the question has to be asked somewhere else, by you, before you connect the server.
The practical test is a single question, and it is not “is it encrypted.” It is: where does the plaintext exist? If plaintext exists on the server side at any point — and it must, if the server is the thing performing the search — then whoever runs that server is inside your trust boundary, no matter what the storage disk is encrypted with.
Three ways to give an MCP agent memory
Nearly every MCP memory server in circulation is one of three designs. They are not ranked; they suit different situations, and the third is the one SAIHM implements.
| Design | Where memory lives | Who can read it | Moves with you? |
|---|---|---|---|
| Local file or database store | A file or embedded database on your machine | Anyone with access to that machine, and any process running as you | No — it is tied to the device |
| Hosted memory service | The provider’s database | The provider, and anyone they are compelled or breached into disclosing to | Within that provider’s products |
| Identity-bound protocol memory | Distributed storage, sealed before it is sent | Only the holder of the key | Yes — it follows the key, not the app |
A local store is the right answer more often than its reputation suggests. It is simple, it is fast, nothing leaves the machine, and for a single developer on a single laptop it is hard to beat. Its limits are the ones you would expect: it does not follow you to a second machine, it does not survive a rebuild unless you remembered to back it up, it cannot be shared with a colleague without copying the whole thing, and every process running under your account can read it.
A hosted service solves the machine-boundary problem and adds real operational value — backups, availability, search quality, a dashboard. It relocates the custody question rather than answering it. The provider holds readable memory because the provider performs the search, and your erasure requests are requests, executed on their timetable, against replicas you cannot enumerate.
Identity-bound memory keeps the durability and the portability, and removes the operator from the trust boundary by never giving them anything readable. The cost is that features requiring the server to understand your content are constrained by design. That trade is the whole point, and it is the honest way to describe it.
For named products rather than architectures, the comparison page and the decision matrix go product by product.
Add memory to your MCP client
SAIHM ships as a standard MCP server on npm. It runs on your machine and speaks stdio, the transport most MCP clients launch a local server with. There is nothing to host and no endpoint to stand up.
For clients configured by a JSON file, add one entry:
{
"mcpServers": {
"saihm": {
"command": "npx",
"args": ["-y", "@saihm/mcp-server-pro"]
}
}
}
For Claude Code, the same thing from a terminal:
claude mcp add saihm -- npx -y @saihm/mcp-server-pro
No environment variables are required. Every setting the server accepts has a working default, so the minimal configuration above is the complete configuration for a normal first run. Restart the client, and the memory tools appear in its tool list.
Then tell the agent “Join SAIHM”. It generates an identity on your device, activates the free tier, and has memory from that moment. Nothing is pasted, no key is issued to you by us, and no card is involved. If you would rather do it before wiring anything up, npx -y @saihm/mcp-server-pro free-join does the same thing from a terminal, and /free does it in a browser.
Because the interface is plain MCP, it is not tied to one agent. Any client that speaks the protocol can use the same memory — including one you write yourself, and including agents that do not exist yet.
The tools your agent gets
Eight tools, which is deliberately few. A memory interface that an agent has to be taught is a memory interface that will be used wrongly.
- saihm_remember
- Store something. Encryption happens on your machine, so what leaves it is ciphertext.
- saihm_recall
- Retrieve memories and decrypt them locally. Typically the first call of a session.
- saihm_forget
- Cryptographic erasure of one memory. Irreversible, including for us.
- saihm_status
- Identity, tier, what is stored, what is shared.
- saihm_share
- Grant one other agent access to one memory, at a scope you set.
- saihm_revoke_share
- Withdraw that grant.
- saihm_governance_propose
- Open a proposal on a protocol parameter.
- saihm_governance_vote
- Vote on an open proposal.
The agent calls these on its own judgment, in the ordinary flow of the conversation. In practice the pattern that emerges is recall at the start of a session and remember when something is decided — which is roughly how a competent colleague would behave, and it is not something you have to prompt for.
Full parameter detail is on the documentation page, and integration notes are on the developers page.
What “forget” has to mean in a memory server
Every memory server has a delete tool. Very few will tell you what it does, and the difference is the difference between a tidy-up and an erasure.
Deletion in an ordinary store is a row removal. The row goes, the index updates, and the content persists in whatever replicas, snapshots, backups and log archives the system created while it existed — which is exactly the set the operator cannot fully enumerate, because durability engineering is the practice of making copies you do not have to think about.
SAIHM erases by destroying the key that decrypts the memory. The ciphertext may remain wherever it has spread; it is no longer readable by anyone, us included. That property is what makes the guarantee hold against copies that cannot be reached, and it is why the operation is irreversible rather than reversible-with-effort.
It also means saihm_forget is not a tool for tidying a working set. It is for when erasure is the intent. That distinction is written into the tool description the agent reads, so the agent treats it that way too.
The regulatory reading, for those who need one: this is the shape a right-to-erasure request has to take when the data has been replicated. Compliance reports covers that in detail.
Sharing between MCP agents
Once more than one agent is doing useful work, they need shared context, and the usual answer is to give them a shared store — which means every agent can read everything, forever, and the blast radius of one compromised agent is the whole corpus.
Sharing in SAIHM is per memory and per recipient. Granting access re-wraps that one memory’s key for that one recipient. Nothing is copied, no bulk export exists, and revoking ends future reads. The recipient is named by their identity, not by an account name on a platform both parties happen to use.
This is what lets a group of agents coordinate without being wired to each other. Multi-agent memory covers that case, including swarms and robot fleets, in full.
When this is the wrong choice
Three cases where you should use something else, stated plainly because a page that cannot name its own limits is advertising.
You want the server to reason over your content. Server-side semantic ranking, clustering and summarization all require the server to read plaintext. If those features are the requirement, a hosted memory service is the correct architecture and sealed memory is the wrong one. The trade is real and it does not go away by wishing.
Everything is on one machine and stays there. If nothing ever needs to move between devices, be shared, or survive that machine, a local file-backed MCP memory server is simpler and you should use it.
You need memory your organization can read without the user. Some environments have a legitimate requirement for supervised access to what an agent stored. Custody that excludes the operator excludes the employer too. Enterprise describes what is and is not possible there, without pretending the tension does not exist.
Start free
The free tier needs no card, no wallet and no crypto. Tell your agent “Join SAIHM”, or run one command:
npx -y @saihm/mcp-server-pro free-join
It shows a short code and a link. Open the link, approve it, and the agent has memory from that moment. Prefer to start in a browser? /free does the same thing.
Paid plans are monthly. Card worldwide through Stripe; card and M-PESA in Africa through Paystack. Stablecoin is available for those who prefer it and is the only route that needs a wallet. Prices are published on the pricing page rather than quoted per customer.
Common questions
- What is an MCP memory server?
- An MCP server whose tools store, retrieve and remove information, so an agent can keep facts that outlive a single conversation. The Model Context Protocol standardizes how the agent calls those tools; it does not specify where the memory is kept or who can read it.
- Does MCP say who can read my agent’s memory?
- No. MCP standardizes discovery, tool schemas and transport. Custody is left to the server. Two servers can look identical to the agent while one holds readable plaintext and the other holds ciphertext it cannot decrypt, so the question has to be asked about the specific server.
- How do I add a memory server to my MCP client?
- Add an entry to the client’s MCP configuration with the command that launches the server. For SAIHM that is
npx -y @saihm/mcp-server-prowith no environment variables required, orclaude mcp add saihm -- npx -y @saihm/mcp-server-profrom a terminal in Claude Code. - Does the SAIHM MCP server run locally or remotely?
- Locally. It is launched by your client over stdio and runs on your machine, which is what allows encryption and decryption to happen where the key is. There is no endpoint to host and no server of your own to operate.
- Is a local file-backed memory server good enough?
- For one developer on one machine, often yes, and it is simpler. It stops being enough when memory needs to survive that machine, move to a second one, be shared with another agent, or be erased in a way you can evidence.
- What does the forget tool actually delete?
- It destroys the key that decrypts that memory, which leaves any remaining ciphertext unreadable to everyone including the operator. That is what makes it effective against replicas and backups that cannot be individually located, and it is why the operation cannot be undone.
- Can two MCP agents share memory without sharing everything?
- Yes. Access is granted one memory at a time to one named recipient, by re-wrapping that memory’s key rather than copying content, and can be withdrawn. There is no shared store that every participating agent can read.
- Do I need crypto to use SAIHM?
- No. The free tier needs no payment method, and paid plans are payable by card through Stripe, or card and M-PESA through Paystack in Africa. Stablecoin is an option for people who prefer it.
Related
- AI agent memory — the four kinds, custody, and what erasure means.
- Multi-agent memory — agents, swarms and robot fleets coordinating without wiring.
- Persistent memory — what memory has to survive: the session, the machine, the app, the model, the provider.
- Memory security — the threat model, and what custody does not fix.
- Memory protocol — why portability is a protocol property, not a product feature.
- Decision matrix — which kind of memory fits which requirement.
- Developers — interface, integration and tooling.
- Docs — tool parameters and the identity model.
- Quickstart — the shortest path from nothing to working memory.
- MCP crosswalk — how a memory layer composes with Model Context Protocol primitives.
- Standards work — the wider specification and crosswalk set.