slowave

Official

Overview Schema Source Related Servers Discussions Admin

slowave_remember

Save confirmed facts, preferences, decisions, constraints, and lessons as durable memory for future tasks, helping agents avoid rework and repeated questions.

Instructions

Record newly discovered knowledge worth retaining for future tasks in this scope. Scalar and batch forms inherit one explicitly verified session and scope. Proactively call this when you discover new knowledge worth retaining as durable memory because it could help you with future tasks: pursue a goal, avoid rework or a wrong assumption, or avoid asking the user again. Do not wait for the user to say “remember”. Good candidates are confirmed facts, user preferences, decisions, constraints, lessons, warnings, and open questions that affect future goals. Save the claim when it becomes clear; review for missed claims before commit. Use concise, standalone wording with enough context for a later session, and batch independent claims. Check activated memories and task context for duplicates; a matched claim is acceptable. Skip speculation, progress notes, pending steps, temporary task state, and details unlikely to matter again. A fact recorded elsewhere can still be worth saving when rediscovery would cost meaningful work.

Write for later retrieval: use one independent claim per entry and name its subject explicitly instead of "this" or "that approach". Preserve conditions, exceptions, and negation; include the reason for a decision when it explains when to apply it. Keep meaningful exact names, identifiers, commands, and error text alongside natural-language context. Retrieval considers meaning and specific terms, so avoid keyword lists, repeated synonyms, and unrelated claims in one entry. For example, prefer "Atlas authentication credentials expire after 45 minutes" to "Tokens: timeout, expiry, login, auth; same as discussed above." Include source/time context when it affects applicability, and use occurred_at only for the source-event time described below.

Args: scope: required scope matching the active session. session_id: required active session returned by slowave_activate. content: one standalone durable claim; mutually exclusive with memories. type: required scalar type. Reusable directions use instruction; only verified commit procedures are execution-backed procedures. occurred_at: optional RFC 3339 source-event time, such as 2026-08-26T09:30:00Z. Use only when the claim records an event that happened at a different time from this MCP call. Slowave always sets internal raw-event ts itself to the write time; occurred_at never changes event order. memories: strict batch of {content, type, occurred_at?} objects inheriting the outer scope and session.

Returns: stored: true when the scalar claim was accepted. memory_id: canonical identifier for a scalar stored or matched memory. disposition: created or matched for a scalar claim. type: confirmed scalar memory type. scope: confirmed scalar memory scope. source_event_id: source provenance event for a scalar claim. results: for batch input, ordered item envelopes with index and independent ok/data or ok/error results.

Input Schema

Name	Required	Description
`type`	No
`scope`	Yes
`content`	No
`memories`	No	Batch mode: omit outer content, type and occurred_at; each entry supplies its own claim fields.
`session_id`	Yes
`occurred_at`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.20.5Oct 14, 2026

addedInput schema / examples

Added value: +[
+  {
+    "memories": [
+      {
+        "content": "A standalone claim",
+        "type": "fact"
+      }
+    ],
+    "scope": "project:<repo>",
+    "session_id": "<active>"
+  }
+]

addedInput schema / oneOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "memories"
+      ]
+    },
+    "required": [
+      "content",
+      "type"
+    ],
+    "title": "Scalar claim"
+  },
+  {
+    "not": {
+      "anyOf": [
+        {
+          "required": [
+            "content"
+          ]
+        },
+        {
+          "required": [
+            "type"
+          ]
+        },
+        {
+          "required": [
+            "occurred_at"
+          ]
+        }
+      ]
+    },
+    "required": [
+      "memories"
+    ],
+    "title": "Batch claims"
+  }
+]

addedInput schema / properties / memories / description

Added value: +"Batch mode: omit outer content, type and occurred_at; each entry supplies its own claim fields."

First observedv0.20.3Sep 15, 2026

TDQS

A4.5/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 behavioral burden and does substantial work: it discloses duplicate matching ('a matched claim is acceptable'), that writes can resolve to created or matched, and that occurred_at is a source-event time that never changes internal event ordering because Slowave stamps ts itself. It does not discuss permissions, failure modes, or rate/volume limits.

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?

It is front-loaded with the purpose and invocation trigger, then args and returns, so an agent can stop reading early. It is nonetheless roughly four times a typical description and repeats the standalone-claim guidance in two places, but nearly every sentence carries operational content rather than 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?

Given a 6-parameter schema with 17% coverage, a nested entry shape, an output schema, and no annotations, the definition still covers invocation trigger, exclusions, both scalar and batch forms, per-argument semantics, and return fields (stored, memory_id, disposition, source_event_id, batch envelopes). Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is only 17%, so the description has to compensate, and it does: scope must match the active session, session_id must be an active session from slowave_activate, content is one standalone claim mutually exclusive with memories, memories is a strict batch inheriting outer scope/session, type is explained with the instruction/procedure distinction, and occurred_at gets an RFC 3339 example plus ordering semantics. This is meaningfully richer than the schema.

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

Purpose4/5

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

The first sentence gives a specific verb and resource with scope: 'Record newly discovered knowledge worth retaining for future tasks in this scope.' It is unmistakably a write/memory-persistence tool and contrasts implicitly with recall/activate/commit by describing when to save rather than fetch. It stops short of naming a sibling as the alternative, so it is clear but not explicitly differentiated.

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?

It gives an explicit invocation condition ('Proactively call this when you discover new knowledge... pursue a goal, avoid rework or a wrong assumption'), an explicit anti-pattern ('Do not wait for the user to say remember'), a positive candidate list, and a negative list ('Skip speculation, progress notes, pending steps, temporary task state'). It also states a prerequisite: the session and scope must come from slowave_activate.

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

Deploy Server