genesis-memory

memory_remember

Store a memory so your agent can recall it in a later session. Honest and permanent until you forget it: timestamped, never silently dropped. Needs your api_key.

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	optional tags for later filtering
`check`	No	optional forward-looking test: the observation that would settle whether this entry still holds, e.g. 'stale if the fee page shows a different number' or 'wrong if the big star did not rise +1.8k over refill'. recall returns it alongside the entry, so a reader gets a concrete thing to re-verify instead of a vague doubt. The falsifier a later reader runs, the inverse of source (where it came from) vs where it would break
`source`	No	optional note where this came from
`api_key`	Yes
`content`	Yes	what to remember
`relied_on`	No	optional: the specific span you actually relied on for this decision, a subset of source_excerpt, so a reader can see it sitting inside the broader passage and judge whether it was cherry-picked. Proves justification, not just retrieval
`collection`	No	optional group/namespace, e.g. a project
`supersedes`	No	optional id of your earlier memory this replaces; the old entry is retired from recall but kept for audit
`source_hash`	No	optional content hash of the source bytes you cited, so a later reader can detect a silent edit (integrity, not just origin)
`retrieved_at`	No	optional ISO timestamp of when you fetched the source, distinct from when this memory was written, so a later reader can tell whether the source drifted after you cited it
`agent_version`	No	optional: what wrote this (model or prompt version), so a later reader can audit who said it
`source_excerpt`	No	optional: the actual cited bytes/passage you retrieved (not just a URL), so the evidence survives even if the live source later changes or dies
`supersede_kind`	No	optional (with supersedes): WHY the old entry was replaced. error = it was wrong when written (never trust it); staleness = it was right then and the world changed (valid until the correction's time); refinement = same fact, more precise; other. A reader treats a corrected fact and a stale-but-once-true fact very differently, so recording which is the honest minimum
`supersede_scope`	No	optional (with supersedes): which specific claim or part of the earlier entry this correction targets, e.g. 'the fee amount only'. Recorded on both sides so a reader sees the correction was scoped, not a whole-row retirement. Note: retirement is still row-level today; this records intent until claim-level partial retirement lands
`supersede_reason`	No	REQUIRED when supersedes is set: why this correction replaces the earlier entry. Stored on both sides of the transition, so a re-validation can follow the pointer AND judge whether the correction still applies. A supersede with no reason is rejected (optional is where provenance goes to die)
`source_conditions`	No	optional: the request conditions that produced these bytes (e.g. 'locale=de; bucket=A; version=2026-10'), captured at fetch time, so a divergent re-fetch reads as a different rendering rather than a contradiction

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / check

Added value: +{
+  "description": "optional forward-looking test: the observation that would settle whether this entry still holds, e.g. 'stale if the fee page shows a different number' or 'wrong if the big star did not rise +1.8k over refill'. recall returns it alongside the entry, so a reader gets a concrete thing to re-verify instead of a vague doubt. The falsifier a later reader runs, the inverse of source (where it came from) vs where it would break",
+  "type": "string"
+}

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / supersede_kind

Added value: +{
+  "description": "optional (with supersedes): WHY the old entry was replaced. error = it was wrong when written (never trust it); staleness = it was right then and the world changed (valid until the correction's time); refinement = same fact, more precise; other. A reader treats a corrected fact and a stale-but-once-true fact very differently, so recording which is the honest minimum",
+  "enum": [
+    "error",
+    "staleness",
+    "refinement",
+    "other"
+  ],
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose key traits: persistence ('permanent until you forget it'), timestamping, non-silent dropping, and the auth requirement ('Needs your api_key'). However it omits error/overwrite semantics, what happens to superseded entries (schema covers this, not the description), and any return behavior.

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?

Two tightly written sentences, front-loaded with purpose and durability. 'Honest and permanent until you forget it' is slightly rhetorical but conveys the non-dropping guarantee economically; nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter, no-output-schema mutation tool with zero annotations, the description covers purpose, durability, and auth but says nothing about the supersede workflow or what is returned. The unusually rich schema descriptions compensate substantially, making this adequate but not complete on its own.

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 description coverage is 94%, so the schema already documents the rich parameter set (supersedes, check, source_excerpt, etc.). The description only echoes api_key and adds no syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource ('Store a memory') and frames its role by naming the counterpart activity ('so your agent can recall it in a later session'). It doesn't explicitly distinguish itself from memory_update or team_remember, but the write-vs-recall pairing is clear enough to distinguish it from memory_recall.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use/when-not guidance and no named alternative. The phrase 'recall it in a later session' hints at the durability use case, but it never says when to prefer this over memory_update or team_remember, nor what conditions require it.

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

All genesis-memory 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.

Resources

Need Help?