Mnemoverse Memory

memory_feedback

Rate memories by ID with an outcome from -1 to 1 to improve future retrieval ranking; positive feedback raises a memory, negative lowers it without deleting saved text.

Instructions

Rate memories returned by memory_read to help improve future retrieval ranking. Pass their IDs as memory_ids and an outcome from -1 (unhelpful) to 1 (helpful). Records feedback and updates ranking signals: positive feedback raises a memory's ranking; negative feedback lowers it so other memories out-rank it — nothing is erased. Saved text is not changed or deleted. For memories read from a shared room, 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

Name	Required	Description
`domain`	No	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.
`outcome`	Yes	How helpful was this? 1.0 = very helpful, 0 = neutral, -1.0 = harmful/wrong
`memory_ids`	Yes	IDs of the memories to rate, the `id:` line of each memory_read result.

Output Schema

Name	Required	Description
`avg_valence`	No	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.
`updated_count`	Yes	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.
`coactivation_edges`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.15.3Oct 18, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed1 schema field changedv0.14.2Oct 1, 2026

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

Changed3 schema fields changedv0.13.0Sep 28, 2026

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"
+]

Changed1 schema field changedv0.12.1Sep 25, 2026

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

Changed1 schema field changedv0.11.0Sep 23, 2026

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"
+}

Changed4 schema fields changedv0.10.2Sep 22, 2026

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"
+]

First observedv0.3.7Jun 17, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Adds real context beyond annotations: positive feedback raises ranking, negative lowers it so others out-rank it, and nothing is erased or edited. However, it never mentions that repeated calls accumulate rather than being idempotent (idempotentHint=false), nor does it address whether feedback can be revised or overwritten.

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 effect, then permissions. Slightly padded at the end: 'nothing is erased' and 'Saved text is not changed or deleted' are two near-identical reassurances that could collapse into one clause.

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?

For a 3-param mutation tool with full schema coverage and an output schema (so return values need no explanation), the description covers purpose, side effects, reversibility, domain requirement, and the permission gate. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description restates the -1..1 outcome scale and the domain-for-shared-rooms rule, but both points are already spelled out in the property descriptions; it adds no format or edge-case detail the schema lacks.

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 ('Rate memories returned by memory_read') and states the goal (improve future retrieval ranking). It is clearly distinguished from siblings like memory_write and memory_read, which store and fetch rather than score.

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?

Explicitly ties invocation to memories obtained from memory_read, states the domain-only condition for shared-room memories versus own memories, and names a hard exclusion: a read-only room member cannot rate the room's memories. That is when-to-use, when-not, and the gating prerequisite in one place.

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

Deploy Server