slowave

Official

Overview Schema Source Related Servers Discussions Admin

slowave_feedback

Record feedback on retrieved memories and procedures—usage, effect, relevance, or stale status—so future retrieval and ordering improve.

Instructions

Record append-only evidence about retrieved memories and procedures.

Task outcome does not belong here; slowave_commit owns it. Memory feedback informs future retrieval; procedure use/effect informs future ordering. Task mismatch does not establish that a claim is false. When a retrieved claim is replaced, remember the corrected claim first, then mark the old one stale/superseded with its replacement_memory_id. Declarative assessments are used|not_used|unassessable|irrelevant|already_known|stale. Report used only after observed influence on reasoning, an action, a check, or an applied constraint; reading or topical similarity is insufficient. not_used means no influence; irrelevant means task mismatch. unassessable requires reason and records unknown usage, never guessed non-use. Both not_used and unassessable are neutral and complete target accountability. Complete all exposed targets after the relevant work, before commit. Partial checkpoints may report observed use or stale evidence earlier. Only returned targets need feedback; do not exhaust continuation pages. You may batch multiple retrievals in items. A minimal memory entry is {"memory_id":"","assessment":"not_used"}. 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|unassessable) separate from effect (helped|no_effect|harmed|unknown), with contribution required when used. Memory feedback additionally accepts: relevance (relevant|irrelevant|uncertain), effect for used marks (helped|no_effect|harmed; absent means helped, unknown is invalid), and the already_known assessment (dedup observation; no reinforcement, no suppression). Relevance never gates the usage axis and vice versa (decoupled axes). For assessments other than used, omit effect or set unknown. not_used/unassessable procedures require omitted/unknown effect and no contribution; unassessable additionally requires reason. Replacement memories must be active, different, and in the retrieval scope; replacement IDs need not have been exposed by this retrieval. Even an empty retrieval requires {"retrieval_id": "", "coverage": "complete"}. Default coverage is partial. For batches put coverage inside each item, never at top level. Outer ok=true can contain rejected targets or failed batch items: inspect every results[i].ok, data.rejected and data.outstanding. Correct rejected entries and outstanding targets, then declare complete.

Args: retrieval_id: opaque ID returned by activate/recall. memory_feedback: [{memory_id, assessment, relevance?, effect?, 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: achieved partial or complete coverage. A rejected complete request reports partial. requested_coverage: the client's requested 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: actual strengthened/weakened/unchanged numeric changes, plus neutral not_used/unassessable observations and stale transitions. results: for batch input, ordered item envelopes with independent ok/data or ok/error results.

Input Schema

Name	Required	Description	Default
`items`	No	Batch mode: send items alone. Put coverage inside each item; omit every scalar feedback field.
`missing`	No
`coverage`	No		partial
`retrieval_id`	No
`memory_feedback`	No
`retrieval_quality`	No
`procedure_feedback`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedv0.20.5Oct 14, 2026

addedInput schema / $defs / MemoryFeedbackEntry / properties / assessment / description

Added value: +"used requires observed influence on reasoning/action/check/constraint, not reading or topical similarity. not_used means no influence; irrelevant means task mismatch; unassessable means lost/uncertain usage evidence and requires reason. stale requires stale_reason and reason."

addedInput schema / $defs / MemoryFeedbackEntry / properties / assessment / enum

Added value: +[
+  "used",
+  "not_used",
+  "unassessable",
+  "irrelevant",
+  "already_known",
+  "stale"
+]

addedInput schema / $defs / MemoryFeedbackEntry / properties / effect

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "used: helped/no_effect/harmed; omitted means helped. Other assessments: omit or unknown.",
+  "enum": [
+    "helped",
+    "no_effect",
+    "harmed",
+    "unknown",
+    null
+  ],
+  "title": "Effect"
+}

addedInput schema / $defs / MemoryFeedbackEntry / properties / memory_id / description
```
Added value: +"Assessed memory ID exposed by this retrieval."
```
addedInput schema / $defs / MemoryFeedbackEntry / properties / reason / description
```
Added value: +"Nonblank explanation required for stale or unassessable."
```

addedInput schema / $defs / MemoryFeedbackEntry / properties / relevance

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional relevance, independent of usage.",
+  "enum": [
+    "relevant",
+    "irrelevant",
+    "uncertain",
+    null
+  ],
+  "title": "Relevance"
+}

addedInput schema / $defs / MemoryFeedbackEntry / properties / replacement_memory_id / description

Added value: +"For stale: different active memory in the retrieval scope; need not be exposed."

