openclaw - 💡(How to fix) Fix [Feature]: GhostCrab MCP + mindBrain SQLite — structured domain navigation for OpenClaw sessions

Summary

GhostCrab MCP + mindBrain db engine for SQLite provides a drop-in replacement for OpenClaw's built-in SQLite memory slot. Instead of a flat keyword/vector index, agents read and write to a structured ontology backend (MindBrain) that supports faceted recall, entity graphs, and cross-agent memory sharing — without leaving your local stack.

Problem to solve

What problem this solves

OpenClaw stores memory in two native layers: Markdown files (MEMORY.md, memory/YYYY-MM-DD.md) as a human-readable source of truth, and a per-agent SQLite index at ~/.openclaw/memory/<agentId>.sqlite for search. That SQLite supports FTS5 (BM25), vector search via sqlite-vec, and hybrid retrieval. It works — but it is flat. An index, not a structured graph.

Facts discovered by one skill invocation are invisible to another agent. Entities exist without typed relationships. Context rebuilt from Markdown on every session. No shared registry across agents. No typed ontology. No phase-level orchestration.

This request adds a ClawHub Skill that gives OpenClaw agents a structured memory backend — either as a drop-in replacement for the native SQLite slot, or as a parallel operational layer that coexists with MEMORY.md.

What a domain looks like in practice

A domain is any bounded context where agents need to reason over structured relationships : not just retrieve text.

mindBrain separates two levels:

Ontology (the model) : the schema of a domain: entity types, relationship types, constraints, vocabularies. Defined once, shared across every skill invocation and every session.

Knowledge Graph (the projected instance) : the populated graph: real entities, real edges, real state : queryable via GhostCrab MCP tools.

Example: multi-agent project delivery

Ontology (model)              Knowledge Graph (instance)
─────────────────             ──────────────────────────
Project                       "Platform Modernization Q3"
└── has Task                  └── Task: "Rotate JWT keys"
      └── status                    status: blocked
      └── depends_on          Task: "Define ERP contract"
      └── assigned_to               assigned_to: DevAgent
Decision                      Decision: "Stateless JWT over Redis"
└── IMPLEMENTS Requirement          IMPLEMENTS: req-auth-perf
Phase                         Phase: BUILDING → readiness_score: 88

An OpenClaw orchestrator reads a graph projection signal PHASE_EXIT_READY — all phase exit criteria met — and calls ghostcrab_phase_advance without scanning MEMORY.md or replaying conversation history. Sub-agents write ghostcrab_entity_update(status="blocked", blocked_by="erp-contract") and the orchestrator receives BLOCKER_RAISED on its next heartbeat tick. No message relay. No re-derivation from logs.

Example: ERP domain

Ontology (model)              Knowledge Graph (instance)
─────────────────             ──────────────────────────
Account                       "Acme Corp" (tier=enterprise)
└── has CostCenter            └── CostCenter: "Engineering"
└── has ApprovalFlow          └── ApprovalFlow: PO > €5k → CFO
GLEntry                       GL-20260501: amount=€12,400
└── linked_to CostCenter            linked_to: "Engineering"

A finance_skill resolving a billing anomaly calls ghostcrab_search(facets={"type": "GLEntry", "cost_center": "Engineering"}). Account structure, approval rules, and GL history are returned as structured records. No keyword search through Markdown notes. No flat FTS5 retrieval from an untyped index. The relationship GL-20260501 → linked_to → CostCenter:Engineering is a first-class edge — traversable, not reconstructed from text.

Example: CRM domain

Ontology (model)              Knowledge Graph (instance)
─────────────────             ──────────────────────────
Account                       "NovaTech" (tier=enterprise)
└── has Contact               └── Contact: "Maria Chen" (VP Engineering)
└── has Deal                  └── Deal: "Platform License" (stage=negotiation)
└── has Interaction           └── Call: 2026-05-14, sentiment=positive
└── has Constraint            └── Constraint: "No multi-year commitment"

