PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_consolidation_candidates

Read-only

Find clusters of near-duplicate memories for consolidation by anchoring on a query or episode; review the candidates, synthesize a canonical note, and commit it via memory_consolidate.

Instructions

Find clusters of near-duplicate memories ripe for consolidation — the same thing phrased five ways across five sessions. Anchor with a query or an episode; read the clusters, synthesise one canonical note, then commit it via memory_consolidate.

Each member carries its id; commit with memory_consolidate(entry_ids=[...]) rather than the members' texts — IDs survive rewording and duplicate phrasing, exact text does not.

Returns: {count, clusters: [{cohesion, size, members}]}.

Input Schema

Name	Required	Description
`tags`	No	Consider only entries carrying one of these tags.
`query`	No	Topic-driven anchor: cluster memories near this description.
`top_k`	No	How many candidate entries to cluster over; positive integer.
`episode`	No	Session-driven anchor: cluster within this episode id.
`sources`	No	Consider only entries with one of these source tags.
`max_clusters`	No	Max clusters returned; positive integer.
`min_cohesion`	No	Minimum intra-cluster cosine — raise it to flag only near-duplicates.
`min_cluster_size`	No	Drop clusters with fewer members than this; positive integer.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.18.1Oct 14, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / max_clusters / description

Previous value: -"Max clusters returned."New value: +"Max clusters returned; positive integer."

addedInput schema / properties / max_clusters / minimum
```
Added value: +1
```

changedInput schema / properties / min_cluster_size / description

Previous value: -"Drop clusters with fewer members than this."New value: +"Drop clusters with fewer members than this; positive integer."

addedInput schema / properties / min_cluster_size / minimum
```
Added value: +1
```

changedInput schema / properties / top_k / description

Previous value: -"How many candidate entries to cluster over."New value: +"How many candidate entries to cluster over; positive integer."

addedInput schema / properties / top_k / minimum
```
Added value: +1
```

Changed8 schema fields changedv0.15.0Sep 3, 2026

addedInput schema / properties / episode / description

Added value: +"Session-driven anchor: cluster within this episode id."

addedInput schema / properties / max_clusters / description
```
Added value: +"Max clusters returned."
```
addedInput schema / properties / min_cluster_size / description
```
Added value: +"Drop clusters with fewer members than this."
```

addedInput schema / properties / min_cohesion / description

Added value: +"Minimum intra-cluster cosine — raise it to flag only near-duplicates."

addedInput schema / properties / query / description

Added value: +"Topic-driven anchor: cluster memories near this description."

addedInput schema / properties / sources / description

Added value: +"Consider only entries with one of these source tags."

addedInput schema / properties / tags / description

Added value: +"Consider only entries carrying one of these tags."

addedInput schema / properties / top_k / description

Added value: +"How many candidate entries to cluster over."

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuine context beyond that — this is read-only discovery feeding a separate mutation, and the ID-not-text commit contract matters because IDs survive rewording. It also discloses the return shape. It stops short of noting limits on how many clusters or entries are scanned beyond the schema's defaults.

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?

Three short paragraphs, purpose front-loaded, then the workflow, then the commit contract and return shape. The prose is dense but every clause carries actionable information; nothing is 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?

Covers purpose, anchor choice, the follow-up commit call, the ID-vs-text caveat, and the return shape, which is more than sufficient given an output schema already exists and annotations carry the safety profile.

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%, so the schema already documents all eight parameters including the topic-driven vs session-driven anchor distinction. The description restates the query/episode anchoring but adds no syntax, format, or interaction detail beyond it, so 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+resource ('find clusters of near-duplicate memories ripe for consolidation') and frames the scope precisely as a discovery step, clearly distinct from the sibling memory_consolidate which performs the write. An agent can separate the two tools 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 Guidelines5/5

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

Gives an explicit three-step workflow (anchor with query/episode, read clusters, synthesise, commit via memory_consolidate) and names the alternative tool for the write step. It also resolves the no-required-params ambiguity by telling the agent to supply an anchor.

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