addedInput schema / $defs / MemoryFeedbackEntry / properties / stale_reason / description
```
Added value: +"Only for stale. superseded also requires replacement_memory_id."
```

addedInput schema / $defs / MemoryFeedbackEntry / properties / stale_reason / enum

Added value: +[
+  "contradicted",
+  "superseded",
+  "outdated",
+  "unsupported",
+  "withdrawn",
+  null
+]

addedInput schema / $defs / ProcedureFeedbackEntry / properties / contribution / description

Added value: +"Nonblank description of how the procedure contributed; required when used, omit when not_used."

addedInput schema / $defs / ProcedureFeedbackEntry / properties / effect / description
```
Added value: +"Omitted means unknown. not_used permits only omitted or unknown."
```

addedInput schema / $defs / ProcedureFeedbackEntry / properties / effect / enum

Added value: +[
+  "helped",
+  "no_effect",
+  "harmed",
+  "unknown",
+  null
+]

addedInput schema / $defs / ProcedureFeedbackEntry / properties / procedure_id / description
```
Added value: +"Procedure ID exposed by this retrieval."
```

addedInput schema / $defs / ProcedureFeedbackEntry / properties / use / description

Added value: +"used requires nonblank contribution; not_used/unassessable forbid contribution; unassessable requires reason."

addedInput schema / $defs / ProcedureFeedbackEntry / properties / use / enum
```
Added value: +[
+  "used",
+  "not_used",
+  "unassessable"
+]
```

addedInput schema / examples

Added value: +[
+  {
+    "items": [
+      {
+        "coverage": "complete",
+        "memory_feedback": [
+          {
+            "assessment": "not_used",
+            "memory_id": "<returned>"
+          }
+        ],
+        "retrieval_id": "<returned>"
+      }
+    ]
+  }
+]

addedInput schema / oneOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "items"
+      ]
+    },
+    "required": [
+      "retrieval_id"
+    ],
+    "title": "Scalar feedback"
+  },
+  {
+    "not": {
+      "anyOf": [
+        {
+          "required": [
+            "retrieval_id"
+          ]
+        },
+        {
+          "required": [
+            "memory_feedback"
+          ]
+        },
+        {
+          "required": [
+            "procedure_feedback"
+          ]
+        },
+        {
+          "required": [
+            "retrieval_quality"
+          ]
+        },
+        {
+          "required": [
+            "missing"
+          ]
+        },
+        {
+          "required": [
+            "coverage"
+          ]
+        }
+      ]
+    },
+    "required": [
+      "items"
+    ],
+    "title": "Feedback batch"
+  }
+]

addedInput schema / properties / items / description

Added value: +"Batch mode: send items alone. Put coverage inside each item; omit every scalar feedback field."

First observedv0.20.3Sep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the entire burden and does so: append-only semantics, decoupled usage/relevance axes, neutral not_used/unassessable observations, and non-obvious server behavior ('Outer ok=true can contain rejected targets or failed batch items: inspect every results[i].ok, data.rejected and data.outstanding'). It also warns that 'A rejected complete request reports partial' and 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.

Conciseness4/5

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

Front-loaded with purpose and the commit boundary, and most sentences carry operational rules that cannot be inferred elsewhere. It is dense and occasionally repetitive (the reason-required rule is restated for memory vs. procedure contexts), and the running-prose layout makes the many constraints harder to scan than they need to be, but little is pure 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?

An output schema exists and the Returns section already enumerates every response field, so the description is free to spend its words on the hard parts: assessment semantics, batching, rejection recovery, and coverage semantics. An agent has everything needed to shape a valid call and to react to partial rejection.

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?

Top-level schema coverage is only 14%, but the description compensates by explaining nearly every field: scalar feedback vs. items mutual exclusivity, coverage default of partial, batch coverage placement, stale_reason values with the superseded/replacement_memory_id dependency, and procedure use-vs-effect separation. Minor gap: retrieval_quality and missing are described only in one vague clause each, with no expected format.

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: 'Record append-only evidence about retrieved memories and procedures.' It also explicitly fences off the sibling: 'Task outcome does not belong here; slowave_commit owns it,' so an agent can distinguish this from slowave_commit without reading either 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 explicit when-to-report rules for each assessment ('Report used only after observed influence on reasoning, an action, a check, or an applied constraint; reading or topical similarity is insufficient'), sequencing guidance ('Complete all exposed targets after the relevant work, before commit'), and an exclusion ('Only returned targets need feedback; do not exhaust continuation pages'). Alternatives and edge conditions are covered, not left to inference.

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

Deploy Server