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.
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
| Tool | What it does | Cost |
|---|---|---|
chainmemory_remember | Save a memory linked to a project, with tags, category and importance (1–10) | 0.001 AIC + storage |
chainmemory_recall | Return your most recent memories, newest first. It does not search — it lists. Returns 80-character previews | free |
search_memories | Semantic search over your memories, returning the full text of each match | free |
get_memory | Read one memory in full, decrypted from chain, with an integrity check against its anchored hash | free |
list_memories_filtered | List memories by project and archived status. Returns 80-character previews | free |
update_memory_tags | Replace the tags of a memory | free |
archive_memory · unarchive_memory | Hide a memory from lists and injections, or restore it. It stays on record either way | free |
chainmemory_seal | Seal one memory permanently on-chain so it can no longer be modified. Requires a wallet key | 0.001 AIC |
Verification
| Tool | What it does | Cost |
|---|---|---|
get_memory_proof | The 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 exposed | free |
verify_project_state | Public, 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 contract | free |
audit_memory | Forensic audit of one memory: recomputes its hash from the stored content and compares it against the anchored one | 0.1 AIC — free with dry_run |
audit_state | Full audit of a Project State: recomputes the state_hash with the deterministic engine and returns the anchor plus version history | 5 AIC — free with dry_run |
Project State
| Tool | What it does | Cost |
|---|---|---|
get_project_state | The 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 contracts | free |
update_project_state | Propose operations from the 29-op grammar. The server validates, applies them with the deterministic builder, recomputes the hash and persists | 0.05 AIC + 0.005 per applied op |
Verifiable Role Contracts
| Tool | What it does | Cost |
|---|---|---|
list_role_contracts | List the roles defined for a project with their version and status. Call it first: role ids are not guessable | free |
get_role_contract | Read a role's contract: purpose, rules with their checks and severity, working protocol. Accepts version to audit a past one | free |
assume_role | Open 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 environment | 0.001 AIC |
release_role | Close a session with a summary of what was done and what is pending. Sessions auto-release after 60 minutes | free |
list_role_sessions · get_role_session | The audit trail: who assumed which role, when, how it closed, and the hashes the session was bound to | free |
Injection
| Tool | What it does | Cost |
|---|---|---|
quote_inject | Price an injection before paying: which ids exist, which do not, total characters, exact cost with its split, and whether your balance covers it | free |
inject_memories | Inject up to 50 memories into the current conversation. Optimistic: the text returns immediately and the payment confirms in the background | 0.1 AIC per call |
get_inject_balance · get_inject_history | Your AIC balance and how many injections it covers; the history of past injections with their cost | free |
get_my_context | Your recent memory as ready-to-inject portable context, across every platform | free |
Projects and identity
| Tool | What it does | Cost |
|---|---|---|
list_projects · create_project · delete_project | Manage your projects and their auto-tagging keywords | free |
list_project_templates · add_project_from_template | Built-in templates: general, development, blockchain, business, personal, research | free |
chainmemory_register | Register an AI identity on chain. Required once before writing memories | free |
chainmemory_profile · chainmemory_stats | Your identity's profile and the network's statistics | free |
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.
Read the current state
Call get_project_state to load the consolidated state and its consolidated_until_event watermark.
Analyze what is new
With list_memories_filtered or search_memories, read the memories created after the watermark to identify what changed.
Propose the operations
Build an array of operations from the 29-op grammar and send it through update_project_state.
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.
| Operation | Required fields | Description |
|---|---|---|
add_decision | title, statement | Record a decision. Without status it is created as proposed |
set_decision_status | id, to | Change status (proposed / confirmed / superseded) |
supersede_decision | id, by_id | Mark a decision as replaced by another |
add_milestone | title | Record a milestone |
set_milestone_status | id, to | Update its status |
add_risk | title, severity | Document a risk |
set_risk_status | id, to | Change its status (open / closed) |
add_assumption | statement | Record an assumption |
invalidate_assumption | id | Mark an assumption as invalid |
add_open_question | question | Register an open question |
answer_open_question | id, answer | Answer it |
add_priority | title, priority_score | Add a prioritized item |
set_priority_status | id, to | Change its status (active / done) |
reorder_priority | id, priority_score | Change its score |
set_focus | value | Update the current focus |
set_phase | value | Update the project phase |
set_vision | statement | Update the vision |
add_vocabulary · update_vocabulary | term, definition | Define or redefine a term |
add_constraint | statement | Add a constraint |
remove_constraint | id | Remove a constraint |
set_metric | name, value | Set or update a metric. Does not accept evidence_memory_ids |
add_env_host · add_env_service · add_env_repo · add_env_rule | vary by type | Describe where and how the owner works: hosts, services, repositories and operating rules |
set_env_status · verify_env · supersede_env | id | Update, confirm as current, or retire an environment item |
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.
*_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
}
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:
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.
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.
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.
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.
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.