PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_dream

Destructive

Manage long-term memory by consolidating recent memories into canonical facts and graph structure; track backlog, run dream passes, and roll back committed changes.

Instructions

Drive the dream — consolidation of recent memories into canonical facts and graph structure.

Actions: status: backlog + whether a sweep would fire. Read-only. pull: unconsolidated memories, oldest first; write facts via memory_fact_set, then commit. run: a server-side dream with the configured extractor (loop to drain). deep: full-corpus graph consolidation; dry run unless apply. Settle candidates via memory_graph_review; duplicate lesson/world slots are listed for hand curation. Lists are capped; truncated holds their full counts. runs: recent dream passes (tallies, status). rollback: revert a committed pass from its journal (facts + events; traces/cursor kept).

Returns: per-action dict; {error} on bad input.

Input Schema

TableJSON Schema

Name	Required	Description
`apply`	No	deep: True writes the consolidation (graph tables are snapshotted first); the default is a dry run.
`limit`	No	pull/run: how many memories to process (pull defaults to 40). runs: how many passes to list (defaults to 10).
`action`	Yes
`cursor`	No	Deprecated; use commit_token.
`run_id`	No	rollback: which pass to revert; defaults to the newest committed pass.
`snippets`	No	deep: False omits the evidence snippets.
`commit_token`	No	commit: token returned by pull.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.16.0Oct 3, 2026

addedInput schema / properties / commit_token

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "commit: token returned by pull.",
+  "title": "Commit Token"
+}

changedInput schema / properties / cursor / description

Previous value: -"commit: the newest pulled timestamp. Required for that action."New value: +"Deprecated; use commit_token."

Changed5 schema fields changedv0.15.0Sep 3, 2026

addedInput schema / properties / apply / description

Added value: +"deep: True writes the consolidation (graph tables are snapshotted first); the default is a dry run."

addedInput schema / properties / cursor / description

Added value: +"commit: the newest pulled timestamp. Required for that action."

addedInput schema / properties / limit / description

Added value: +"pull/run: how many memories to process (pull defaults to 40). runs: how many passes to list (defaults to 10)."

addedInput schema / properties / run_id / description

Added value: +"rollback: which pass to revert; defaults to the newest committed pass."

addedInput schema / properties / snippets / description

Added value: +"deep: False omits the evidence snippets."

Changed2 schema fields changedv0.14.0Aug 22, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "status",
-  "pull",
-  "commit",
-  "run",
-  "deep"
-]New value: +[
+  "status",
+  "pull",
+  "commit",
+  "run",
+  "deep",
+  "runs",
+  "rollback"
+]

addedInput schema / properties / run_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Run Id"
+}

First observedv0.11.0Jul 31, 2026

TDQS

A4/5.0

Behavior4/5

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

With annotations already declaring destructiveHint=true and readOnlyHint=false, the description adds real context beyond them: rollback reverts facts + events while traces/cursor are kept, deep snapshots graph tables before writing and defaults to a dry run, duplicate lesson/world slots require hand curation, and lists are capped with 'truncated' holding full counts. It does not discuss auth requirements or cost/rate limits, so it is rich but not exhaustive.

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?

The purpose is front-loaded in one sentence and the action list is organized and scannable. Given six actions and seven parameters the length is defensible, though a few lines (e.g. rollback details) could be tighter without losing meaning.

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

Completeness4/5

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

For a multi-action tool with 7 params and an output schema, the description covers nearly everything an agent needs. The one gap is the 'commit' action, which appears in the enum and is referenced inside the pull line but never given its own described entry, leaving its behavior implicit.

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 description coverage is 86%, so most parameters are already documented. The description adds meaning beyond the schema for the 'action' enum values, whose schema entries carry only a title, by explaining what each action does and its read/write semantics; it also flags 'commit' as the write step after pull. The remaining param notes largely restate schema descriptions.

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?

The opening states a specific verb+resource: 'Drive the dream — consolidation of recent memories into canonical facts and graph structure,' and each action (status/pull/run/deep/runs/rollback) is named and described. However, it never explicitly differentiates itself from consolidation-related siblings like memory_consolidate or memory_consolidation_candidates, so the agent must infer the boundary.

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

Usage Guidelines4/5

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

Per-action guidance is strong: status is labeled read-only, pull is for unconsolidated memories (oldest first) with an explicit follow-up path via memory_fact_set then commit, deep is full-corpus with dry-run default, rollback reverts a committed pass. It stops short of stating when NOT to use this tool versus siblings, so it lacks full alternative routing.

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