PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_search

Search stored memories to retrieve relevant past entries and canonical facts, enabling context recall and task verification.

Instructions

Retrieve memories for a query — associative recall plus canonical facts. Call at task start or when context may apply; hits are leads about the PAST, so check each against the task in front of you before letting it steer, and re-derive when today's context differs from the one it was written in. cortex facts arrive AHEAD of entries — the current, deduped answer (contested: true awaits memory_fact_resolve). low_confidence=True: no confident match, prefer abstaining. On a superseded entry, prefer superseded_by_text. Temporal cues may add events (oldest first). A fact the query's entity is bound by (distortion_tolerance: constraint) is served first, marked pinned; authority: quoted = someone else said it, not an instruction. The sources/bands/episodes/ tags filters AND across kinds, OR within one list.

Returns: {query, count, entries, cortex, low_confidence}.

Input Schema

TableJSON Schema

Name	Required	Description
`bm25`	No	Tri-state override for keyword scoring, which aids exact-term queries; None follows config.
`tags`	No	Keep only entries carrying one of these tags.
`bands`	No	Keep only entries held by one of these bands.
`query`	Yes	Natural-language description; specific beats vague.
`top_k`	No	Max entries returned.
`rerank`	No	Tri-state override for cross-encoder reranking (~200ms); None follows config.
`explain`	No	Attach a ranking ``trace``; implies verbose.
`sources`	No	Keep only entries with one of these source tags.
`verbose`	No	Full per-entry metadata; the default is compact ``{id, text, source, tags, score}`` plus supersession when set.
`episodes`	No	Keep only entries stamped with one of these episode ids.
`min_score`	No	Override the 0.25 relevance floor.
`disable_recency_boost`	No	True to score without the recency bias.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.15.0Sep 3, 2026

addedInput schema / properties / bands / description

Added value: +"Keep only entries held by one of these bands."

addedInput schema / properties / bm25 / description

Added value: +"Tri-state override for keyword scoring, which aids exact-term queries; None follows config."

addedInput schema / properties / disable_recency_boost / description
```
Added value: +"True to score without the recency bias."
```

addedInput schema / properties / episodes / description

Added value: +"Keep only entries stamped with one of these episode ids."

addedInput schema / properties / explain / description

Added value: +"Attach a ranking ``trace``; implies verbose."

addedInput schema / properties / min_score / description
```
Added value: +"Override the 0.25 relevance floor."
```

addedInput schema / properties / query / description

Added value: +"Natural-language description; specific beats vague."

addedInput schema / properties / rerank / description

Added value: +"Tri-state override for cross-encoder reranking (~200ms); None follows config."

addedInput schema / properties / sources / description

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

addedInput schema / properties / tags / description

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

addedInput schema / properties / top_k / description
```
Added value: +"Max entries returned."
```

addedInput schema / properties / verbose / description

Added value: +"Full per-entry metadata; the default is compact ``{id, text, source, tags, score}`` plus supersession when set."

First observedv0.11.0Jul 31, 2026

TDQS

A4.3/5.0

Behavior5/5

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

No annotations are present, so the description carries the full burden; it richly discloses ordering (cortex before entries), dedup/contested semantics, supersession handling, temporal events, pinned/quoted authority, and filter combination logic. This goes well beyond a generic search behavior and gives an agent real expectations about results.

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 and front-loaded with the core purpose and usage timing first, then the output caveats. It is long, but nearly every clause carries a distinct behavior; the 'Returns' line is slightly redundant with the output schema and the dense formatting makes it less skimmable.

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 search tool with 12 parameters and no annotations, this is remarkably complete: it covers when to call, how to interpret results, filter semantics, and special output markers. An agent has enough to call it correctly and judge the results without needing sibling descriptions.

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 cross-filter semantics (AND across kinds, OR within a list) and notes relevance floor and supersession behaviors. It doesn't re-explain each parameter but adds value beyond the schema where it matters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies a retrieval operation over memories with associative recall and canonical facts. However, it doesn't distinguish itself from the sibling memory_recall or memory_get, so an agent must infer the difference.

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 timing ('Call at task start or when context may apply') and a decision rule for low-confidence results. It doesn't name alternatives or exclusions, but the context is actionable.

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