Setting up memoclaw-mcp for OpenClaw

Your OpenClaw agent wakes up fresh every session. You correct it, it apologizes, and next time it makes the same mistake. If you've been through this loop enough times, you've probably tried MEMORY.md or some other file-based workaround. Those work until they don't.

memoclaw-mcp gives your agent actual memory through MCP tools. Store facts, recall them semantically, and stop repeating yourself. This walkthrough covers the install, the OpenClaw config, and a concrete example where the agent remembers a correction you made yesterday.

What MCP does here

If you're running MCP servers with OpenClaw already, you know the pattern: install a server, add it to your config, and your agent gets new tools. memoclaw-mcp adds four:

• memoclaw_store — save a memory with importance and tags
• memoclaw_recall — semantic search across everything stored
• memoclaw_list — browse stored memories
• memoclaw_delete — remove a memory by ID

No skill install, no SDK code. Your agent calls these like any other MCP tool.

Install

npm install -g memoclaw-mcp

Confirm it's there:

memoclaw-mcp --help

You need Node.js 18+ and an Ethereum wallet. MemoClaw uses wallet-based identity instead of API keys. Your wallet address is your account. No registration.

Wire it into OpenClaw

Edit your OpenClaw MCP config (usually ~/.openclaw/mcp.json or wherever your setup points):

{
  "mcpServers": {
    "memoclaw": {
      "command": "memoclaw-mcp",
      "args": ["--private-key", "0xYOUR_PRIVATE_KEY"]
    }
  }
}

That's the minimum. Your agent now has persistent semantic memory.

If you're working across multiple projects and want memories isolated:

{
  "mcpServers": {
    "memoclaw": {
      "command": "memoclaw-mcp",
      "args": [
        "--private-key", "0xYOUR_PRIVATE_KEY",
        "--namespace", "my-project"
      ]
    }
  }
}

Memories in my-project won't bleed into other namespaces. You can also pass namespace per-call if you'd rather run a single server.

The correction problem

Here's why this matters in practice. Say you ask your agent to write a deployment script, and it uses docker-compose. You correct it: "We switched to Podman last month. Always use podman-compose."

Without memory, that correction lives only in the current session's context window. Tomorrow, the agent writes docker-compose again. You correct it again. And again. And again.

With memoclaw-mcp configured, the flow changes.

Session 1: You correct the agent

You: "Stop using docker-compose. We migrated to Podman. Use podman-compose for all container orchestration."

Your agent, with memoclaw tools available, stores this:

{
  "content": "Team migrated from Docker to Podman. Always use podman-compose, never docker-compose.",
  "importance": 0.95,
  "tags": ["corrections", "tooling", "containers"]
}

High importance because it's a correction. The agent knows corrections matter more than casual preferences.

Session 2: The agent actually remembers

Next day. Fresh session. You ask: "Write me a deployment script for the staging environment."

Before generating anything, the agent calls memoclaw_recall with something like "deployment containers orchestration". It gets back:

{
  "memories": [
    {
      "content": "Team migrated from Docker to Podman. Always use podman-compose, never docker-compose.",
      "importance": 0.95,
      "similarity": 0.87
    }
  ]
}

The script uses podman-compose. No correction needed. The agent remembered because the memory survived outside the session.

What makes this different from MEMORY.md

MEMORY.md loads everything on every session start. 200 lines of preferences, corrections, project context, and random notes all hit the context window whether they're relevant or not.

memoclaw_recall is a semantic search. When the agent needs deployment context, it searches for deployment context. Your pizza topping preferences don't get loaded. The agent pulls what it needs, when it needs it, and the similarity score tells it how relevant each memory actually is.

The other difference: 8,192 characters per memory, vector-embedded. MEMORY.md is a flat text file your agent reads top to bottom. One scales. The other doesn't.

Checking what your agent stored

You can audit memories from the CLI:

npm install -g memoclaw
memoclaw list --private-key 0xYOUR_KEY
memoclaw recall "container tooling" --private-key 0xYOUR_KEY

Useful when you want to see exactly what your agent has been remembering.

Cost

The free tier gives you 100 API calls per wallet. A store costs $0.005. A recall costs $0.005. That's enough to test everything here and run a few real sessions.

After the free tier, MemoClaw uses x402 payments (USDC on Base). A typical day of agent use — maybe 5 stores and 10 recalls — runs about $0.075. Not zero, but a lot less than the token cost of loading a bloated MEMORY.md every session.

Tips from actual usage

Set importance deliberately. Corrections should be 0.9-1.0. Preferences around 0.7-0.8. Casual observations at 0.3-0.5. The recall ranking uses importance as a weight, so this directly affects what your agent retrieves.

Tag consistently. I use corrections, preferences, decisions, and project-specific tags. When your agent recalls with tag filters, the results get much tighter.

One wallet, shared memory. If you run multiple OpenClaw agents with the same wallet, they share a memory pool. Your research agent stores findings, your coding agent recalls them. Use namespaces if you want isolation instead.

Memory size limit is 8,192 characters. This is for discrete facts and decisions, not full documents. If you're trying to store an entire README, you're using it wrong.

The actual setup, summarized

1. npm install -g memoclaw-mcp
2. Add the server block to your OpenClaw MCP config with your private key
3. Your agent now has memoclaw_store and memoclaw_recall as native tools

Three commands, maybe two minutes. The agent starts building memory from there.

---

More on namespaces and batch storage at docs.memoclaw.com.