Context
The plugin exposes the same capability (recall org memory; query the code graph) through three different mechanisms, one per agent-runtime extension model:
- claude-code / codex / cursor — a PreToolUse hook intercepts
grep/cat on the ~/.deeplake/memory/ mount and rewrites it to SQL (the "virtual filesystem" trick). No MCP. Evidence: src/hooks/pre-tool-use.ts (imports grep-direct, handleGraphVfs); src/cli/install-cursor.ts:48 ("rewrites grep/rg against the memory mount").
- hermes — a real MCP server for memory recall (
hivemind_search/read/index), installed via src/cli/install-hermes.ts:196 (ensureMcpServerInstalled) + config.yaml mcp_servers. Plus a terminal-tool intercept for the graph.
- openclaw / pi — native plugin API (
registerTool via definePluginEntry), reimplementing the same tools by hand. Evidence: openclaw/src/index.ts:953,1049,1087.
Problem
Three mechanisms for one capability = maintenance tax, inconsistent coverage, and adding any feature (e.g. the code graph) means deciding per-agent how to wire it. Today only 4/6 agents can query the graph; pi/openclaw cannot.
Proposal to investigate
Converge the tool surface onto the shared MCP server (mcp/bundle) where agents support MCP, keeping the hook-intercept only as the "feels-like-a-filesystem" UX sugar / fallback. MCP is the standard, discoverable, first-class path — and the only thing pi/openclaw could share with the others instead of native reimplementations.
Investigate:
- Which of the 6 runtimes can connect to an MCP server today, and how mature.
- Whether the graph endpoints (
find/query/show/neighborhood/impact/path/tour) can be exposed as MCP tools backed by handleGraphVfs.
- What can be deleted (per-agent hook intercepts, native
registerTool reimplementations) vs what must stay (the filesystem-style cat UX over the memory mount).
- Migration risk + per-agent fallback.
Non-goal
Do not add MCP as a fourth mechanism just for the graph. Either converge, or leave as-is.
Filed from the code-graph cross-agent audit (Python cross-file resolution PR).
Context
The plugin exposes the same capability (recall org memory; query the code graph) through three different mechanisms, one per agent-runtime extension model:
grep/caton the~/.deeplake/memory/mount and rewrites it to SQL (the "virtual filesystem" trick). No MCP. Evidence:src/hooks/pre-tool-use.ts(importsgrep-direct,handleGraphVfs);src/cli/install-cursor.ts:48("rewrites grep/rg against the memory mount").hivemind_search/read/index), installed viasrc/cli/install-hermes.ts:196(ensureMcpServerInstalled) +config.yaml mcp_servers. Plus aterminal-tool intercept for the graph.registerToolviadefinePluginEntry), reimplementing the same tools by hand. Evidence:openclaw/src/index.ts:953,1049,1087.Problem
Three mechanisms for one capability = maintenance tax, inconsistent coverage, and adding any feature (e.g. the code graph) means deciding per-agent how to wire it. Today only 4/6 agents can query the graph; pi/openclaw cannot.
Proposal to investigate
Converge the tool surface onto the shared MCP server (
mcp/bundle) where agents support MCP, keeping the hook-intercept only as the "feels-like-a-filesystem" UX sugar / fallback. MCP is the standard, discoverable, first-class path — and the only thing pi/openclaw could share with the others instead of native reimplementations.Investigate:
find/query/show/neighborhood/impact/path/tour) can be exposed as MCP tools backed byhandleGraphVfs.registerToolreimplementations) vs what must stay (the filesystem-stylecatUX over the memory mount).Non-goal
Do not add MCP as a fourth mechanism just for the graph. Either converge, or leave as-is.
Filed from the code-graph cross-agent audit (Python cross-file resolution PR).