Skip to main content
Glama
slowave-ai

slowave

Official
by slowave-ai

slowave_activate

Prime working memory at task start by retrieving relevant memories and procedures and opening a server-side session, so agents gain context without manual session setup.

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.
Retrieval considers meaning and specific terms, then selects context
applicable to the task. The bounded result is not a complete inventory
or a verification of the returned claims; assess their actual use.
A user message establishing or changing durable guidance is also a
task, even without another action request. Save the durable claim
and complete feedback and commit before acknowledging completion;
saving guidance is part of completing the task.
Answer-only tasks also require retrieval feedback and commit before
the final response; remember and recall are conditional.
Procedures include complete steps, applicability context, outcomes,
and caveats. Inspect these against current evidence before adapting
a method. Recall only when needed history or details are absent;
name the original goal and relevant conditions in that query.

The cognitive cycle:
    1. slowave_activate(task, initial_goal, scope)      <- start here
    2. slowave_remember(session_id, scope, content, type)
       <- when you discover new knowledge worth retaining as durable memory
          because it could help you with future tasks
    3. slowave_recall(session_id, scope, query)                            <- mid-task lookup
    4. slowave_feedback(retrieval_id, memory_feedback, procedure_feedback, coverage)    <- after using memories
    5. slowave_commit(session_id, final_goal, outcome, outcome_summary, verification)         <- close the task

Args:
    task: copy the user request exactly (required, nonblank); do not
        rewrite or translate it. Put interpretation in initial_goal.
    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 it or reuse it across different client conversations.
    page_size: optional strict integer 1–10; omitted values use the server default.
    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-ready methods with ID, goal, summary, steps,
        context, outcome, outcome_summary, and safety caveats.
        Deliberate recall additionally returns detailed reuse evidence.
    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. 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; false does not include procedure results. 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

NameRequiredDescriptionDefault
taskYesCopy the user request verbatim. Do not rewrite, translate, or substitute the inferred goal.
scopeYes
page_sizeNoMaximum memories per page (default 5); continuations inherit this bound. Procedures have a separate limit.
initial_goalYesConcise action-led interpretation; helps discovery but cannot independently justify admission.
task_contextNo
continuity_idNo
semantic_contextNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.20.5
    • addedInput schema / properties / initial_goal / description
      Added value: +"Concise action-led interpretation; helps discovery but cannot independently justify admission."
    • addedInput schema / properties / page_size
      Added value: +{
      +  "default": 5,
      +  "description": "Maximum memories per page (default 5); continuations inherit this bound. Procedures have a separate limit.",
      +  "maximum": 10,
      +  "minimum": 1,
      +  "title": "Page Size",
      +  "type": "integer"
      +}
    • addedInput schema / properties / task / description
      Added value: +"Copy the user request verbatim. Do not rewrite, translate, or substitute the inferred goal."
  2. First observedv0.20.3

TDQS

A4.4/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 disclose non-obvious traits: a server-side session side effect, bounded/non-exhaustive retrieval ('not a complete inventory or a verification of the returned claims'), catalog truncation, cold_start vs available states, and stable warnings. It does not state permissions, auth requirements, or rate limits, which keeps it short of a 5.

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?

Well front-loaded and organized into purpose / cycle / args / returns, but substantially oversized: a long tail of agent-policy prose ('a user message establishing or changing durable guidance is also a task...') plus a full restatement of the cognitive cycle that repeats sibling-tool duties in prose. Several sentences could be trimmed without losing callable information.

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?

An output schema exists, so the detailed Returns block is arguably redundant, but the annotation-free status means the behavioral disclosure is necessary and is largely present for a multi-step memory system. The one genuine hole is semantic_context, absent from both description and schema.

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 only 43% across 7 params, so the description must compensate, and it does: the Args block adds real meaning beyond the schema for task ('copy verbatim, put interpretation in initial_goal'), continuity_id ('never invent it or reuse it across different client conversations'), and page_size bounds. It only misses semantic_context, which is undocumented in both places.

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?

Opens with a specific verb+resource ('Prime working memory with relevant context. Opens an implicit session.') and immediately states its role as step 1 of a named cycle. Siblings slowave_recall/remember/feedback/commit are placed explicitly in that cycle, so an agent can distinguish this entry-point tool from the mid-task and closing tools 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when ('Call this once at the beginning of every task'), an explicit alternative it removes ('you never need to call session_start manually'), and conditional guidance for downstream tools ('Recall only when needed history or details are absent'). It also resolves an ambiguous case (guidance-only and answer-only tasks still count as tasks). 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.