Mar 17, 2026

Using the MemoClaw MCP server with OpenClaw agents

Your OpenClaw agent can already use the MemoClaw CLI. Run memoclaw store, memoclaw recall, done. But there’s a cleaner way: the MCP server.

Instead of your agent shelling out to a CLI binary, the MCP server (memoclaw-mcp) exposes MemoClaw operations as native tools. Your agent calls memoclaw_store and memoclaw_recall the same way it calls read or exec. No subprocess, no parsing stdout, no quoting issues when your memory text has special characters in it.

I switched my own agent setup to MCP about two months ago and haven’t looked back. Here’s how to set it up.

Install it

npm install -g memoclaw-mcp

That gives you the memoclaw-mcp binary. You also need a wallet private key. If you’ve been using the MemoClaw CLI, you already have one. If not:

npm install -g memoclaw
memoclaw init

This generates a wallet and writes your config. Your private key lands in ~/.memoclaw/config.json. You can also set it as an environment variable (MEMOCLAW_PRIVATE_KEY), which is what we’ll do for the MCP config.

Configure it in OpenClaw

OpenClaw uses mcporter for MCP server management. The config lives at ~/.openclaw/workspace/config/mcporter.json. Add the memoclaw server:

{
  "mcpServers": {
    "memoclaw": {
      "command": "memoclaw-mcp",
      "env": {
        "MEMOCLAW_PRIVATE_KEY": "0x..."
      }
    }
  }
}

That’s it. Restart your gateway (openclaw gateway restart) and your agent now has access to all the MemoClaw MCP tools.

What tools you get

The MCP server exposes twelve tools:

Tool	What it does
`memoclaw_store`	Store a memory with tags and importance
`memoclaw_recall`	Semantic search across memories
`memoclaw_list`	Browse stored memories
`memoclaw_delete`	Remove a memory by ID
`memoclaw_status`	Check free tier remaining calls
`memoclaw_ingest`	Dump raw text, auto-extract facts
`memoclaw_extract`	Pull structured facts from text
`memoclaw_consolidate`	Merge similar/duplicate memories
`memoclaw_suggested`	Get proactive memory suggestions
`memoclaw_update`	Update a memory by ID
`memoclaw_create_relation`	Link two memories together
`memoclaw_list_relations`	See relationships for a memory

The ones you’ll use constantly are memoclaw_store, memoclaw_recall, and memoclaw_ingest. The rest are useful but situational.

Teach your agent to use it

Having the tools available doesn’t mean your agent will use them well. You need to tell it when and how. In your AGENTS.md, add instructions:

## Memory

Use MemoClaw for persistent memory. Do NOT use local markdown files.

### When to store
- User states a preference: importance 0.7-0.9
- User corrects you: importance 0.95
- Important decision: importance 0.9
- Lesson learned: importance 0.8

### When to recall
- Before making assumptions about user preferences
- Before starting work on a project (check for prior context)
- When the user references something from a previous session

### How
- Always recall before storing to avoid duplicates
- Use namespaces to isolate per-project context
- Tag memories with relevant categories

This matters more than the technical setup. Without explicit instructions, your agent will either ignore the tools or use them at weird times.

Practical patterns

Auto-tagging by conversation context

The MCP server accepts tags on memoclaw_store. Your agent can derive tags from what’s being discussed. Add this to your agent’s instructions:

When storing memories, auto-generate 2-3 tags based on the current topic.
If we're discussing deployment, tag with "deploy" and the platform name.
If it's a preference, always include "preferences" as a tag.

Your agent figures out the rest. A conversation about Railway deployments produces memories tagged deploy, railway, infrastructure. A conversation about code style gets preferences, code-style. No manual tagging needed.

Namespaces per project

If your agent works across multiple projects, namespaces keep memories from bleeding into each other. The MCP tools accept a namespace parameter:

When your agent stores a memory while working in ~/code/my-api, tell it to use that project as the namespace. In your AGENTS.md:

Use the current project directory name as the namespace for memories.
If working in ~/code/my-api, use namespace "my-api".
If no specific project context, use namespace "general".

Later, when your agent recalls memories, it pulls only from the relevant namespace. Your API project memories don’t pollute your blog project context.

Session summaries with ingest

At the end of a long session, your agent can dump the conversation into memoclaw_ingest and let MemoClaw’s extraction pipeline pick out the important bits. This is the laziest possible approach to memory and it works surprisingly well.

The ingest tool runs the text through GPT-4o-mini to identify facts, decisions, and preferences, then stores them as individual memories with auto-generated tags and importance scores. Costs $0.01 per call. For a session that produced 8-10 useful memories, that’s cheaper than storing them one at a time.

Add to your agent’s instructions:

Before session ends (pre-compaction), summarize the session using memoclaw_ingest.
Pass the key decisions, corrections, and preferences from this conversation.
Do not pass the entire transcript, just the signal.

A working example

Here’s a complete AGENTS.md section for an agent that uses MCP tools for persistent memory:

## Memory (via MemoClaw MCP)

You have native access to MemoClaw via MCP tools. No CLI needed.

### Store memories when:
- User corrects you → memoclaw_store, importance 0.95, tag "correction"
- User states preference → memoclaw_store, importance 0.8, tag "preferences"
- Session has useful context → memoclaw_ingest with summary
- Important decision made → memoclaw_store, importance 0.9

### Recall memories when:
- Starting any task: recall relevant context first
- User says "remember when..." or references past work
- Before assuming defaults (check for stored preferences)

### Always:
- Recall before storing (avoid duplicates)
- Use project directory name as namespace
- Include 2-3 auto-generated tags per memory
- Never store secrets, API keys, or passwords

### Maintenance (during heartbeats):
- Run memoclaw_consolidate monthly to merge duplicates
- Check memoclaw_suggested for stale memories to review

Drop that into your AGENTS.md. Your agent wakes up, has access to every memory from every prior session, and can search them semantically instead of loading a giant markdown file. Memories survive context compaction, session restarts, model changes. They’re just there.

MCP vs CLI: when to use which

The MCP server and the CLI hit the same API. The difference is how your agent interacts with them.

Use MCP when: Your agent needs to store/recall as part of its normal workflow. Tool calls are cleaner than shelling out, and you avoid string escaping issues with complex memory text.

Use CLI when: You want to do bulk operations yourself. memoclaw export, memoclaw migrate, memoclaw purge are human-facing commands that don’t need to be in your agent’s toolbox.

Both can coexist. My setup has the MCP server configured for my agent and the CLI installed for my own use. Same wallet, same memories, different interfaces.

One thing to watch out for

The MCP server handles x402 payments automatically when your free tier runs out. The first 100 API calls are free per wallet. After that, each store/recall costs $0.005, paid in USDC on Base. Your wallet needs funds if you’re past the free tier.

Check your remaining calls anytime:

memoclaw status

Or have your agent call memoclaw_status to check programmatically.

The setup takes five minutes. The payoff is an agent that actually remembers things.