Skip to main content
Glama

delete_episode

Delete one episode by ID when recorded content must not exist, such as accidental PII, sensitive data, or wrong recordings. Cascades associations, logs an audit entry, and is irreversible.

Instructions

Delete a single episode by ID. Use this for content that should not exist: accidentally recorded PII, sensitive data, or fundamentally wrong recordings. Do NOT use for factual corrections — record a new episode with the correction instead and let compression resolve it. Deletion cascades: all Hebbian associations involving the episode are removed, and the deletion is logged in the audit trail. The text is removed from the episodes table and overwritten in the database file (secure_delete); the WAL is emptied after the delete, or at the store's next delete or close if another connection is reading at that moment. By default, a tombstone is preserved as an existence proof for audit integrity: episode ID, original timestamp, episode type, and a content hash keyed by a per-store salt; a new episode's id is keyed by it too. The salt is kept in the database, never in the audit trail, so a guess at deleted content cannot be checked against the audit trail alone; whoever holds the database file can still guess short content from the tombstone. Disable tombstones at Store construction (keep_tombstones=False) if no hash should stay in the database. Episodes recorded before the store was upgraded, and team-imported episodes, carry an unsalted hash and id, which can be guessed for short content. The audit trail keeps each event's source, time and type in clear. Not reached: backups, the migration's .bak copy, other copies of the file, and text already consolidated into continuity or a pattern's stored explanations. The hash chain remains verifiable either way. This action is irreversible.

Input Schema

NameRequiredDescriptionDefault
episode_idYesThe 8-character hex ID of the episode to delete. Use recall or prepare_wrap to find episode IDs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.3
  2. Removed
  3. Addedv0.3.0

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it does: cascading removal of Hebbian associations, audit-trail logging, secure_delete overwrite, WAL behavior, tombstone semantics with salted hashes, irreversibility, and explicit limits (backups, .bak copies, consolidated text are NOT reached). This is far beyond what any annotation could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are admirably front-loaded and the structure is logical (purpose → when/when-not → mechanics → limits → irreversibility). However, roughly three quarters of the text is dense cryptographic/tombstone detail whose marginal value to a tool-selection decision is limited, making it over-sized for a single-parameter operation.

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?

With no output schema and no annotations, the description must stand alone — and it fully covers safety profile, side effects, reversibility, and audit implications. An agent has everything needed to decide correctly.

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% and the schema already documents the 8-character hex ID plus where to find IDs (recall/prepare_wrap). The description only restates 'by ID' and adds no format or lookup guidance beyond the schema, 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 ('Delete a single episode by ID') and immediately scopes it against alternatives in the sibling set (record/recall). An agent can distinguish this from record and crystal_index without opening any 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?

Explicitly gives when-to-use ('content that should not exist: PII, sensitive data, wrong recordings') and when-not ('Do NOT use for factual corrections — record a new episode with the correction instead'), naming the alternative tool and the rationale (compression will resolve it). Nothing 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.