Recued

memory.search

Read-only

Recall saved facts, decisions, and preferences from earlier sessions that the current conversation never carried, using keyword or meaning-based search.

Instructions

Recall saved KNOWLEDGE from the owner's memory pool — facts, decisions, preferences, product/domain notes the owner or you saved with memory.write. Its job is CROSS-SESSION recall: knowledge from earlier sessions that the current conversation never carried. A truncated entry's full text comes back when you call again with its memory_id. To recall what is saved about a person or a thing, pass about too: it finds notes by their claim, in whatever words or language they were saved. READ match BEFORE USING THE RESULTS — it says how well they actually matched: exact = every word you searched for is present, treat the top result as the answer; relaxed = every meaningful word is present, filler words were dropped, still reliable; loose = NO entry contained all your terms and these merely share some, so treat them as candidates to weigh, never as the answer, and tell the user the match was approximate; semantic = NO entry shared any of your words, so these were found by MEANING alone — check the entry is really about what was asked before relying on it, and say you found it by meaning rather than by wording; claim = each note's claim names what you passed in about, either way round. top_margin (0-1) is how far the first result outscores the second: near 1 the leader clearly wins, near 0 they are interchangeable and you must not silently pick one — say they are equally close, or ask. An entry marked by_you is one you saved: only those can you correct (memory.write with replaces) or remove (memory.forget). When entries disagree, the owner's own (origin_actor user_self) beats an agent's whatever the dates; an entry under rejected is one the owner marked wrong, so never state it as true; between agents' entries the newest wins, and you ask the user when the difference matters; a removed note counts for nothing, however often it was saved; and a save met again in old chat (recall.search) is only history: its memory_now says where that note stands now. Do NOT call it to re-fetch something already said in THIS conversation — this pool holds saved knowledge, not the transcript. Only the last few turns are in front of you; earlier ones are NOT lost — recall.search brings them back. It holds no run history, mail, calendar or contacts; those have their own tools.

Input Schema

Name	Required	Description
`about`	No	One name, or two for how two are related, written as a save's `claim` writes them ("owner" for the user). With `query` too, its words answer when no claim names them.
`query`	No	What to recall — free text, matched over each memory's summary and full body. Omit to get the most recent memories.
`since`	No	Only memories at/after this epoch-ms.
`until`	No	Only memories at/before this epoch-ms.
`cursor`	No	Next page — pass the `next_cursor` from a previous result.
`memory_id`	No	Fetch ONE memory in full. Pass the `memory_id` of an entry that came back `truncated`. Ignores `query`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv26.11.3Nov 3, 2026

addedInput schema / properties / about

Added value: +{
+  "description": "One name, or two for how two are related, written as a save's `claim` writes them (\"owner\" for the user). With `query` too, its words answer when no claim names them.",
+  "items": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "object"
+      }
+    ]
+  },
+  "maxItems": 2,
+  "minItems": 1,
+  "type": "array"
+}

First observedv26.10.22Oct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint=true; the description adds substantial behavioral context beyond that — how to interpret `match` tiers, how `top_margin` should block silent tie-breaking, what `truncated` means and how to recover it, that only `by_you` entries are correctable via `memory.write`/`memory.forget`, and precedence rules when entries disagree (`origin_actor` user_self beats agents, `rejected` is never true, removed notes count for nothing). No contradiction with the read-only annotation.

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 purpose and constraints before the interpretive rules, and nearly every sentence carries operative information. It is dense and long, but the density is driven by six parameters plus unannotated result semantics; a mild deduction for the volume of disagreement-precedence prose packed into one block.

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?

There is no output schema, so the description must carry the return semantics — and it does: result fields (`match`, `top_margin`, `truncated`, `by_you`, `origin_actor`, `rejected`, `memory_now`) are all explained along with truncation recovery and pagination cursor usage. An agent has enough to call it and to interpret the response correctly.

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 the baseline is 3, but the description meaningfully extends it: it explains that `about` finds notes by their `claim` in any wording or language and interacts with `query`, and that `memory_id` exists specifically to un-truncate an entry and ignores `query`. That is real semantic value beyond the 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?

States a specific verb and resource — 'Recall saved KNOWLEDGE from the owner's memory pool' — and immediately frames its job as cross-session recall. It explicitly separates itself from `recall.search` (transcript history) and from mail/calendar/contacts tools, 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?

Gives explicit when-to-use (knowledge from earlier sessions the current conversation never carried), an explicit when-NOT (do not re-fetch something already said in THIS conversation), and named alternatives (`recall.search` for earlier turns, dedicated tools for run history/mail/calendar/contacts). Nothing is left to inference.

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

Deploy Server

memory.search

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools