ChainMemory

ChainMemory MCP Server

Cross-model, cryptographically verifiable memory for Claude, ChatGPT, and any AI agent — own your AI's memory and carry it across every model.

ChainMemory MCP exposes the ChainMemory protocol to any AI agent that speaks the Model Context Protocol. Memories are encrypted (AES-256-GCM), anchored on-chain one by one so anyone can verify them, and portable across ChatGPT, Claude, Gemini, Perplexity, and any other LLM. No vendor lock-in, ever.

What's new in v2.10.0

• Full level for `get_project_brief`, only when you allow it. The brief is public by default: safe to paste into any chat, with addresses, ports, server paths and security rules replaced by [withheld]. Pass level: "full" to get them too, for work on your own infrastructure. It works only if you add CHAINMEMORY_ALLOW_FULL=1 to this MCP server's env, only with the owner's key (member and project keys are refused by the API), and ChainMemory logs every full-level request: when, which project and version, from which client and how many sensitive lines went out. The brief says so at the top and counts the sensitive lines at the end.
• The remote endpoint never offers the full level. It serves third-party clients, so the parameter is not even published there.
• How a project's AIC are safeguarded never appears in a brief, at any level.
• Every request now tells the API which client made it (chainmemory-mcp stdio|remote), which is what the full-level log records.

To enable it, add the variable next to your API key:

"env": {

"CHAINMEMORY_API_KEY": "aic_your_key_here", "CHAINMEMORY_ALLOW_FULL": "1" }

What's new in v2.9.1

• `get_project_brief` has a task mode. Pass task: "pri_0015" and the brief is about that one priority: the priority in full, its completion criterion on its own line, the risks it mitigates, everything else in the Brain that mentions it, and every work rule and constraint. A general brief orients; this one is meant to be enough to start the work. It does not move the version remembered for "what changed".
• Briefs are safe to paste into any chat. The server now replaces IP addresses, ports, server paths and the owner's security rules with [withheld], and says how many were withheld in that text, so the agent knows to ask. Before, a large budget could carry a server path or an SSH port into a third-party chat.
• The brief says more about what it shows: the full state_hash, each changed priority-risk link with its previous value, completion criteria never cut, titles in "to review", the owner's work rules, and how many items cite evidence, with the rest marked (no evidence).
• Priorities can be linked to risks. update_project_state documents the new mitigates field of add_priority and the set_priority_risks op (the grammar is now 30 ops). The brief then shows which priority covers each risk and lists the high risks nobody mitigates. The documented value sets were also corrected: risks can be mitigated, and priorities are active, done or dropped.

What's new in v2.9.0

• `get_project_brief`: the Project Brain in a few thousand characters, most important first. get_project_state returns the whole state as JSON, which on a mature project is long, and an agent opening a session reads it from the top. The brief is plain text built by the server (GET /v1/project/:name/inject) by relevance and within a character budget (default 7,000, from 1,000 to 50,000): what changed since the last version you read, open risks (high first), active priorities, recent decisions with their scope, recent milestones, open questions, each constraint as a one-line rule, and the items that have not been reviewed for more than 30 versions and may no longer be true. It starts with the state's on-chain anchor. Free and read-only.
• "What changed" is measured from what you last read. This local server remembers, per project, the last version it gave you, in ~/.chainmemory/brief-since.json. The file is indexed by a hash of your API key and the project name: it contains neither. Pass since to compare against a specific version. On the remote endpoint nothing is stored, and the comparison is with the previous version.
• Headings in English or Spanish (lang: "es"); the items are returned as they were written.
• get_project_state is unchanged, and is still the tool to use before update_project_state.

What's new in v2.8.1

• The search model downloads on slow connections. The first download (45 MB, only with the blind vault) was cut after 2 minutes in total, so on a slow but working connection the model never arrived and the first sealed memory was saved without its search vector. Now the download is cut only if it receives no data for 60 seconds, however long it takes overall.

What's new in v2.8.0

• Sealed memories are searchable. With the blind vault configured (CHAINMEMORY_SEED_PHRASE), chainmemory_remember with sealed:true now sends the memory's search vector along with the encrypted blob, computed on your machine. The server can find a memory it cannot read, and search_memories decrypts sealed matches locally.
• Your queries stay on your machine. With the vault configured, search_memories sends the query's vector, not its text, so the text of what you search is never sent to the server nor written to its search log.
• No new dependencies. The vector comes from ChainMemory's own engine (tokenizer, model reader and WebAssembly kernel written by ChainMemory), shipped in the package: 80 kB in total. The first time it is needed, the 45 MB search model is downloaded from models.chainmemory.ai, checked against its SHA-256 anchored on ChainMemory's chain, and stored in ~/.chainmemory/models (or CHAINMEMORY_MODELS_DIR); it is checked again every time it is loaded.
• Without the vault nothing changes and nothing is downloaded.

