Holographic Memory MCP

Overview Schema Source Related Servers Discussions Admin

Store memory

remember

Destructive

Store durable facts, decisions, or preferences as persistent memories; omit an id to create a new entry or supply one to replace an existing memory.

Instructions

Store a durable fact, decision or preference; use recall to find one instead. A supplied id replaces that memory, while an omitted id creates a new one. Use if_version to reject concurrent changes or create_only to reject overwrites.

Input Schema

Name	Required	Description
`id`	No	Stable id; replaces an existing memory with this id.
`tags`	No	Labels; filters match memories carrying every listed tag.
`text`	Yes	UTF-8 memory content; must be nonblank unless `allow_empty` is true. The server also enforces a byte limit and a 4,096-word limit.
`title`	No	Optional display title; does not change the id.
`metadata`	No	Arbitrary JSON object; keys starting with "hms." are reserved.
`if_version`	No	Version from `remember` or `get`; write only if the stored version still matches. Cannot combine with `create_only`.
`allow_empty`	No	Permit blank text for file-like use; otherwise blank text is rejected.
`create_only`	No	Reject the write if the chosen id already exists; cannot combine with `if_version`.

Output Schema

Name	Required	Description
`id`	Yes	Id of the stored memory.
`bytes`	Yes	Stored text size in UTF-8 bytes.
`created`	Yes	True when this call created an id.
`version`	Yes	New version for a later conditional update.
`namespace`	Yes	Store namespace used for the write.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Oct 26, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations flag destructiveHint=true, and the description supplies the reason an agent needs: supplying an `id` overwrites that memory, omitting it creates a new one. It also discloses the two opt-in guards against clobbering. It stops short of saying what happens to fields not supplied on replace, but that is the only meaningful gap.

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?

Two sentences, both load-bearing: the first establishes scope and the sibling routing, the second covers id semantics and the two guard parameters. The most decision-critical fact (replace vs create) is front-loaded after the routing hint.

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?

An output schema exists, so return values need no explanation, and the schema documents all eight parameters including tags, title, metadata and limits. The description fills the remaining conceptual gap – overwrite behavior and concurrency guards – so an agent has everything needed to call this correctly.

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 earns above baseline by explaining the interaction between `if_version` and `create_only` as a pair of mutually exclusive conflict strategies, rather than just restating the per-field definitions. It adds intent, not syntax, which the schema already handles.

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 (store) plus the resources it stores (durable fact, decision or preference), and explicitly routes the agent away from the sibling `recall`. The create-vs-replace distinction makes the operation unambiguous even before 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 Guidelines5/5

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

Names the alternative tool explicitly ('use `recall` to find one instead') and gives the conditions that select the two conflict-control modes: `if_version` for concurrent-change rejection, `create_only` for overwrite rejection. Nothing about when-to-use is left to inference.

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

Deploy Server