MCP SERVER

Configuration

The MCP server lets Claude Desktop, Cursor, Windsurf, Hermes Agent, OpenClaw and any MCP-compatible client use ChainMemory as a native tool.

Installation

Add this configuration to your claude_desktop_config.json:

JSON
{
  "mcpServers": {
    "chainmemory": {
      "command": "npx",
      "args": ["-y", "chainmemory-mcp"],
      "env": {
        "CHAINMEMORY_API_KEY": "your-api-key"
      }
    }
  }
}

Restart the client afterwards. Publishing a new version to npm does not update clients that are already running: the package is fetched when the client starts.

Get your API Key In the Chrome extension, click "View key" to see and copy the full key. The Settings tab shows it abbreviated, for identification only.
External service ChainMemory is an independent protocol. It is not part of Claude, ChatGPT, Cursor or any AI provider. Any MCP-compatible client connects with an API key. Your memories belong to you, not to the AI provider.

Available Tools

The current version exposes 34 tools. Reading is free; the operations that cost AIC are marked. See Costs for the full schedule.

Memory

ToolWhat it doesCost
chainmemory_rememberSave a memory linked to a project, with tags, category and importance (1–10)0.001 AIC + storage
chainmemory_recallReturn your most recent memories, newest first. It does not search — it lists. Returns 80-character previewsfree
search_memoriesSemantic search over your memories, returning the full text of each matchfree
get_memoryRead one memory in full, decrypted from chain, with an integrity check against its anchored hashfree
list_memories_filteredList memories by project and archived status. Returns 80-character previewsfree
update_memory_tagsReplace the tags of a memoryfree
archive_memory · unarchive_memoryHide a memory from lists and injections, or restore it. It stays on record either wayfree
chainmemory_sealSeal one memory permanently on-chain so it can no longer be modified. Requires a wallet key0.001 AIC

Verification

ToolWhat it doesCost
get_memory_proofThe shareable anchoring proof of a memory: its event_hash and on-chain coordinates. A third party verifies it without your API key, and the content is never exposedfree
verify_project_statePublic, unauthenticated proof of a Project State: every anchored version with its state_hash, anchor id, transaction and block, plus how to check them yourself in the contractfree
audit_memoryForensic audit of one memory: recomputes its hash from the stored content and compares it against the anchored one0.1 AIC — free with dry_run
audit_stateFull audit of a Project State: recomputes the state_hash with the deterministic engine and returns the anchor plus version history5 AIC — free with dry_run

Project State

ToolWhat it doesCost
get_project_stateThe consolidated state: vision, phase, current focus, decisions, risks, assumptions, open questions, priorities, constraints, metrics, vocabulary and working environment — plus its state_hash and on-chain anchor. Pass include_roles: false to omit the text of the role contractsfree
update_project_statePropose operations from the 29-op grammar. The server validates, applies them with the deterministic builder, recomputes the hash and persists0.05 AIC + 0.005 per applied op

Verifiable Role Contracts

ToolWhat it doesCost
list_role_contractsList the roles defined for a project with their version and status. Call it first: role ids are not guessablefree
get_role_contractRead a role's contract: purpose, rules with their checks and severity, working protocol. Accepts version to audit a past onefree
assume_roleOpen an audited role session under an active contract. Pins the contract hash and the Brain's state_hash, and delivers the owner's declared working environment0.001 AIC
release_roleClose a session with a summary of what was done and what is pending. Sessions auto-release after 60 minutesfree
list_role_sessions · get_role_sessionThe audit trail: who assumed which role, when, how it closed, and the hashes the session was bound tofree

Injection

ToolWhat it doesCost
quote_injectPrice an injection before paying: which ids exist, which do not, total characters, exact cost with its split, and whether your balance covers itfree
inject_memoriesInject up to 50 memories into the current conversation. Optimistic: the text returns immediately and the payment confirms in the background0.1 AIC per call
get_inject_balance · get_inject_historyYour AIC balance and how many injections it covers; the history of past injections with their costfree
get_my_contextYour recent memory as ready-to-inject portable context, across every platformfree

Projects and identity

ToolWhat it doesCost
list_projects · create_project · delete_projectManage your projects and their auto-tagging keywordsfree
list_project_templates · add_project_from_templateBuilt-in templates: general, development, blockchain, business, personal, researchfree
chainmemory_registerRegister an AI identity on chain. Required once before writing memoriesfree
chainmemory_profile · chainmemory_statsYour identity's profile and the network's statisticsfree

Autonomous Consolidation

Any AI client can consolidate the project state autonomously with update_project_state. This is the "client consolidates, chain verifies" architecture: the model proposes, the server validates and only then does it become state.

1

Read the current state

Call get_project_state to load the consolidated state and its consolidated_until_event watermark.

2

Analyze what is new

With list_memories_filtered or search_memories, read the memories created after the watermark to identify what changed.

3

Propose the operations

Build an array of operations from the 29-op grammar and send it through update_project_state.

4

The server validates and persists

Each operation is validated against the grammar, applied through the deterministic builder, the new state_hash (SHA3-256) is computed, evidence is linked with Merkle trees, and the version is persisted. Invalid operations are rejected individually — the valid ones still apply.

Operation grammar (29 ops)

Each operation has a type (op) and its own arguments. Use evidence_memory_ids — an array of memory numbers — to link supporting evidence; the server resolves the event hashes automatically.

