Spomory

Overview Schema Source Related Servers Discussions Admin

forget_all_memory

Destructive

Delete the entire memory graph in one action. First call shows what would be removed; a second call with confirm deletes everything.

Instructions

Permanently delete the entire memory graph -- every entity and relation.

forget_memory is deliberately one-fact-at-a-time; this is its bulk counterpart for a user who wants a clean slate (e.g. before re-testing, or a genuine full data wipe) instead of narrowing and retrying a query N times.

destructive_hint=True on this tool's annotations is only a hint -- the MCP spec doesn't require a host to gate on it, so a host that treats it as advisory (or an agent auto-approving destructive tools) could otherwise wipe everything on the first call with no human in the loop at all. confirm is the actual enforcement: the first call (confirm left at its default, False) never deletes anything -- it only reports what a real call would remove -- so triggering a wipe needs an explicit second call with confirm=True, regardless of what the host's UI does or doesn't show.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`confirm`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.1Sep 22, 2026

addedInput schema / properties / confirm

Added value: +{
+  "default": false,
+  "title": "Confirm",
+  "type": "boolean"
+}

First observedv0.1.0Sep 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations provide destructiveHint=true but the description adds essential behavior beyond that: the first call with confirm=false is a dry run that only reports what would be removed, and only a second call with confirm=true actually deletes. It also explains that destructive_hint is just a hint and may not be enforced by hosts, making the confirm parameter the real enforcement. This is substantial non-annotation context.

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 description is four sentences and each carries new information: core action, sibling contrast, host enforcement caveat, and confirmation protocol. It is front-loaded with the primary purpose, but it is slightly longer than strictly necessary; the caveat about destructive_hint could arguably be condensed. Overall, well-structured but not maximally concise.

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?

There is one parameter, and the description explains it exhaustively, including its confirmation semantics. Return values are covered by the output schema. The tool's destructive nature, safety mechanism, and relation to siblings are all described. No essential calling information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the only parameter is a boolean `confirm` with default false. The description fully explains its meaning: the default leaves it a no-op reporting call, and confirm=true triggers the actual wipe. This completely compensates for the missing schema description.

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 opens with 'Permanently delete the entire memory graph -- every entity and relation,' which states the exact verb and resource. It then explicitly contrasts with the sibling `forget_memory` ('deliberately one-fact-at-a-time') by calling itself the 'bulk counterpart,' so an agent can disambiguate without opening schemas.

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?

It names the alternative tool (`forget_memory`) and gives the specific condition for choosing this one: a user who wants a clean slate (e.g., before re-testing or a genuine full data wipe) instead of narrowing and retrying a query. This directly answers when to use it versus the sibling.

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

Deploy Server