PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_fact_get

Read-only

Retrieve the current value of a fact for a given entity and attribute from long-term memory, returning null if empty and conflict indicators if unsettled.

Instructions

Look up the one CURRENT value at an (entity, attribute) slot; open questions go to memory_search. A null record means EMPTY, not unknown. 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 (core)); 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 (full) shows the slot's version chain.

Input 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.18.1Oct 14, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

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 declare readOnlyHint=true and destructiveHint=false, and the description goes well beyond them: null means EMPTY not unknown, contenders signals an unsettled conflict, re_verify warns the value may be stale, and it discloses a backend difference (PostgreSQL keeps the warning after eviction, file mode has no durable retraction). This is unusually rich behavioral disclosure for a read tool.

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 core purpose is front-loaded in the first clause and every sentence carries information. It is dense with backtick notation and multiple nested concepts, which costs some readability, but there is little filler.

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?

Despite an output schema existing, the description supplies interpretation the schema cannot: what null, contenders, candidates and re_verify mean. An agent has everything needed to call and correctly interpret this tool.

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 baseline is 3. The description adds meaning beyond the schema by explaining that verbose=True brings in provenance, support and temporal stamp, complementing the schema's terser 'default drops bookkeeping keys'.

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+resource: 'look up the one CURRENT value at an (entity, attribute) slot'. It explicitly distinguishes itself from the sibling memory_search ('open questions go to memory_search'), so an agent can route correctly without opening either 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?

Gives clear routing guidance to memory_search for open questions and points to memory_fact_resolve for unsettled conflicts and memory_history for the version chain. It does not, however, state exclusions like when this tool is the wrong choice for a set-valued slot versus memory_set_add/remove.

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