Skip to main content
Glama
Pseudogiant-xr

PseudoLife-MCP

Official
by Pseudogiant-xr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

memory_history

Read-only

Read an entity's past to see all versions of a fact (who set it, when) or the chronological events that led to it.

Instructions

Read an entity's past. SLOT mode (attribute given): every version of that canonical fact slot, oldest→newest, each with writer/session, tx/valid time, and age ("what did this used to be? who set it?") — compaction thins chains past ~30d. CHAIN mode (attribute omitted): the entity's dated fact/entry/edge/lesson events merged oldest→newest ("what led to X?").

Returns: {entity, attribute, count, versions} (slot mode) or {found, entity, count, events} (chain mode).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNoSlot mode only: ISO-8601 or epoch seconds; returns only versions written by then.
entityYesThe subject whose past to read.
attributeNoThe fact slot to read; omit for chain mode.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.15.0
    • addedInput schema / properties / as_of / description
      Added value: +"Slot mode only: ISO-8601 or epoch seconds; returns only versions written by then."
    • addedInput schema / properties / attribute / description
      Added value: +"The fact slot to read; omit for chain mode."
    • addedInput schema / properties / entity / description
      Added value: +"The subject whose past to read."
  2. Changed1 schema field changedv0.14.0
    • addedInput schema / properties / as_of
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "As Of"
+}
  3. First observedv0.11.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds real context beyond them: oldest-to-newest ordering, the fields returned per version (writer/session, tx/valid time, age), and the ~30d compaction caveat. The compaction note is a genuinely useful behavioral trait not visible in any structured field.

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?

Dense but front-loaded: purpose first, then mode breakdown, then return shapes. Each clause carries information (mode, ordering, fields, caveat) rather than filler, though the inline return-shape enumeration is somewhat verbose given an output schema exists.

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 two-mode read tool with a documented output schema and full parameter coverage, the description covers mode selection, ordering, returned fields, and a data-retention caveat. Nothing an agent needs to invoke 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 description coverage is 100% and the schema already documents attribute ('omit for chain mode') and as_of ('slot mode only'). The description reinforces the mode-switch meaning of attribute but adds little syntactic detail beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb (read) and resource (an entity's past) and cleanly splits the tool into two named modes with distinct semantics. An agent can tell exactly what it does without opening the schema, and the two-mode framing distinguishes it from simple retrieval siblings like memory_get.

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?

Gives explicit mode-selection logic (attribute given = slot mode, omitted = chain mode) and parenthetical example questions that map intent to mode. It stops short of naming alternative sibling tools or exclusion conditions, so it is clear context without full routing guidance.

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