Add MCP stdio provider for warm-connection benchmarks

[bm-clawd]

Problem

The bm-local provider spawns a new bm tool search-notes CLI subprocess per query. On the full LoCoMo run (1,982 queries), this produces 2,948ms mean latency vs Mem0's 229ms — because each call cold-starts Python, opens SQLite, runs the search, and exits.

Mem0's provider keeps a warm Memory() instance across all queries, which is a fairer comparison to how BM is actually used in production (persistent MCP server).

Proposal

Add a bm-mcp provider that:

1. Spawns bm mcp once via stdio transport at the start of the run
2. Sends search_notes tool calls over the MCP protocol
3. Keeps the connection warm for all queries
4. Tears down on cleanup

This matches real-world usage (OpenClaw plugin, Claude Desktop) and should bring latency to 200-400ms range.

The existing bm-local CLI provider should stay as-is — it's the most reproducible option (anyone with bm installed can run it).

Benchmark evidence

Full LoCoMo run (locomo-full-20260226T055634Z):

Provider	Mean ms	P95 ms
bm-local (CLI)	2,948	3,195
mem0-local (warm)	229	321

[phernandez]

Implemented in 3c1265f.

What changed

Replaced bm-local internals with a warm MCP stdio session (single basic-memory mcp process per provider run) while keeping the provider name the same.

• bm-local now starts one long-lived MCP session and sends search_notes tool calls over stdio for all queries.
• Kept existing project lifecycle behavior (project add + reindex) and project reuse logic.
• Added MCP result normalization for both:
  • structuredContent.result wrapper format
  • text JSON payload fallback
• Added index-readiness gate using bm status --json when supported.
• Added command-path routing so --bm-local-path is actually used for all BM commands/MCP startup:
  • uv run --project <bm-local-path> basic-memory ...
• Provider metadata now includes:
  • bm_transport (mcp-stdio)
  • bm_status_json_supported
  • bm_command (when local path override is used)

Benchmark evidence

Dataset/config for comparisons: locomo-c1-quick25 (same query set + scoring rules).

Before (CLI subprocess per query)

Run: e2d77a99fe38

• bm-local official headline: Recall@5=0.825, Recall@10=0.95, MRR=0.675
• Latency: mean=3196.994ms, p95=3280.156ms

After (warm MCP stdio)

Run: d147cd5089e2

• bm-local official headline: Recall@5=0.825, Recall@10=0.95, MRR=0.675 (unchanged)
• Latency: mean=195.243ms, p95=225.758ms

Latency improvement for BM on this run:

• Mean: ~16.37x faster
• P95: ~14.53x faster

With local BM checkout + status JSON enabled

Run: 51f5eb6d3cf8

• bm_local_path=/Users/phernandez/dev/basicmachines/basic-memory
• Provider metadata confirms:
  • bm_status_json_supported=true
  • bm_command="uv run --project /Users/phernandez/dev/basicmachines/basic-memory basic-memory"

Notes

• This keeps mem0-local unchanged and preserves fairness constraints (same query set, K, and scoring).
• Full LoCoMo run can now be re-executed with this warm provider path for final headline numbers.