Bug: `memory_search` does not filter by `memory_type` parameter

[guolvlin-cn]

Summary

memory_search accepts a memory_type parameter but does not apply it as a filter. The top_k results can contain records of any type regardless of the filter value.

Environment

• Server: https://api.thememoria.ai (production)
• MCP endpoint: POST /mcp (JSON-RPC 2.0)
• Date observed: 2026-06-01

Steps to Reproduce

curl -X POST https://api.thememoria.ai/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"memory_search","arguments":{"query":"verify-skill","memory_type":"working","topK":5}}}'

Expected: Top results all have memory_type === "working"
Actual: Top results include records with memory_type: "procedural" and "episodic" — e.g. an unrelated MOI 报告 work-note (procedural) is returned as the #1 hit for a query that should only match working-type records.

Impact

• Misleading relevance: Search results mix types; agents expecting type-filtered results get wrong data
• Wasted context window: Irrelevant type records consume tokens in the agent's prompt
• Hard to compose workflows: A user wanting only working records for the death-note protocol cannot rely on memory_type filter

Workaround

Clients must apply post-filter:

const filtered = results.filter(m => m.memory_type === expectedType);

Proposed Fix

Apply memory_type as a hard filter at the DB/SQL level (or pre-search index) — do not just use it as a ranking signal.

For hybrid search (vector + keyword), the filter should apply to both retrieval stages.

Related

• Same family as issue Bug: memory_search 偶发无法搜索到刚写入的 working 类型记忆 #210 (memory_search index/sync bugs)
• Combined with Bug: memory_store accepts missing/invalid content and memory_type without validation #211 (missing store validation), this makes the search output essentially untyped and untrustworthy without client-side scrubbing