slowave

Official

Overview Schema Source Related Servers Discussions Admin

slowave_activate

Prime working memory with relevant context and open a server-side session automatically. Call this first to surface task-relevant memories and procedures, eliminating the need to manage session startup.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`task`	Yes
`scope`	Yes
`initial_goal`	Yes
`task_context`	No
`continuity_id`	No
`semantic_context`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.20.3Sep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

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 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server