Summary

The config schema for memory.qmd.searchMode only accepts a fixed set of values (search, vsearch, query), but qmd-manager maps these to mcporter tool names internally. QMD's MCP server can register custom tools (like hybrid_search), but there is no way to use them from OpenClaw without patching qmd-manager.

Problem

QMD supports custom MCP tools — for example, we added a hybrid_search tool that performs BM25 + vector + RRF fusion without reranking (critical for CPU-only servers where reranking takes 34-49s per collection).

However, OpenClaw's config validation rejects any searchMode value that isn't in the hardcoded list. The qmd-manager also has a hardcoded mapping from config values to mcporter tool names, so even if validation passed, the tool name wouldn't be forwarded correctly.

To use our custom search mode, we had to patch qmd-manager to:

1. Add "hybrid" to the accepted values
2. Map it to the hybrid_search mcporter tool name

Request

Either:

1. Accept arbitrary string values for searchMode and pass them through to mcporter as tool names (with a fallback/error if the tool doesn't exist)
2. Add "hybrid" as a recognized value since hybrid search (BM25 + vector without reranking) is a common and useful mode
3. Allow a searchTool config option that specifies the exact mcporter tool name to use, bypassing the mapping

Option 1 would be the most flexible and future-proof, allowing QMD extensions and custom search tools to work without requiring OpenClaw patches for each new tool.

Current mapping in qmd-manager

// Hardcoded mapping — no way to extend without patching
switch (searchMode) {
    case "search": toolName = "search"; break;
    case "vsearch": toolName = "vector_search"; break;
    case "query": toolName = "deep_search"; break;
    // No way to add custom modes
}

Environment

• OpenClaw 2026.2.23
• QMD with custom hybrid_search MCP tool
• Linux server, CPU-only