Align MCP and LLM-facing client surfaces with core search and memory_prompt capabilities

[vishal-bala]

Problem

The core Agent Memory Server supports a richer retrieval surface than the MCP layer and some higher-level client entry points. SearchRequest now supports keyword/hybrid search, episodic event_date filters, recency-aware reranking, and server-side recency options, but MCP wrappers and LLM tool-resolution paths still expose or forward only an older subset.

This creates silent behavior drift: MCP-first agents and LLM tool calls appear to support newer retrieval modes, but frequently fall back to semantic-only behavior or cannot express the newer modes at all.

Confirmed gaps

• search_memory tool schema advertises search_mode, hybrid_alpha, text_scorer, offset, and optimize_query, but _resolve_search_memory() drops them before calling search_memory_tool().
• MCP memory_prompt does not accept search_mode, hybrid_alpha, or text_scorer, and also omits event_date, recency params, and server_side_recency when constructing SearchRequest.
• MCP search_long_term_memory exposes hybrid params but still omits event_date, recency params, and server_side_recency.
• FastMCP.call_tool() still injects default namespace for hydrate_memory_prompt instead of memory_prompt.
• MCP memory_prompt always constructs long_term_search, so it cannot express:
  • session-only prompt hydration
  • the REST long_term_search=True shortcut
  • a cleaner separation between working-memory session scope and long-term search session filters
• MCP get_working_memory lacks namespace, user_id, model_name, and context_window_max, and its not-found behavior differs from REST.
• Entire REST capabilities have no MCP equivalent today:
  • forgetting
  • list sessions
  • delete working memory
  • summary-view CRUD/run/list
  • task status
• hydrate_memory_prompt() in the Python client also lags the core search surface and cannot express hybrid/event-date/recency controls.

Impact

• LLMs requesting keyword or hybrid retrieval through tool resolution silently get semantic search instead.
• MCP agents cannot use episodic/event-date filtering or recency-aware retrieval that REST already supports.
• Namespaced MCP transports may fail to auto-scope memory_prompt.
• MCP-first consumers cannot access some important server features at all, especially forgetting and summary-view/task workflows.
• Test coverage is concentrated on direct REST/client search methods, so parity regressions in MCP and hydration/tool-resolution layers can slip through.

Proposed solution

• Treat MCP wrappers as thin adapters over SearchRequest and MemoryPromptRequest rather than hand-maintained parameter subsets.
• Bring MCP search_long_term_memory and memory_prompt to full SearchRequest parity:
  • search_mode
  • hybrid_alpha
  • text_scorer
  • event_date
  • recency_*
  • server_side_recency
• Fix namespace injection to target memory_prompt.
• Extend MCP memory_prompt so it can represent REST’s three modes cleanly:
  • session only
  • default long-term search (true)
  • explicit long-term search payload
• Decide whether MCP get_working_memory should match REST semantics or remain a documented convenience tool with intentional differences.
• Add MCP equivalents for the currently missing REST features, or explicitly document them as out of scope if that is intentional.
• Update Python docs/examples to match the actual client API and hydration surface.

Acceptance criteria

• MCP and REST accept the same retrieval controls for search and prompt hydration.
• Tool-resolution and convenience client paths forward the same parameters they advertise.
• Namespaced MCP transports scope memory_prompt correctly.
• Regression tests cover hybrid, recency, episodic filters, and memory_prompt mode selection across MCP and client tool-resolution/hydration paths.