Memory MCP

recall

Retrieve relevant remembered facts for the current task, ranked by relevance, recency, and importance, trimmed to a token budget to avoid context overflow.

Instructions

Retrieve only the most relevant remembered facts for the current task.

Call this at the start of a task instead of asking the user to re-explain context. Returns the top facts ranked by relevance + recency + importance, trimmed to a token budget so you never overflow the context window.

Cross-project discovery

When project_name is omitted (None), recall searches across all projects — not just global memories. Each result includes a project_name field so you can see which project a fact belongs to. This is useful when the user hasn't told you which project they're working on: search broadly, read the project names in the results, and use the correct name for follow-up calls.

How to resolve the project_name

Same as remember: auto-match if unambiguous. If ambiguous (e.g. chat client with no filesystem), call list_projects() and explicitly ask the user which project they want to search, or leave it blank to search everything. Once chosen, lock it for the session.

Args: query: What you need context about (the user's request/topic). project_name: Project name to search within. When given, searches that project's memories plus global memories. When omitted (None), searches across ALL projects (cross-project discovery). top_k: Maximum number of facts to return. token_budget: Optional cap on total tokens of returned facts. tool: Calling tool name (for audit).

Returns a ready-to-inject context_block string plus the structured memories with their ranking signals. Each memory includes its project_name so you can tell which project it belongs to.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "recall"
  }
}

Input Schema

Name	Required	Default
`tool`	No	unknown
`query`	Yes
`top_k`	No
`project_name`	No
`token_budget`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does: it discloses the ranking signals (relevance + recency + importance), the token-budget trimming that prevents context overflow, and the non-obvious scope behavior that omitting project_name searches across ALL projects rather than just global memories. That last point is a genuine behavioral surprise an agent would otherwise get wrong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the reason to call it, then organized under headers that an agent can scan. Mild redundancy: the cross-project behavior is explained in the 'Cross-project discovery' section and again verbatim in the project_name arg entry, costing a few lines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the full decision surface for a 5-param retrieval tool: when to call, what scope is searched by default, how to resolve ambiguity, and what comes back (context_block plus structured memories). An output schema exists, yet the description still orients the agent to the return shape without over-explaining it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does for four of five params: query (the user's request/topic), project_name (given = project + global; omitted = all projects), token_budget (optional cap), and tool (audit). top_k is only glossed as 'Maximum number of facts to return' with no default or range, leaving one gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieve only the most relevant remembered facts') plus the ranking model used to select them. The word 'only' plus the relevance-trimming framing distinguishes it from list_memories (exhaustive) and remember (write), so an agent can pick it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger: 'Call this at the start of a task instead of asking the user to re-explain context.' It also names the escalation path (call list_projects() when the project is ambiguous) and states the fallback (leave blank to search everything). When-to-use and alternatives are both spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server