PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_fact_get

Read-only

Retrieve the current value stored at an (entity, attribute) slot to check whether a fact is empty, conflicted, or verified before acting.

Instructions

Look up the one CURRENT value at an (entity, attribute) slot. One value per slot. A null record means EMPTY, not unknown — memory_search still finds context. A set-valued slot returns {kind: "set", members, removed} instead — members: [] means EMPTY too.

Returns: {record | null, contenders} (+ entity_ref when the entity has a graph node). Non-empty contenders = unsettled conflict (see memory_fact_resolve); on an empty slot, candidates lists nearby slots — ranked leads, not answers. re_verify = a memory this fact was derived from has since been corrected; the value still stands but check it before acting. Set slots carry it too, at the slot. PostgreSQL keeps this warning after the corrected source memory is evicted or deleted; file mode has no durable retraction warning. verbose=True adds the record's provenance, support and temporal stamp; memory_history shows the slot's version chain.

Input Schema

TableJSON Schema

Name	Required	Description
`entity`	Yes	The slot's subject; the (entity, attribute) match is case- and separator-insensitive.
`verbose`	No	Full record; the default drops bookkeeping keys.
`attribute`	Yes	The slot's attribute.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.16.0Oct 3, 2026

addedInput schema / properties / verbose

Added value: +{
+  "default": false,
+  "description": "Full record; the default drops bookkeeping keys.",
+  "title": "Verbose",
+  "type": "boolean"
+}

Changed2 schema fields changedv0.15.0Sep 3, 2026
- addedInput schema / properties / attribute / description
```
Added value: +"The slot's attribute."
```
- addedInput schema / properties / entity / description
```
Added value: +"The slot's subject; the (entity, attribute) match is case- and separator-insensitive."
```
First observedv0.11.0Jul 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only safety, so the description is free to add deeper semantics: null means EMPTY (not unknown), set slots return {kind: "set", members, removed}, non-empty contenders signal conflict, and re_verify flags a corrected source memory. It even distinguishes PostgreSQL durable warnings from file-mode behavior — context far beyond the annotations.

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: the core lookup and the null-is-empty rule come first, followed by return shape and edge-case flags. Nearly every sentence earns its place, though the return-format detail is heavier than strictly necessary 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 3-parameter read tool with a rich output schema and full annotation coverage, the description covers the edge cases an agent would otherwise misread: empty vs unknown, set-slot shape, conflict signaling, and staleness warnings. 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.

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. The description adds meaning beyond the schema's terse "Full record; the default drops bookkeeping keys" by specifying that verbose adds provenance, support, and temporal stamp. That is genuine added value over the structured field.

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 precise verb+resource+scope: "Look up the one CURRENT value at an (entity, attribute) slot." This clearly distinguishes it from memory_fact_set (writes a slot), memory_fact_resolve (settles conflicts), and memory_search (broad retrieval). An agent can identify the exact operation 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 Guidelines4/5

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

Routes the agent to alternatives with conditions: memory_search for context on empty slots, memory_fact_resolve for unsettled conflicts, memory_history for version chains. It lacks an explicit "use this instead of X when..." framing for the primary lookup case, but the sibling routing is concrete and actionable.

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