A sales_skill calls ghostcrab_get(path="account/novatech") at skill start. Account tier, deal stage, interaction history, and contractual constraint are loaded from the structured registry — not extracted from MEMORY.md by an LLM pass that costs tokens every time.

Example: Customer Support domain

Ontology (model)              Knowledge Graph (instance)
─────────────────             ──────────────────────────
Ticket                        TK-9821: priority=critical
└── linked_to Component       └── linked_to: "Auth Service"
└── references Incident       └── Incident: "JWT outage 2026-04-30"
KnownIssue                    KI-44: "Token expiry on clock skew"
└── affects Component               affects: "Auth Service"
└── has Resolution            Resolution: "Force clock sync + rolling restart"

A support_skill calls ghostcrab_search(facets={"type": "KnownIssue", "component": "Auth Service"}). The known issue and its resolution surface immediately — across sessions, without re-ingesting knowledge base articles every run. An orchestrator agent can validate the fix by traversing the graph: TK-9821 → references → Incident → linked_to → KnownIssue → has Resolution.

The meta-ontology: where mindBrain becomes strategic

Each domain above is useful alone. The real leverage is connecting them.

         ERP ←──────────────────┐
                                 │
         CRM ←─────── mindBrain ─┼──→ Project Management
                                 │
         Support ←───────────────┘
                                 │
                                 └──→ Knowledge / Documentation

A single OpenClaw agent working on a cross-domain task — say, an enterprise renewal involving a billing dispute, an open critical support ticket, and a stalled deal — calls ghostcrab_search across all four domains from the same workspace.

OpenClaw continues to own conversational context via MEMORY.md. MindBrain owns operational context: typed entities, relationships, phase progression, and cross-domain links.

That is the clean boundary: MEMORY.md stores what was said. MindBrain stores what is true and how things relate.

Two components, one integration

mindBrain (SQLite : Personal edition — local-first)

The data layer. Runs beside the OpenClaw agent runtime. A single local file. It organizes domain knowledge into three constructs:

• Facets : typed dimensions — status, type, phase, project, entity, component, tier, ...
• Semantic graphs : named typed relations — DEPENDS_ON, LINKED_TO, IMPLEMENTS, AFFECTS, VALIDATES, ...
• Projections (the graph projection layer) : pre-computed orchestrator views — phase readiness, blocker queue, agent staleness, entity completion — surfaced at zero inference cost

GhostCrab MCP

The gateway layer, registered as a standard MCP server in OpenClaw's mcp.servers config. Exposes three GhostCrab tools that map directly to OpenClaw's native memory primitives:

Why this goes through ClawHub, not a core PR

The OpenClaw contribution model is explicit: third-party integrations go through Skills published on ClawHub (clawhub.ai), not through PRs to the main repository. The VoltAgent/awesome-openclaw-skills list is the community's visible catalog.

This request adds the ghostcrab-mcp Skill to ClawHub and an entry to awesome-openclaw-skills. No changes to OpenClaw core, agent execution, or skill invocation model.

Two installation modes

Mode 1 — Replace native SQLite memory (full structured backend)

{
  "plugins": {
    "slots": {
      "memory": "none"
    }
  },
  "mcp": {
    "servers": {
      "ghostcrab": {
        "url": "http://localhost:PORT/mcp",
        "transport": "streamable-http"
      }
    }
  }
}

plugins.slots.memory: "none" disables the native SQLite backend. GhostCrab becomes the sole memory layer — structured, faceted, graph-traversable. MEMORY.md files are no longer written.

Mode 2 — Parallel operational layer (coexists with MEMORY.md)

{
  "mcp": {
    "servers": {
      "ghostcrab": {
        "url": "http://localhost:PORT/mcp",
        "transport": "streamable-http"
      }
    }
  }
}

OpenClaw keeps MEMORY.md for conversational context. GhostCrab holds structured project state, entity graphs, and phase projections. Both layers coexist — the agent chooses which to query based on context type.

