Renor

Remember something naturally

remember

Destructive

Call this in the same turn the user states a preference or working rule, makes or confirms a decision, or corrects you, in their words, not at the end of the task; not for task requests, questions, your own progress or status (the sent/submitted ledger still asks you to record what the user reports having done) or thanks. Save something to memory: pass statement, in plain words, and nothing else. Do not save passwords, API keys or tokens. Example: remember({"statement": "We moved the Fjord database to SQLite because it needs no server."}). It is stored whole and indexed at once, so get_context finds it right away; the receipt's id is what read_memory and retire_memory take. scope ("project:") keeps it with one project. Only for a value that stays current until it changes (a city, a project's database, a deadline, a preference), also pass subject, predicate and object together: "subject": "Fjord", "predicate": "database", "object": "SQLite". Saving the same subject, predicate and scope again replaces the value: the old one leaves current reads and stays in history. A save by a different agent than the one that saved the current value is shown in reads as a CONFLICT line until that agent saves it again (see save_memory). Spell them the same every time. Decisions, events and notes need none of the three: leave them out, never guess them. The same statement for the same fact again changes nothing. A statement over 4000 characters is refused, never cut, in either form. Saved on its own as a note, one that is not valid Unicode or holds a control character (U+0000 to U+001F except tab, newline and carriage return, or U+007F) is refused and nothing is written; with subject, predicate and object it is saved as a fact with its control characters escaped in the ledger, and only those three fields refuse them. A fact receipt may list possibleDuplicates (the same predicate under a name one word longer or shorter, or in another scope): nothing is merged; to correct one, save again with its subject and scope. A save is compared within the scope it names. To correct one specific earlier note or log entry (not a fact), also pass replaces, its id (from memory_map with a query, or an earlier save's receipt): that memory is then marked replaced, with a pointer to this save, in every recall, and this save is listed before it. Nothing is deleted; retire_memory on this save undoes it, and the receipt says replaced (or replacesIgnored when linking would make a loop, as when the save is the same line as the memory it replaces). Sent with subject, predicate and object as well, replaces naming a note or entry makes the save that plain-words correction (factFieldsIgnored), and replaces naming a fact is dropped while the fact is saved (replacesIgnored).

Input Schema

Name	Required	Description
`cites`	No	Optional, never required. What this save builds on: the notePath (or memory id) of a note a read returned, or the subject of a fact it returned. Lets Renor tell that reading helped.
`scope`	No	"global" (default) or project:<slug>, e.g. project:atlas.
`object`	No	With subject and predicate: the current value, on one line, e.g. "SQLite".
`source`	No	Name of the app or agent saving this, for example claude-code. Leave it out to use the connecting client. Never a file path or document name.
`subject`	No	With predicate and object: who or what the value is about, e.g. "Fjord".
`replaces`	No	Optional. The id (entry:<path>#<hash> or note:<path>) of the earlier memory this save corrects, from memory_map with a query or an earlier save's receipt. Renor then marks that memory replaced and points to this one, so a later recall puts this first. Nothing is deleted: retire this save to undo it. For a fact, save it again with the same subject, predicate and scope instead.
`timezone`	No	Optional. The user's time zone: an IANA name ("America/Sao_Paulo") or a UTC offset ("-03:00"). A note is then filed under the user's own day and stamped with their local time; without it, under the UTC day and time. A fact keeps its exact moment either way.
`predicate`	No	With subject and object: the attribute, snake_case, spelled the same every time, e.g. "database".
`statement`	Yes	The thing to remember, in plain words.

Output Schema

Name	Required	Description	Default
`id`	No
`ok`	Yes
`file`	No
`mode`	Yes
`index`	No
`scope`	No
`action`	No
`closed`	No
`detail`	No
`created`	No
`eventId`	No
`indexed`	No
`subject`	No
`warning`	No
`replaced`	No
`predicate`	No
`statement`	Yes
`alsoClosed`	No
`replacesIgnored`	No
`possibleDuplicates`	No
`possibleDuplicatesTotal`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "action": {
+      "enum": [
+        "store",
+        "supersede",
+        "nochange"
+      ],
+      "type": "string"
+    },
+    "alsoClosed": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "factId": {
+              "type": "number"
+            },
+            "object": {
+              "type": "string"
+            },
+            "validTo": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "factId",
+            "object",
+            "validTo"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "closed": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "factId": {
+              "type": "number"
+            },
+            "object": {
+              "type": "string"
+            },
+            "validTo": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "factId",
+            "object",
+            "validTo"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "created": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "factId": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "object": {
+              "type": "string"
+            },
+            "validFrom": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "factId",
+            "object",
+            "validFrom"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "detail": {
+      "type": "string"
+    },
+    "eventId": {
+      "type": "string"
+    },
+    "file": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "index": {
+      "additionalProperties": false,
+      "properties": {
+        "errors": {
+          "type": "number"
+        },
+        "failure": {
+          "type": "string"
+        },
+        "indexed": {
+          "type": "number"
+        },
+        "total": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "total",
+        "indexed",
+        "errors"
+      ],
+      "type": "object"
+    },
+    "indexed": {
+      "type": "boolean"
+    },
+    "mode": {
+      "enum": [
+        "fact",
+        "note"
+      ],
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "possibleDuplicates": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "object": {
+            "type": "string"
+          },
+          "scope": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          },
+          "subject": {
+            "type": "string"
+          },
+          "untrusted": {
+            "const": true,
+            "type": "boolean"
+          },
+          "validFrom": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "subject",
+          "object",
+          "scope",
+          "validFrom"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "possibleDuplicatesTotal": {
+      "type": "number"
+    },
+    "predicate": {
+      "type": "string"
+    },
+    "replaced": {
+      "additionalProperties": false,
+      "properties": {
+        "by": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "by"
+      ],
+      "type": "object"
+    },
+    "replacesIgnored": {
+      "type": "string"
+    },
+    "scope": {
+      "type": "string"
+    },
+    "statement": {
+      "type": "string"
+    },
+    "subject": {
+      "type": "string"
+    },
+    "warning": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "mode",
+    "statement"
+  ],
+  "type": "object"
+}

First observedOct 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Rich disclosure well beyond the annotations: the 4000-character hard refusal (never truncation), Unicode/control-character rejection rules that differ for notes vs facts, whole-and-immediately-indexed storage, replacement semantics (old value leaves current reads but stays in history), cross-agent CONFLICT lines, duplicate `possibleDuplicates` that are never merged, and explicit 'nothing is deleted' reversibility. This also usefully clarifies why `destructiveHint=true` is only apparent — replacements are recoverable — and 'the same statement again changes nothing' softens the `idempotentHint=false` reading rather than contradicting it.

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?

The critical routing information is front-loaded in the first clause, which is good, but the body is a single dense paragraph of run-on sentences with nested parentheticals and repeated edge-case retellings (the `replaces` behavior is explained twice, and much of it duplicates the schema descriptions). It is appropriately large for a 9-parameter semantic tool but not structured enough to scan.

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 save tool whose output schema already documents the receipt, the description covers everything else an agent needs: when to fire, how to format facts, hard limits, refusal conditions, duplicate handling, conflict behavior, and undo path. No behavioral gap remains that would cause a mis-call.

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 baseline is 3, and the description earns above that by adding real semantics: subject/predicate/object must be passed together and only for a value that stays current, they must be spelled identically every time, and they must be omitted (not guessed) for decisions/events/notes. It also explains the interaction rules between `replaces` and fact fields (`factFieldsIgnored`, `replacesIgnored`). It stops short of 5 only because the per-parameter meaning of `scope`, `cites`, `timezone` and `source` is largely restated from the schema.

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 concrete verb and resource ('Save something to memory: pass `statement`') and enumerates the triggering events (preference, working rule, decision, correction). It clearly distinguishes this tool from note/log saving, from `retire_memory`/`read_memory` (which take the returned id), and from `save_memory` (conflict resolution), so an agent can separate it from its many siblings without opening the 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 timing ('in the same turn the user states... not at the end of the task') and an explicit exclusion list (task requests, questions, own progress/status, thanks), plus the routing rule for corrections to notes vs facts via `replaces`. The alternative paths are named directly: `read_memory` and `retire_memory` consume the receipt id, `memory_map` supplies replace ids, `retire_memory` undoes a replace.

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

All Renor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.