Skip to main content
Glama
cosmiccoder200x-sys

local-brain-mcp

by cosmiccoder200x-sys
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

brain_forget

DestructiveIdempotent

Remove or deprecate outdated memories from Local Brain by ID, file path, or search query. Deprecates by default for audit trail; hard delete purges permanently.

Instructions

Remove or deprecate specific memories from Local Brain. Can target a memory by ID, file path, or search query. By default deprecates the memory to maintain audit trail; pass hard_delete: true to purge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoExact memory ID to forget.
queryNoForget memories matching this text/topic.
file_pathNoForget all memories associated with this file path.
memory_idNoAlias for id.
hard_deleteNoIf true, permanently deletes records from SQLite. Default is false (marks deprecated).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / memory_id
      Added value: +{
+  "description": "Alias for id.",
+  "type": "number"
+}
  2. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations already marking destructiveHint=true, the description adds crucial nuance: it defaults to deprecation to preserve an audit trail, and only purges records when hard_delete=true. This meaningfully explains what gets changed or destroyed and under what condition.

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 with no filler. The core action and target scope are front-loaded, followed by targeting modes and the key behavioral caveat about hard_delete. Every clause earns its place.

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 destructive tool with 5 parameters and no output schema, the description covers the essential operational details: what it removes, how to target memories, the default non-destructive behavior, and how to override it. The audit-trail rationale also helps the agent anticipate consequences. No critical invocation information is missing.

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 adds value by grouping the parameters into three targeting modes (ID, file_path, query), implying they are alternative ways to select memories, and by clarifying the default soft-delete behavior versus hard_delete=true. This exceeds the schema's per-parameter descriptions.

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 specific verbs ('Remove or deprecate') with a clear resource ('specific memories from Local Brain') and immediately explains the targeting options (ID, file path, search query). This distinguishes it from sibling tools like brain_prune by emphasizing targeted, individual-memory operations.

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?

The description clearly communicates when to use this tool: to forget specific memories by ID, path, or query. It doesn't explicitly contrast with brain_prune or list exclusions, so it stops short of a full when-to-use/when-not-to-use guide, but the context is clear.

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

Deploy Server

Other Tools