This is the recommended path for migration: start with Mode 2, move to Mode 1 once the ontology schema is stable.

Local binary (stdio, zero network dependency)

{
  "mcp": {
    "servers": {
      "ghostcrab": {
        "command": "ghostcrab-mcp",
        "args": ["--db", "${GHOSTCRAB_DB_PATH}"]
      }
    }
  }
}

Skill frontmatter (ClawHub format)

---
name: ghostcrab-mcp
version: 1.0.0
description: "Ontology-based structured memory backend for OpenClaw via GhostCrab MCP"
homepage: https://github.com/mindflight-orchestrator/ghostcrab-personal-mcp
openclaw:
  memoryBackend: external
  disablesBuiltin:
    - memory-core          # only when Mode 1 is selected
  slots:
    memory: ghostcrab
requires:
  env:
    - GHOSTCRAB_URL
    - GHOSTCRAB_TOKEN      # optional
---

disablesBuiltin: [memory-core] explicitly signals to OpenClaw that this Skill takes over the native memory slot — required for ClawHub scanner approval.

→ Full Skill files, runtime guide, and architect onboarding: https://github.com/mindflight-orchestrator/ghostcrab-personal-mcp/blob/main/ghostcrab-integrations/openclaw/SKILL_openclaw_ghostcrab_mindbrain.md

https://github.com/mindflight-orchestrator/ghostcrab-personal-mcp/blob/main/ghostcrab-integrations/openclaw/SKILL_openclaw_ghostcrab-runtime.md

What MindBrain adds that native OpenClaw SQLite does not

Scope of this request

• Publishes ghostcrab-mcp Skill to ClawHub (clawhub.ai)
• Adds an entry to VoltAgent/awesome-openclaw-skills under Database / Knowledge Graph
• No changes to OpenClaw core, agent execution, or skill invocation model
• Compatible with local stdio binary and streamable-http deployed server

Proposed solution

Two installation modes

Mode 1 — Replace native SQLite memory (full structured backend)

{
  "plugins": {
    "slots": {
      "memory": "none"
    }
  },
  "mcp": {
    "servers": {
      "ghostcrab": {
        "url": "http://localhost:PORT/mcp",
        "transport": "streamable-http"
      }
    }
  }
}

plugins.slots.memory: "none" disables the native SQLite backend. GhostCrab becomes the sole memory layer — structured, faceted, graph-traversable. MEMORY.md files are no longer written.

Mode 2 — Parallel operational layer (coexists with MEMORY.md)

{
  "mcp": {
    "servers": {
      "ghostcrab": {
        "url": "http://localhost:PORT/mcp",
        "transport": "streamable-http"
      }
    }
  }
}

OpenClaw keeps MEMORY.md for conversational context. GhostCrab holds structured project state, entity graphs, and phase projections. Both layers coexist — the agent chooses which to query based on context type.

This is the recommended path for migration: start with Mode 2, move to Mode 1 once the ontology schema is stable.

Local binary (stdio, zero network dependency)

{
  "mcp": {
    "servers": {
      "ghostcrab": {
        "command": "ghostcrab-mcp",
        "args": ["--db", "${GHOSTCRAB_DB_PATH}"]
      }
    }
  }
}

Alternatives considered

There is not (yet) a database with this engine that allows for the cross-referencing of dimensions (facets) with graphs (semantic edges) and an internal query system (projections) that is pre-calculated. Agents no longer search; they navigate maps and receive the most requested views instantly. This enables better context management and faster (instantaneous) response times.

Impact

When an agent needs to understand the context of a specific system (ERP, CRM, etc.) or a knowledge base. When different agents need to collaborate, they can share a knowledge graph (such as a project management plan or a procedure to follow). With the history feature, the agent can return to the task three months later and know exactly where they left off and why.

Evidence/examples

No response

Additional information

No response