Skip to main content
Glama
mnemoverse

Mnemoverse Memory

by mnemoverse
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

memory_feedback

Rate memories returned by memory_read as helpful or wrong to adjust ranking. Positive feedback surfaces them faster next time; negative feedback lets other memories out-rank them.

Instructions

Report whether memories returned by memory_read were actually helpful. This is a learning signal, not a log: positive feedback raises a memory's ranking so it surfaces faster next time (across all of the user's tools), negative feedback lowers it so other memories out-rank it — nothing is erased and nothing decays with time. Use it after an answer that relied on or rejected memories from memory_read: pass the ids of those memories as memory_ids, with outcome 1 when they helped and -1 when they were wrong or stale. For memories read from a shared room, also pass that room's address as domain; your own memories need no domain. A read-only room member cannot rate the room's memories.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoOnly for memories read from a shared room: that room's address (xroom:...), exactly as you read it. Omit it for your own memories, which are rated by id alone.
outcomeYesHow helpful was this? 1.0 = very helpful, 0 = neutral, -1.0 = harmful/wrong
memory_idsYesIDs of the memories to rate, the `id:` line of each memory_read result.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
avg_valenceNoAverage valence of the rated memories after the update. Reported as 0 in an asynchronous acknowledgement, where the real value is computed later — a 0 here is therefore not evidence of a neutral outcome.
updated_countYesHow many memories the service reports it applied the rating to. Processed synchronously this is the real count of memories that existed and were updated; processed asynchronously it is a best-effort ACCEPTED-count estimate — the number of IDs submitted — and the authoritative number is not known until the background worker runs. Zero means no submitted ID matched in the service's resolved request scope.
coactivation_edgesNoNumber of links between query concepts and result concepts that this rating changed. This server does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.14.2
    • changedOutput schema / properties / coactivation_edges / description
      Previous value: -"Number of feedback-driven query/result concept co-activation edges changed by the service. This is separate from ordinary Hebbian strengthening among a memory's own concepts. This server does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0."New value: +"Number of links between query concepts and result concepts that this rating changed. This server does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0."
  2. Changed3 schema fields changedv0.13.0
    • removedInput schema / properties / atom_ids
      Removed value: -{
-  "description": "Deprecated since 0.11, removed in 0.13: atom_ids is the old name of memory_ids, still accepted on its own until then. Pass memory_ids instead.",
-  "items": {
-    "type": "string"
-  },
-  "minItems": 1,
-  "type": "array"
-}
    • changedInput schema / properties / memory_ids / description
      Previous value: -"Required: IDs of the memories to rate, the `id:` line of each memory_read result. (Optional in this schema only while the deprecated atom_ids is still accepted in its place.)"New value: +"IDs of the memories to rate, the `id:` line of each memory_read result."
    • changedInput schema / required
      Previous value: -[
-  "outcome"
-]New value: +[
+  "memory_ids",
+  "outcome"
+]
  3. Changed1 schema field changedv0.12.1
    • changedInput schema / properties / atom_ids / description
      Previous value: -"Deprecated since 0.11, removed in 0.12: atom_ids is the old name of memory_ids, still accepted on its own until then. Pass memory_ids instead."New value: +"Deprecated since 0.11, removed in 0.13: atom_ids is the old name of memory_ids, still accepted on its own until then. Pass memory_ids instead."
  4. Changed1 schema field changedv0.11.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "avg_valence": {
+      "description": "Average valence of the rated memories after the update. Reported as 0 in an asynchronous acknowledgement, where the real value is computed later — a 0 here is therefore not evidence of a neutral outcome.",
+      "type": "number"
+    },
+    "coactivation_edges": {
+      "description": "Number of feedback-driven query/result concept co-activation edges changed by the service. This is separate from ordinary Hebbian strengthening among a memory's own concepts. This server does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0.",
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "updated_count": {
+      "description": "How many memories the service reports it applied the rating to. Processed synchronously this is the real count of memories that existed and were updated; processed asynchronously it is a best-effort ACCEPTED-count estimate — the number of IDs submitted — and the authoritative number is not known until the background worker runs. Zero means no submitted ID matched in the service's resolved request scope.",
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "updated_count"
+  ],
+  "type": "object"
+}
  5. Changed4 schema fields changedv0.10.2
    • changedInput schema / properties / atom_ids / description
      Previous value: -"IDs of memories to give feedback on (from memory_read results)"New value: +"Deprecated since 0.11, removed in 0.12: atom_ids is the old name of memory_ids, still accepted on its own until then. Pass memory_ids instead."
    • addedInput schema / properties / domain
      Added value: +{
+  "description": "Only for memories read from a shared room: that room's address (xroom:...), exactly as you read it. Omit it for your own memories, which are rated by id alone.",
+  "type": "string"
+}
    • addedInput schema / properties / memory_ids
      Added value: +{
+  "description": "Required: IDs of the memories to rate, the `id:` line of each memory_read result. (Optional in this schema only while the deprecated atom_ids is still accepted in its place.)",
+  "items": {
+    "type": "string"
+  },
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "atom_ids",
-  "outcome"
-]New value: +[
+  "outcome"
+]
  6. First observedv0.3.7

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes well beyond them by explaining the actual effect (positive raises ranking across all the user's tools, negative lowers it so other memories out-rank it), the non-destructive boundary ('nothing is erased and nothing decays with time'), and the permission limitation. No statement conflicts with the annotation set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences, each carrying distinct load: purpose, effect model, and invocation rules. The purpose and ranking consequence are front-loaded before the edge cases, with no 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?

With an output schema present, return values need no explanation. The description covers the mutation effect, the value convention, the conditional domain argument, and the permission edge case, leaving nothing an agent needs in order to call it correctly.

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 coverage is 100%, so the schema already documents all three parameters; the baseline would be 3. The description adds situational meaning by tying memory_ids to 'the ids of those memories' just consumed and restricting domain to shared-room addresses read as xroom, which helps the agent supply them correctly in context.

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 verb+resource ('Report whether memories returned by memory_read were actually helpful') and immediately frames the tool's role as a learning signal rather than a log, which cleanly separates it from siblings like memory_read and memory_write. An agent can identify this as the ranking-feedback tool 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?

It gives explicit when-to-use conditions ('after an answer that relied on or rejected memories from memory_read'), the exact value convention for outcome (1 helpful, -1 wrong/stale), and a conditional rule for domain (shared-room reads only). It even names an exclusion: a read-only room member cannot rate the room's memories.

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

Deploy Server

Other Tools