redis / redis/agent-memory-server

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

Open
#253 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
316
Forks
63
Avg merge
14d 23h
Merged PRs (30d)
1

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing _resolve_search_memory(), FastMCP.call_tool(), memory_prompt, search_long_term_memory, get_working_memory, and hydrate_memory_prompt() against SearchRequest and the REST behavior. Run the existing MCP and client tests, then add regression coverage for retrieval controls, namespace scoping, and memory_prompt modes. Done means the stated MCP, tool-resolution, and client paths accept and forward the same controls, with missing REST capabilities documented or implemented.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, redis
Domain
api, backend, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.