MCP recall with search_type=CHUNKS runs an LLM session-turn analysis before retrieval — 19s instead of 0.3s (no only_context on MCP)

Summary

The official Cognee MCP recall tool is unexpectedly slow for search_type=CHUNKS because it performs an LLM-based session-turn analysis before the actual retrieval. On our stock v1.4.2 deployment, the vector search itself takes ~0.2-0.5s, but MCP recall takes ~15-24s.

The core issue appears to be that the MCP recall tool does not expose only_context, so it calls /api/v1/recall with only_context=false. BaseRetriever defaults supports_session_turn_preparation=True, and ChunksRetriever does not override it, so a CHUNKS recall first runs prepare_session_turn_for_retrieval() including an LLM chat-completion before the retrieval.

Environment

• Cognee API image: cognee/cognee:1.4.2
• Cognee MCP image: cognee/cognee-mcp:1.4.2
• Deployment: self-hosted Docker, stock/manufacturer release behavior
• Source check: installed files SHA-identical to tag v1.4.2
• Checked 2026-08-12: no existing issue found that covers this exact MCP/CHUNKS/only_context/session-turn-preparation latency path; main still appears unfixed.

Measured evidence

Measured on srv:

• /api/v1/search CHUNKS with only_context=true: 0.26-0.37s
• /api/v1/recall CHUNKS with only_context=true: 0.26-0.37s
• Same paths without only_context: 16.3-22.6s
• Full MCP recall tool call: 15.6-24.0s
• Actual chunk search according to API log: 0.21-0.46s

One concrete timing sample:

• MCP accepted the call at 06:44:44.740Z
• The chunk search started at 06:45:03.875Z
• That is about 19 seconds of pre-retrieval work before the actual fast CHUNKS search.

LiteLLM logs confirm an LLM call before the vector search on this path.

Expected behavior

CHUNKS retrieval should be retrieval-only / non-generative. The docs describe CHUNKS as a retrieval-only path, and in practice only_context=true makes it fast and deterministic.

MCP recall with search_type=CHUNKS should therefore not run LLM session-turn analysis before retrieval, or the MCP tool should expose an only_context parameter so callers can request the documented retrieval-only behavior explicitly.

Actual behavior

MCP recall for search_type=CHUNKS does not expose only_context. It effectively takes the /api/v1/recall path with only_context=false, which triggers prepare_session_turn_for_retrieval() through the default retriever behavior.

Because ChunksRetriever does not opt out of session-turn preparation, the request performs an LLM chat-completion before running the actual vector search. This makes a sub-second retrieval path take ~16-24 seconds.

Likely root cause

• MCP recall tool has no only_context parameter.
• It calls /api/v1/recall with only_context=false.
• BaseRetriever defaults supports_session_turn_preparation=True.
• ChunksRetriever does not override supports_session_turn_preparation.
• Therefore CHUNKS recall does the session-turn preparation step before retrieval.

Suggested fixes

Either of these would solve the practical issue; both would be ideal:

1. Set deterministic/non-generative retrievers such as ChunksRetriever to opt out of session-turn preparation, analogous to CodeRetriever:

supports_session_turn_preparation = False

1. Expose only_context on the MCP recall tool and pass it through to the API recall call.

Why this matters

For agent/client integrations, explicit MCP recall is expected to be the fast retrieval path. The current behavior makes CHUNKS recall look like a slow LLM operation even though the actual vector retrieval is fast, causing large latency regressions in otherwise healthy self-hosted setups.

We are intentionally not patching this locally because we are trying to stay on stock releases and upstream product behavior.