PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_graph_review

Review pending knowledge-graph proposals and issue verdicts before changes apply. Settle links, merges, duplicates, and junk findings to keep stored facts accurate and the graph clean.

Instructions

Work the graph review queue — deep-dream proposals that need a verdict before they touch the graph.

Actions: list: pending findings/proposals. propose: file link proposals for review. relate: related-not-duplicate verdict — writes the relation edge and dismisses the pair. dismiss_pair: mark src/dst genuinely distinct. dismiss_slot_pair: same for lesson/world duplicate listings. restore_slot: undo a lesson/world forget (forgets retire, never delete) — store + src (the retired key). accept_link/reject_link: settle an edge proposal by id. accept_merge: fold a near-duplicate into its twin. accept_junk: delete an over-extraction artifact. reject_entity: keep the entity, dismiss the proposal.

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`dst`	No	relate/dismiss_pair: the second entity. dismiss_slot_pair: an "entity\|attribute" key from the deep response.
`src`	No	relate/dismiss_pair: the first entity. dismiss_slot_pair: an "entity\|attribute" key from the deep response; restore_slot: retired key or entity.
`scope`	No	list: keep only findings of this kind.
`store`	No	dismiss_slot_pair / restore_slot: which store the key belongs to — "lesson" or "world".
`action`	No		list
`relation`	No	relate: the edge relation to write, from the graph vocabulary.
`proposals`	No	propose: ``[{src, relation, dst, similarity?, rationale?}]``.
`proposal_id`	No	Id actions: the one proposal to settle.
`proposal_ids`	No	Id actions: settle many proposals in one call, instead of ``proposal_id``.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.15.0Sep 3, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "propose",
-  "relate",
-  "dismiss_pair",
-  "dismiss_slot_pair",
-  "accept_link",
-  "reject_link",
-  "accept_merge",
-  "accept_junk",
-  "reject_entity"
-]New value: +[
+  "list",
+  "propose",
+  "relate",
+  "dismiss_pair",
+  "dismiss_slot_pair",
+  "restore_slot",
+  "accept_link",
+  "reject_link",
+  "accept_merge",
+  "accept_junk",
+  "reject_entity"
+]

addedInput schema / properties / dst / description

Added value: +"relate/dismiss_pair: the second entity. dismiss_slot_pair: an \"entity|attribute\" key from the deep response."

addedInput schema / properties / proposal_id / description

Added value: +"Id actions: the one proposal to settle."

addedInput schema / properties / proposal_ids / description

Added value: +"Id actions: settle many proposals in one call, instead of ``proposal_id``."

addedInput schema / properties / proposals / description

Added value: +"propose: ``[{src, relation, dst, similarity?, rationale?}]``."

addedInput schema / properties / relation / description

Added value: +"relate: the edge relation to write, from the graph vocabulary."

addedInput schema / properties / scope / description

Added value: +"list: keep only findings of this kind."

addedInput schema / properties / src / description

Added value: +"relate/dismiss_pair: the first entity. dismiss_slot_pair: an \"entity|attribute\" key from the deep response; restore_slot: retired key or entity."

addedInput schema / properties / store / description

Added value: +"dismiss_slot_pair / restore_slot: which store the key belongs to — \"lesson\" or \"world\"."

Changed3 schema fields changedv0.14.0Aug 22, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "propose",
-  "dismiss_pair",
-  "dismiss_slot_pair",
-  "accept_link",
-  "reject_link",
-  "accept_merge",
-  "accept_junk",
-  "reject_entity"
-]New value: +[
+  "list",
+  "propose",
+  "relate",
+  "dismiss_pair",
+  "dismiss_slot_pair",
+  "accept_link",
+  "reject_link",
+  "accept_merge",
+  "accept_junk",
+  "reject_entity"
+]

addedInput schema / properties / proposal_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Proposal Ids"
+}

addedInput schema / properties / relation

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Relation"
+}

First observedv0.11.0Jul 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that relate writes an edge and dismisses the pair, accept_junk deletes an artifact, restore_slot undoes a forget, and reject_entity keeps the entity. It stops short of stating irreversibility or side effects of every destructive action, but the per-action behavior is substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long because the tool is a multi-action dispatcher with 11 operations, but every bullet earns its place with a compact one-line semantics. The purpose is front-loaded, and the action list is scannable without redundancy.

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 complex, high-parameter tool with no annotations, the description is remarkably complete: it covers every action, notes the return shape ('per-action dict; {error} on bad input'), and relies on the existing output schema for return-value details. No critical calling context is left entirely to inference.

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 89%, so the baseline is 3. The description adds value on top by mapping actions to parameters, such as restore_slot needing store + src, and relate/dismiss_pair using src/dst. It clarifies which parameter combinations matter for which action.

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?

The description clearly identifies a specific responsibility — working the graph review queue for deep-dream proposals requiring a verdict before graph mutation. Each action is explicitly named with a one-line purpose, which disambiguates this from direct graph-editing siblings like memory_graph_relate and memory_graph_unrelate.

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?

The description gives clear context: this tool handles pending proposals/findings that need a verdict. It does not explicitly name alternatives or state when not to use it, but the action list and 'before they touch the graph' framing make the intended usage obvious.

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