Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@slowave Remember that we pin all dependencies to exact versions."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Living memory layer across your AI tools.
AI agents have large context windows, but that context ends with your current session. Open a new session, switch from Claude Code to Codex, and you have to restate the same decisions, constraints, and failed attempts.
Slowave gives your agents one local, shared memory, without requiring a separate LLM for memory maintenance.
Slowave is designed as an adaptive memory layer rather than a static retrieval or summarisation system; it approaches agent memory from a different angle:
An effective memory system should help an agent achieve its goals.
Agent memory is not only a retrieval problem. A useful memory system should retain what helps the agent, weaken what does not, and continuously adapt based on use.
Slowave addresses this with a continuous feedback loop between your agent and its memory:
remember → recall → use → feedback → reinforce / weaken → decay
Slowave adapts the salience of stored memories based on your agent's feedback.
Over time, your agent’s feedback shapes what Slowave returns without needing a separate LLM judge inside the memory layer.
Memory becomes something continuously shaped by use rather than a static collection of facts waiting to be retrieved.
Keep context across tasks: Your agents can reuse recorded decisions, preferences, constraints, and lessons instead of making you repeat them.
Improves with use: Useful memories strengthen, irrelevant ones lose priority, stale knowledge can be suppressed or superseded.
Learns from experience: Decisions, outcomes, and multi-step solutions can become reusable memories and procedures.
Runs locally: Slowave stores memory in SQLite and does not send it to a hosted memory service.
No LLM API key: The memory core performs maintenance and retrieval without LLM calls or an LLM API key.
Inspectable: Review memories, retrievals, feedback, procedures, and system activity in the local dashboard.
The first useful payoff is simply not having to repeat the same constraint in the next task.
Over time, the way you work becomes reusable context for your agent.
Claude Code
Codex
Cursor
Cline
Windsurf / Devin Desktop
OpenCode
Claude Desktop
See platform coverage and manual steps.
pipx install slowave
slowave setup --dry-run
slowave setupThe quick start configures every detected client. To configure just one client at a time, see the installation reference.
No LLM API key required.
To remove Slowave, see the removal guide.
Related MCP server: Turbo Quant Memory MCP Server
Slowave is transparent to your work.
You keep working with your agent as usual.
When your agent encounters a durable fact or decision, the installed lifecycle directs it to preserve that claim.
On a later task, Slowave can return a compact, scoped set of relevant recorded memories to your agent, so that it can act upon its own memories.
What you will see while working with your agent:
your agent activating Slowave for the current task and goal,
Slowave retrieving relevant context to your agent,
your agent sending feedback to Slowave on what was retrieved.
your agent committing a Slowave session.
Optionally you will see:
your agent invoking Slowave to remember durable facts.
your agent invoking Slowave to recall something critical for the current task or goal.
Slowave does not decide whether a claim is true or important. Your agent makes that judgment and reports whether retrieved memory helped, was irrelevant, or became stale. Slowave maintains the resulting local memory.
Start the local dashboard with:
slowave dashboardOpen the dashboard in your browser, where you can inspect:
Memories: browse saved decisions, constraints, and lessons.
Procedures: review reusable step-by-step methods from past work.
Retrievals: see what memory Slowave returned for each task.
Activity: follow recent sessions, memory updates, and feedback.
Memory graph: explore connections between related memories.
System health: check the database, worker, backups, and local services.
Client coverage is actively expanding. Suggest more integrations or report broken ones with setup details.
✅ = manually verified · ⬜ = pending verification
Client | macOS | Linux | Windows | Setup |
✅ | ✅ | ✅ |
| |
✅ | ✅ | ✅ |
| |
✅ | ✅ | ✅ |
| |
✅ | ✅ | ✅ |
| |
✅ | ✅ | ✅ |
| |
✅ | ✅ | ✅ |
| |
✅ | ✅ | ✅ |
| |
All the above |
|
¹ requires one manual paste after setup
The default embedding model downloads from Hugging Face on first use (~45 MB, cached locally). Subsequent runs work offline.
Memory is stored in plaintext in the current OS user's application-data directory. Slowave does not send it to a hosted memory service. See runtime data location.
Slowave works through 5 simple MCP tools:
Activate: start a task and load relevant memory.
Remember: save a fact, decision, preference, or instruction.
Recall: search memory during a task.
Feedback: mark retrieved memory as useful, irrelevant, or stale.
Commit: save the task outcome and any reusable procedure.
A background worker consolidates relevant memories and procedures.
See architecture.md and design.md for more details.
flowchart LR
A[Agent task] --> B[1. <i>activate</i><br/>start session]
B --> C[Scoped retrieval<br/>and session]
C --> D[Agent reasoning]
D --> E[2. <i>remember</i><br/>durable claims]
D --> F[3. <i>recall</i><br/>mid-task lookup]
C --> G[4. <i>feedback</i><br/>target assessments]
F --> G
E --> H[5. <i>commit</i><br/>outcome and verification]
G --> H
H --> I[(Local SQLite<br/>raw events and evidence)]
I --> J[Offline consolidation]
J --> K[(Episodes, prototypes,<br/>schemas, relations)]
K --> CSee architecture.md and design.md for details.
Slowave is a memory layer, not a reasoning engine.
It cannot recall information that was never recorded.
It supplies relevant context, but the connected agent decides how to interpret and use it.
Memory quality depends on the client agent and the feedback it provides.
Scopes reduce accidental context leakage; use separate stores when hard isolation is required.
Slowave adds token overhead from tool calls and retrieved context.
The local SQLite database is plaintext by default; protect it with OS permissions or full-disk encryption.
Slowave is public beta software. APIs, configuration, and storage schema may change, and migrations are not guaranteed before stable release.
The current evaluation notes report preliminary retrieval-evidence results, methodology, limitations, and commands for running new evaluations. They do not claim end-to-end agent accuracy or a comparison against other memory systems. See benchmarks.md before treating any result as a production-quality claim.
Mintlify documentation: full auto-generated documentation
design.md: design rationale, boundaries, and positioning
architecture.md: brain-inspired memory model and lifecycle
install.md: installation, setup, lifecycle instructions, modified files, and removal
benchmarks.md: benchmark results, methodology, and reproduction
troubleshooting.md: daemon, worker, dashboard, client integration, database, backup/restore
Slowave is open source under the AGPL-3.0-or-later license.
Contributions are welcome, especially in:
installation and setup quality
client integrations
performance optimization
See CONTRIBUTING.md before submitting a pull request.
Slowave is open source under the GNU AGPL-3.0-or-later license.
Prime working memory with relevant context. Opens an implicit session.
Call this once at the beginning of every task. Spreading activation surfaces relevant memories and procedures, and opens a server-side session so you never need to call session_start manually.
The cognitive cycle: 1. slowave_activate(task, initial_goal, scope) <- start here 2. slowave_remember(content, type, scope) <- for durable facts 3. slowave_recall(query) <- mid-task lookup 4. slowave_feedback(retrieval_id, feedback, ...) <- after using memories 5. slowave_commit(session_id, outcome, ...) <- close the task
Args:
task: verbatim task description (required, nonblank).
initial_goal: concise action-led provisional objective (required, nonblank).
scope: required retrieval boundary in kind:id form.
continuity_id: omit on the first client-conversation activation;
retain and resend the returned opaque token unchanged on later
activations in that conversation. Never invent or reuse it.
task_context: optional structured facts that condition retrieval.
Returns: retrieval_id: pass to slowave_feedback. session_id: required by recall and commit. memory_state: cold_start or available for the resolved scope. memories: canonical [{memory_id, content, pathway, provenance?}]. procedures: execution-backed procedures, pending O4 canonicalization. warnings: stable structured safety warnings. continuity_id: server-issued opaque client-conversation token. continuity_state: started on omission, continued on valid reuse. retrieval_policy_version: server-selected retrieval-policy identifier. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| scope | Yes | ||
| initial_goal | Yes | ||
| task_context | No | ||
| continuity_id | No | ||
| semantic_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the call opens a server-side session, surfaces memories and procedures, and returns warnings, pagination state, and a continuity token. The continuity_id handling is especially explicit with 'Never invent or reuse it,' which goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with an upfront call to action, a numbered cycle, and separate Args/Returns blocks. It earns most of its length, though the detailed Returns list is somewhat verbose and could be trimmed if an output schema is already available.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateful activation tool with no annotations and a bare schema, the description is nearly complete: it covers when to call, parameter semantics, return contract, continuity behavior, and warnings. The main gap is the missing explanation for semantic_context, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining task, initial_goal, scope in 'kind:id' form, continuity_id semantics, and task_context. However, semantic_context appears in the input schema but is absent from the Args section, leaving one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Prime working memory with relevant context' and 'Opens an implicit session.' It also positions itself as the starting step in a numbered cognitive cycle alongside its siblings, making it clearly distinct from slowave_recall, slowave_remember, slowave_feedback, and slowave_commit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call this once at the beginning of every task' and provides a numbered cognitive cycle that maps each phase to the correct sibling tool. It also tells the agent it will 'never need to call session_start manually,' which is a clear usage exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the current task and trigger offline memory consolidation.
Call at the end of every task. If skipped, the idle-session reaper closes the session after SLOWAVE_SESSION_IDLE_TIMEOUT seconds (default 3600). Args: session_id: required active session from activate. final_goal: required confirmed goal. outcome: required success|partial|failure. outcome_summary: required standalone actual result. verification: required {status, summary, evidence_refs?}; status is verified|partially_verified|unverified. procedure: optional {version: 2, summary, context: {}, steps: [{summary}], caveats: []}; include only for a reusable method that was actually attempted. trajectory: optional executed-attempt trace of at most 32 action/observation entries, each {kind, summary, status?}. Must contain TASK actions/observations only. Do NOT include Slowave lifecycle bookkeeping (activate/recall/feedback/commit calls, "Activated the Slowave session." etc.) -- the server filters those out and reports the count as trajectory_lifecycle_filtered. If you have no task-level actions, omit the trajectory. Returns: session_id: the session that was closed. episodes_formed: number of episodic memories created. feedback_status: complete for normal closure. committed: true when the session outcome was recorded. outcome: confirmed success, partial, or failure outcome. verification_status: confirmed verification status. operation: closed for a new close or updated for an already-ended session. trajectory_lifecycle_filtered: number of lifecycle entries removed, when any were filtered. already_ended: true when the session had already been closed.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| procedure | No | ||
| final_goal | Yes | ||
| session_id | Yes | ||
| trajectory | No | ||
| verification | Yes | ||
| outcome_summary | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains several behavioral aspects: it closes the session, triggers memory consolidation, filters out lifecycle bookkeeping entries (and reports the count as trajectory_lifecycle_filtered), and handles already-ended sessions (returning already_ended=true). It also specifies constraints on the trajectory (must contain only TASK actions/observations, max 32 entries) and the condition to omit trajectory if no task-level actions. This is comprehensive and goes beyond what a typical description provides, even with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections for Args, Returns, and usage guidance. It front-loads the core purpose and usage timing ('Call at the end of every task') before detailing parameters. While it is detailed, every sentence adds value, such as the warning about not including lifecycle bookkeeping. It could be slightly more concise by trimming some redundant phrasing, but the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (7 params, nested objects, output schema), the description is thorough. It covers all parameters, their requiredness, allowed enums, constraints (max 32 trajectory entries), and the filtering behavior for lifecycle entries. It also provides comprehensive return field descriptions, which is helpful even though an output schema exists. The absence of details on authentication or rate limits is acceptable since no annotations suggest these are needed, and the tool appears to be a session closure operation. Overall, an agent has enough information to correctly construct the arguments and understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for param semantics. The description provides detailed explanations for each parameter: session_id (required active session from activate), final_goal (required confirmed goal), outcome (required success|partial|failure), outcome_summary (required standalone actual result), verification (required {status, summary, evidence_refs?} with status enum), procedure (optional with version 2 and structure), and trajectory (optional with constraints on content and length). It adds meaning beyond the schema by specifying the source of session_id and the 'confirmed' aspect of final_goal, and by clarifying that procedure is only for reusable methods actually attempted. This is strong compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: close the current task and trigger offline memory consolidation. It uses a specific verb ('close') and resource ('task'), and it distinguishes itself from siblings by emphasizing the end-of-task lifecycle action, which is unique among the listed sibling tools (activate, recall, remember, feedback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Call at the end of every task.' It also provides a clear alternative consequence if skipped (the idle-session reaper closes the session after a timeout), which implies that this tool should be used to avoid that automatic closure. No sibling tool is suggested as an alternative, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record append-only evidence about retrieved memories and procedures.
Task outcome does not belong here; slowave_commit owns it. Declarative
assessments are used|irrelevant|stale. A stale assessment must include
stale_reason (contradicted|superseded|outdated|unsupported|withdrawn)
and a concise reason; superseded additionally requires
replacement_memory_id. Procedure feedback keeps
use (used|not_used) separate from effect
(helped|no_effect|harmed|unknown), with contribution required when used.
Args: retrieval_id: opaque ID returned by activate/recall. memory_feedback: [{memory_id, assessment, stale_reason?, replacement_memory_id?, reason?}]. procedure_feedback: [{procedure_id, use, effect, contribution?, reason?}]. retrieval_quality: optional whole-result quality assessment. missing: optional descriptions of expected but absent knowledge. coverage: partial or complete; silence under partial is not negative. items: batch of records with the same fields. Scalar feedback fields and items are mutually exclusive. Returns: retrieval_id: the assessed scalar retrieval. coverage: applied partial or complete coverage. outstanding: memory_ids and procedure_ids still requiring assessment. accepted_event_ids: append-only feedback events accepted by the server. rejected: feedback targets or shapes the server did not apply, with reasons. applied: IDs grouped by the feedback effect recorded by the server. results: for batch input, ordered item envelopes with independent ok/data or ok/error results.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | ||
| missing | No | ||
| coverage | No | partial | |
| retrieval_id | No | ||
| memory_feedback | No | ||
| retrieval_quality | No | ||
| procedure_feedback | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It discloses append-only semantics, constraint rules (stale requires stale_reason; superseded requires replacement_memory_id; contribution required when used), and server behavior via return fields like 'rejected' and 'accepted_event_ids.' It even notes the non-obvious nuance that 'silence under partial is not negative.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It is front-loaded with purpose and exclusions, then organized into Args and Returns sections. Given the complexity and the total lack of schema-described parameters, this density is appropriate rather than bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no schema parameter documentation, and complex nested inputs, the description is remarkably complete. It covers purpose, exclusions, constraints, parameter semantics, batch behavior, and the full return shape. An agent has everything needed to invoke it correctly, including what happens to rejected or outstanding feedback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does: each parameter is explained in the Args section, including required vs optional fields in nested structures, enum meanings (used|not_used, helped|no_effect|harmed|unknown), mutual exclusivity, and the meaning of 'coverage.' This goes far beyond what the bare JSON schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair: 'Record append-only evidence about retrieved memories and procedures.' It also explicitly differentiates from a sibling tool by stating 'Task outcome does not belong here; slowave_commit owns it,' so an agent can distinguish it from the other slowave tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not guidance ('Task outcome does not belong here') and names the alternative that owns that case (slowave_commit). It also ties the tool to the retrieval workflow by noting retrieval_id comes from 'activate/recall' and clarifies batch vs scalar usage with 'Scalar feedback fields and items are mutually exclusive.' This is enough to route an agent toward the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Args: 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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| scope | Yes | ||
| evidence | No | references | |
| session_id | Yes | ||
| task_context | No | ||
| continue_from | No | ||
| semantic_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It goes beyond the schema by disclosing session/scope binding, server-owned budget and policy, frozen continuation semantics, truncation behavior, and that accessible_field never contains content. It does not state whether the operation modifies state or what authentication is required, but the disclosed contract is detailed and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and usage are front-loaded, and the Args/Returns structure is methodical with no filler. It is long, but for a 7-parameter tool with no annotations most lines add value; the exhaustive return enumeration is the main risk of duplicating information already available in the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex retrieval tool with no annotations, it gives enough context to call correctly: required session/scope, query rules, evidence modes, continuation and truncation, and the retrieval_id handoff to slowave_feedback. The missing semantic_context explanation and lack of error-case guidance are the notable gaps, but the output schema plausibly covers return shapes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 largely does: it explains query omission when continuing a frozen result, session_id provenance, scope matching, task_context purpose, evidence modes, and continue_from cursor semantics. However, semantic_context appears in the input schema but is never described, leaving one parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource: 'Semantic retrieval: bring relevant memories into working memory.' The second sentence immediately distinguishes it from slowave_activate by framing it as a deliberate mid-task lookup for context 'beyond what activate surfaced,' so an agent can tell which sibling to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it for 'deliberate mid-task lookups when you need specific historical context beyond what activate surfaced,' naming the main alternative and the condition that selects this tool. It also reinforces the binding requirement to the active session and matching scope, which is a crisp usage constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly encode a durable typed claim into long-term memory.
Scalar and batch forms inherit one explicitly verified session and scope.
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.
IMPORTANT: Use ONLY for durable knowledge that should persist across sessions.
Do NOT store ephemeral task state — that belongs in session events.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| scope | Yes | ||
| content | No | ||
| memories | No | ||
| session_id | Yes | ||
| occurred_at | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals non-obvious semantics: Slowave always sets internal ts to the write time, occurred_at never changes event order, scalar claims can be created or matched, and batch results are independent item envelopes with ok/data or ok/error. This is far richer than a simple 'store memory' statement, though it does not fully clarify what happens on 'matched' beyond the disposition field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with an opening purpose, Args list, IMPORTANT guidance, and Returns section. However, phrases like 'only verified commit procedures are execution-backed procedures' are cryptic and do not earn their place, and the overall length is high relative to the amount of new information. The structure is above average, but the verbiage makes it a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with zero annotation coverage, this description covers nearly everything needed to call it correctly: parameter meanings, usage constraints, return fields, and batch behavior. The schema-optionality mismatch around type and the lack of a concrete invocation example leave small gaps, but the definition is largely self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates thoroughly: it documents scope/session provenance, content/memories mutual exclusivity, RFC 3339 occurred_at semantics, and batch inheritance of outer scope/session. The only blemish is 'type: required scalar type,' which conflicts with the schema's optional type field and is ambiguous when using the memories batch form.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Explicitly encode a durable typed claim into long-term memory.' The IMPORTANT section then narrows the purpose to durable knowledge that persists across sessions, explicitly excluding ephemeral task state. This distinguishes the tool from siblings like slowave_recall and slowave_feedback without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use directive ('Use ONLY for durable knowledge that should persist across sessions') and a when-not-to-use rule ('Do NOT store ephemeral task state — that belongs in session events'). It also ties the tool to the active session from slowave_activate, establishing a prerequisite. However, it does not explicitly compare against sibling tools slowave_commit or slowave_feedback, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.20.3slowave_activateslowave_commitslowave_feedbackslowave_recallslowave_rememberScored across 5 tools
Each tool occupies a distinct phase in the memory lifecycle: activate primes and opens a session, remember encodes facts, recall retrieves, feedback assesses retrieved items, and commit closes the task. There is no meaningful overlap, and the descriptions reinforce clear boundaries between start, use, and completion.
All tools follow a consistent slowave_<verb> pattern: activate, remember, recall, feedback, commit. The naming is uniform and predictable, making the intended action of each tool immediately clear.
Five tools is well-scoped for the stated purpose of managing a cognitive/memory session lifecycle. Each tool earns its place and together they form a compact, coherent set without redundancy or bloat.
The tool surface covers the full intended cycle: priming/activation, durable storage, retrieval, feedback on retrieval quality, and task closure with consolidation. Gaps like explicit deletion are handled through stale feedback, so no critical operation appears to be missing for the declared domain.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Persistent memory for AI agents. Search, store, and recall across sessions.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
