slowave

Official

Overview Schema Source Related Servers Discussions Admin

slowave_recall

Retrieve relevant historical context and procedures into working memory for mid-task lookups. Query by natural language to find memories, evidence, and steps tied to the active session and scope.

Instructions

Semantic retrieval: bring relevant memories into working memory. Use for deliberate mid-task lookups when you need specific historical context beyond what activate surfaced. Recall is explicitly bound to the active session and matching scope. Retrieval considers semantic meaning and specific lexical matches, then selects context relevant to the current need. Ask a focused natural-language question naming the subject, goal, and relevant conditions; preserve exact project/service names, identifiers, and error text when known. Paraphrases can match; you do not need to reproduce the stored wording. Avoid keyword stuffing or assuming the answer in the query. For example, a stored claim "Atlas authentication credentials expire after 45 minutes" can be queried with "How long do Atlas login tokens remain valid?" State independent needs as separate sentences when asking several questions. Results are bounded suggestions, not proof of truth or a complete inventory. If needed history is missing, clarify the question or use a returned continuation when more context would help; an empty result does not prove absence. Inspect provenance/evidence and procedure outcomes/caveats before applying guidance; use evidence="full" when source content is needed, noting truncation. Args: page_size: optional strict integer 1–10; omitted values use the server default for a new query. Omit with continue_from. query: natural-language query; omit when continuing a frozen result. session_id: active session returned by slowave_activate. scope: required retrieval boundary; must match the session. task_context: optional context update for this sub-question. evidence: references (default) or full; budget and policy are server-owned. continue_from: opaque cursor returned by activate or recall. The cursor is bound to this session and scope and replays a frozen tail. Returns: retrieval_id: pass to slowave_feedback after using memories. memories: canonical direct/associated memories with stable pathways. procedures: canonical procedures, including their ID, goal, summary, context, steps, caveats, outcome, outcome_summary, created_at, aggregate evidence, and recent contributions; no ranking scores. evidence: bounded records with evidence_id, source_kind, recorded_at, occurred_at, and source_ref; full mode also returns content and per-record truncated. evidence_mode: the applied references or full mode. evidence_truncated: whether evidence records exceeded the response budget. retrieval_policy_version: server-selected retrieval-policy identifier. relevant_total: number of discovered relevance-qualified declarative memories in a relevant-set response. catalog_truncated: true when the bounded candidate search could have omitted qualifying memories. more_available: whether a frozen continuation page is available. continue_from: opaque continuation cursor, present only when more_available. accessible_field: bounded orientation for unreturned candidates; contains extra_candidates, kinds, and approx_extra_tokens, never content.

Input Schema

Name	Required	Default
`query`	No
`scope`	Yes
`evidence`	No	references
`page_size`	No
`session_id`	Yes
`task_context`	No
`continue_from`	No
`semantic_context`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.20.5Oct 14, 2026

addedInput schema / properties / page_size

Added value: +{
+  "anyOf": [
+    {
+      "description": "Maximum memories per page (default 5); continuations inherit this bound. Procedures have a separate limit.",
+      "maximum": 10,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Page Size"
+}

First observedv0.20.3Sep 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses session/scope binding, that results are 'bounded suggestions, not proof of truth', that an empty result does not prove absence, that evidence can be truncated, and that continuations replay a frozen tail. It omits any note on auth requirements or rate limits, but the behavioral profile for a read-lookup tool is otherwise thorough.

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

Conciseness3/5

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

The purpose is front-loaded and the guidance is useful, but the long enumerated Returns block duplicates an output schema that already exists, making the description noticeably bloated. The query-crafting advice earns its place; the return-field catalogue largely does not.

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

Completeness4/5

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

For an 8-parameter, session-bound retrieval tool with a separate output schema, the description covers usage, query construction, evidence modes, pagination/continuation and failure interpretation. The only real omission is the undocumented semantic_context parameter.

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 description coverage is 0%, so the description must compensate and largely does, documenting the semantics and interactions of query, scope, session_id, task_context, evidence, continue_from and page_size (including the 'omit when continuing' rule). The one gap is semantic_context, which exists in the schema but is never mentioned in the Args section.

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 ('Semantic retrieval: bring relevant memories into working memory') and immediately scopes it against a sibling ('beyond what activate surfaced'). An agent can distinguish it from slowave_activate without opening any 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?

Explicitly names the trigger ('deliberate mid-task lookups' needing 'specific historical context beyond what activate surfaced') and gives strong query-crafting guidance with a worked example. It does not explicitly say when NOT to use it versus slowave_remember/feedback/commit, so it stops short of a full routing rule set.

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

Deploy Server