What's new in v2.7.1

• Correct version in the MCP handshake. The server announced itself as 2.5.6 to every client, whatever package was installed. It now reads the version from package.json, so the two cannot drift again.
• `quote_inject` reports missing memories correctly — fixed on the API side (2026-09-14), no client change needed. Before, it listed memories it had found as *not found* and told the agent to fix a list that was fine.
• get_inject_history responses now include memory_numbers, the #N of each injected memory.

What's new in v2.7.0

Tool descriptions rewritten for agents, not for humans. An audit of all 36 found that only 39% said *when* to use them, 25% stated their limits, and two charged without saying so. One of them was plainly wrong.

• chainmemory_profile promised memory count, trust score and registration block. None of those fields exist — the API returns chain_memories, local_memories, synced_memories, pending_sync, reputation, owner and active. The v2.5.6 release fixed the code that asked for the wrong fields; the description kept advertising them.
• chainmemory_remember (0.001 AIC) and update_project_state (0.05 + 0.005 per op) now state their fee. They are the most used and the most expensive tool respectively.
• update_project_state now documents the closed value sets. severity is low, med or high — *not* medium, *not* critical. A wrong value costs a rejected op and the fee is charged anyway.
• get_my_context and chainmemory_recall both said "use at conversation start". Now each says when to use it *instead of* the other.
• Twelve one-line descriptions gained their cost, their limits and the gotchas that cost a failed call: delete_project needs the numeric id and rejects the slug; add_project_from_template and list_project_templates deal in ids that cannot be guessed; chainmemory_seal is the only tool requiring a wallet private key.

No behaviour changed: same 36 tools, same endpoints, same fees. What changed is what the agent is told before it chooses.

What's new in v2.6.1

Documentation fix only, no code changes. The blind vault section described the verification step wrongly: GET /v1/memory/ /decrypted does not fail on a sealed memory — it returns 200 with scheme: "sealed" and the encrypted blob. The guarantee is the same (the operator never gets your text) but the observed behaviour was not what we documented. Found by running the first end-to-end test against the live API.

What's new in v2.6.0

Blind vault — memories the server cannot read. Pass sealed: true to chainmemory_remember and the text is encrypted on your own machine before it leaves: AES-256-GCM with a key derived from twelve BIP-39 words that never touch the network. ChainMemory stores an opaque blob and anchors its hash. Same fee as a normal write — privacy costs nothing extra.

• chainmemory_new_seed creates the phrase locally. Shown once, stored nowhere.
• chainmemory_open_sealed fetches the blob and decrypts it here, not there.
• Without CHAINMEMORY_SEED_PHRASE, everything behaves exactly as in 2.5.6.

One honest limitation: a sealed memory is stored with no searchable text, so it will not appear in search_memories — the server has nothing to index. Its project and tags *are* stored, so list_memories_filtered still finds it by project; you then read the content with chainmemory_open_sealed. Losing full text search is the direct consequence of the server being unable to read it, and there is no way around that which keeps the guarantee. *(Solved in v2.8.0: the search vector is now computed on your machine, so sealed memories are searchable without the server reading them.)*

If you lose the twelve words, the memories sealed with them are gone — for you and for everyone. Write them on paper.

What's new in v2.5.6

Three defects that made tools report confidently wrong things. No new tools.

• `list_project_templates` never listed anything. It read templates / template_id from a response that returns defaults / project_id, so it always answered "No templates available" — which meant nobody could learn the id that add_project_from_template needs. The whole template flow was unreachable.
• `chainmemory_profile` got five of eight fields wrong. It read wallet, memory_count, trust_score, registration_block and sealed; the API returns owner, chain_memories / local_memories, reputation and active. Every profile came back with an empty wallet, zero memories, ? reputation and Sealed: no, regardless of the real state. It also had no handling for an API key with no registered identity, printing AI Profile #undefined.
• `update_project_state` hid the reason when every op was rejected. Rejections were only rendered on the success path, but rejecting *all* ops leaves the state unchanged and takes the other branch — so the reply said Rejected: 3 and nothing else. The only way to find out why was to guess again and pay the fee again.

What's new in v2.5.5

• `audit_memory` and `audit_state` — the two forensic audit endpoints, now reachable from any MCP client. Both accept `dry_run: true`, which returns the identical result without charging: an audit you can run as often as you like, and pay for only when you need the receipt on record. audit_state costs 5 AIC in its paid form, so the tools default to the dry run.
• Both endpoints were fixed server-side first: t