Skip to main content
Glama
wazionapps

NEXO Brain

by wazionapps
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

nexo_memory_forget

Verifiably erase revoked secrets or correct facts from all memory stores. Supports hard deletion of sensitive data and soft correction of factual errors.

Instructions

SELECTIVE-FORGET: verifiably erase a revoked secret, or correct a fact.

Two modes, never mixed:

  • mode='secret' (HARD-FORGET): scrubs the secret from EVERY table of ALL LIVE DBs the agent retrieves from — nexo, cognitive, local-context, local-context-usage, and email — discovered by live introspection (sqlite_master + PRAGMA) over each subsystem's own canonical path resolver, not a curated list — plus every FTS index (incl. local_chunks_fts), on-disk transcripts, and legacy shadow DBs (cognitive

    • local-context). The row is DELETED where it IS the secret (or carries an embedding/FTS copy), and REDACTED in place where the secret is embedded in an otherwise-useful record (diary, item_history.note, local_chunks.text, entity_facts.value, change_log...). It then RE-ENUMERATES and RE-SCANS everything and only returns complete=True at total zero; any survivor (even in a table not anticipated) is reported as complete=False with its . location. Use ONLY for revoked credentials/secrets or toxic data. Destructive run requires dry_run=False AND confirm=True (a dry-run count is returned otherwise). HNSW persisted indices are invalidated. SCOPE: point-in-time backups / snapshots are NOT swept (retention) — rotate the secret; the report's backup_scope field states this so complete=True never overclaims.

  • mode='fact' (CORRECT-FACT): does NOT delete. Useful memory is preserved via the existing reversible supersede; correct it with nexo_learning_update / supersede instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesthe literal secret value to forget.
modeNo'secret' (default, hard) or 'fact' (soft, reversible).secret
dry_runNowhen True (default) only count matches; never mutate.
confirmNorequired (with dry_run=False) to actually delete in secret mode.
use_regexNoalso match generic secret-shaped tokens (secret mode only).
reasonNofree-text audit note recorded in the ledger.

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully details the destructive behavior of secret mode, including the comprehensive scope (multiple DBs, FTS indices, transcripts, shadow DBs), the redaction process, the confirmation requirement (dry_run=False + confirm=True), and the return conditions (complete=True only if zero survivors). It also notes HNSW index invalidation and backup scope limitations.

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 somewhat lengthy but well-organized with bullet points and mode headings. It is front-loaded with the core purpose and mode distinction. The verbosity is justified by the tool's complexity, though a slight reduction could improve conciseness without losing essential detail.

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?

Given the complexity of the tool, the description comprehensively addresses all necessary aspects: two modes, parameter usage, safety mechanisms, return values (complete=True/False with survivor reporting), and edge cases like backup scope. Even without an output schema, the description adequately describes the tool's behavior and results.

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?

Although the input schema already covers all 6 parameters with descriptions, the tool description adds significant context: it explains the role of 'reason' as an audit note, clarifies that 'dry_run' and 'confirm' control destructive execution, and specifies that 'use_regex' is limited to secret mode. This goes beyond the schema's basic definitions.

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 clearly identifies the tool as a selective forget mechanism with two distinct modes: 'secret' for hard deletion of revoked secrets and 'fact' for correcting facts without deletion. The verb 'erase' and 'scrubs' are specific, and the tool is well-distinguished from any likely siblings due to its unique purpose.

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?

The description explicitly states when to use each mode: secret mode for revoked credentials/secrets or toxic data, and fact mode for corrections, directing the agent to use nexo_learning_update for fact corrections instead. This provides clear guidance on alternatives and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wazionapps/nexo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server