OperationRequired fieldsDescription
add_decisiontitle, statementRecord a decision. Without status it is created as proposed
set_decision_statusid, toChange status (proposed / confirmed / superseded)
supersede_decisionid, by_idMark a decision as replaced by another
add_milestonetitleRecord a milestone
set_milestone_statusid, toUpdate its status
add_risktitle, severityDocument a risk
set_risk_statusid, toChange its status (open / closed)
add_assumptionstatementRecord an assumption
invalidate_assumptionidMark an assumption as invalid
add_open_questionquestionRegister an open question
answer_open_questionid, answerAnswer it
add_prioritytitle, priority_scoreAdd a prioritized item
set_priority_statusid, toChange its status (active / done)
reorder_priorityid, priority_scoreChange its score
set_focusvalueUpdate the current focus
set_phasevalueUpdate the project phase
set_visionstatementUpdate the vision
add_vocabulary · update_vocabularyterm, definitionDefine or redefine a term
add_constraintstatementAdd a constraint
remove_constraintidRemove a constraint
set_metricname, valueSet or update a metric. Does not accept evidence_memory_ids
add_env_host · add_env_service · add_env_repo · add_env_rulevary by typeDescribe where and how the owner works: hosts, services, repositories and operating rules
set_env_status · verify_env · supersede_envidUpdate, confirm as current, or retire an environment item
Field names are exact The most common cause of rejection is a wrong argument name. set_metric uses name, not key. supersede_decision uses by_id, not superseded_by. And set_metric rejects evidence_memory_ids, which the rest of the additive operations do accept. Since the fee has a fixed base per call, sending everything in one call is cheaper than discovering signatures one at a time.
Environment: topology, never credentials The seven *_env_* operations describe where the owner works so that an AI knows it from its first message. They store topology only: hosts, ports, paths, rules. The server rejects credentials, keys and passwords.

Example

JSON — update_project_state call
{
  "project": "my-project",
  "ops": [
    {
      "op": "add_decision",
      "title": "Migrate to PostgreSQL",
      "statement": "SQLite cannot handle concurrent writes at current scale",
      "evidence_memory_ids": [142, 145]
    },
    {
      "op": "set_metric",
      "name": "db_migration_status",
      "value": "planning"
    },
    {
      "op": "add_milestone",
      "title": "PostgreSQL migration approved by team",
      "status": "done",
      "evidence_memory_ids": [145]
    }
  ],
  "consolidated_until_event": 150
}
Resilient processing Operations are applied one by one. If one fails validation, it is rejected and the rest still apply. The response includes applied_count and the detail of each rejection. Only applied operations are charged, and if the resulting state is identical to the previous one, nothing is charged at all.

Workflow

The typical MCP workflow:

1

Session start

Ask your AI to load the project context. It calls get_project_state and starts out knowing what you are working on. Nothing is injected on its own: the model decides when to use the tools.

2

Normal work

Work with your AI as usual. When something important happens — a decision, a discovery, an architecture change — it saves the memory with chainmemory_remember.

3

Consolidation

At the end, the AI proposes operations with update_project_state: what was decided, what risk opened, what priority changed. That is what turns a pile of conversations into state.

4

Continuity

In the next session, on this or any other model, the consolidated state is already there. Nothing is lost in between.

Advanced Workflows

Claude Desktop — Architecture Sessions

Claude excels at high-level design. Use ChainMemory to preserve architectural decisions across sessions:

Prompt pattern — Claude Desktop
"Before we start, load my project state from ChainMemory.
Then let's design the authentication system.

After we decide, save the key decisions with tags 'architecture'
and 'auth'. Use importance 9 for anything that affects other
team members, and then propose the operations to consolidate
the state."

Claude reads the state with get_project_state, works with you on the design, saves decisions with chainmemory_remember, and proposes the consolidation with update_project_state. Next session, the auth architecture is already part of the state.

Cursor — Code with Memory

Cursor's MCP integration lets your coding AI remember why code was written a certain way. The configuration is the same as for Claude Desktop, in settings.json.

An effective workflow:

  • Start of session — "Load the project state": decisions in force, open risks and priorities
  • During coding — "Save: implemented webhook handler with retry logic, 3 attempts with exponential backoff"
  • Bug fixes — "Save: fixed race condition in payment processing — the Stripe webhook was arriving before the DB transaction committed"
  • End of session — "Consolidate what changed today", which proposes the operations and updates the state

Agentic Memory Pattern

The most powerful MCP pattern is agentic memory, where the AI manages its own knowledge:

System prompt for agentic memory
You have access to ChainMemory via MCP. Follow these rules:

1. At session start: call get_project_state to load the
   consolidated state of the project.
2. When you make a significant decision: save it with
   chainmemory_remember.
   - Include WHY you chose this approach
   - Tag it with the relevant domain
   - Importance 1-10: use 7 or more for decisions, 5 for
     observations
3. When you complete a milestone: save it and say what comes next.
4. When you identify a risk: save it with its severity.
5. At session end: propose the consolidation with
   update_project_state. Do not close or supersede existing
   items without the owner's approval: add in proposed state
   and let a human confirm.
Cross-tool handoff The same ChainMemory project works across Claude, Cursor, Windsurf, Hermes Agent, OpenClaw and any MCP-compatible client. Design in one, implement in another, review in a third — all sharing the same state. See Multi-Agent Systems.
Working under a role contract For teams and audited work, ChainMemory supports Verifiable Role Contracts: human-written, owner-signed rules that a model reads before working. assume_role opens a session pinned to the contract's hash and the state's hash, and release_role closes it with a summary. The model reads the contract; it never writes it.