Plain Text Memory MCP

Overview Schema Source Related Servers Discussions Admin

Recall memory in steps

recall

Read-only

Search persistent repository memory in tracked steps, return only new and linked entities, and record conclusions with the source notes they rest on.

Instructions

Search memory in steps, recording why each search was made.

Each step runs its queries and opens named entities, returning only hits not already returned in this session, plus linked entities not yet opened. Small matching entities are returned whole. With path, notes from MEMORY.ptm.md files in folders covering it rank higher. The last step records a conclusion and the facts it rests on. An unknown session starts a new one. For a single lookup, see search_nodes.

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": {
      "thought": "<thought>",
      "step": "<step>",
      "total_steps": "<total_steps>",
      "next_step_needed": "<next_step_needed>"
    },
    "name": "recall"
  }
}

Input Schema

Name	Required	Description
`open`	No	Exact names of entities to return in full.
`path`	No	Folder or file the task is about, relative to the repo root; notes from memory files covering it rank higher.
`step`	Yes	Number of this step, from 1.
`queries`	No	Up to 3 searches, each in search_nodes query syntax.
`session`	No	Session id from the first step's result; omitted on the first step.
`sources`	No	Notes the conclusion rests on.
`thought`	Yes	Why this step is taken: what is being looked for, and why.
`conclusion`	No	What memory showed, for the last step; required when next_step_needed is false.
`total_steps`	Yes	Estimated number of steps; raised to step when step is larger.
`revises_step`	No	Earlier step of this session that this one corrects.
`next_step_needed`	Yes	Whether another step follows; false ends the recall and requires conclusion.

Output Schema

Name	Required	Description	Default
`hits`	Yes
`seen`	Yes
`step`	Yes
`session`	Yes
`entities`	Yes
`unopened`	Yes
`warnings`	Yes
`relations`	Yes
`total_steps`	Yes
`next_step_needed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses session-scoped deduplication of returned hits, automatic opening of linked entities, whole returns for small matches, path-based ranking, and the conclusion requirement on the final step. These are important behavioral traits not captured by annotations alone.

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

Conciseness5/5

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

The description is compact and front-loads the core behavior. Every sentence adds useful process or routing information, with no filler.

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?

For an 11-parameter, output-schema-backed tool, the description covers the step lifecycle, session handling, deduplication, path ranking, and conclusion recording. It gives an agent enough context to invoke the tool correctly without needing return-value explanations.

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 100%, so parameter documentation is already strong. The description adds integrated meaning by explaining how queries, opens, session, and the final conclusion interact across steps, including that an unknown session starts a new one. It does not add syntax details for every parameter, but it adds workflow semantics beyond isolated field descriptions.

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?

The description states a specific verb and resource: searching memory in recorded steps, with conclusion and source facts. It also explicitly distinguishes this tool from search_nodes for single lookups. An agent can identify the tool's scope without opening the schema.

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

Usage Guidelines4/5

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

It explicitly routes single lookups to search_nodes and explains that an unknown session starts a new one. It also explains the last-step conclusion requirement. It stops short of fully contrasting with open_nodes and stamp_notes, so the alternative guidance is clear but not exhaustive.

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

Deploy Server