Skip to main content
Glama

Delete memory

delete_memory
DestructiveIdempotent

Remove a saved memory or conclusion by its ID using a soft delete, freeing up space while retaining recoverability for local-first MCP clients.

Instructions

Soft-delete a saved memory or conclusion by id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations by disclosing that deletion is 'soft' rather than a permanent hard delete, which is not explicit in destructiveHint=true or idempotentHint=true. It does not elaborate on recovery or cascading effects, but the key non-obvious trait is clearly stated.

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 a single, tightly worded sentence with no filler. It front-loads the operation type and parameter semantics, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with annotations covering idempotency and destructiveness, the description is nearly complete. It accurately identifies what the tool does and the required id, though it could optionally clarify the difference between deleting a memory versus a conclusion and what the response contains.

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?

With schema coverage at 0%, the description carries the burden of explaining the 'id' parameter. It does say the operation acts by id on a saved memory or conclusion, which adds some meaning beyond the bare schema property, but it does not specify id format, provenance, or how to obtain a valid id.

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 uses a specific verb ('soft-delete') and names the resource ('saved memory or conclusion') plus the primary identifier dimension ('by id'). It also distinguishes itself from sibling tools like purge_memory by explicitly flagging the operation as a soft-delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies that the tool should be used when a soft-delete of a memory/conclusion by id is intended, and the 'by id' phrasing hints at the required input. However, it gives no explicit comparison with alternatives such as purge_memory, supersede_memory, or update_memory, so the when/when-not guidance 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.