Skip to main content
Glama

memory_invalidate

Invalidate a memory without deleting it, preventing future injection and hiding it from lists while preserving an audit trail.

Instructions

Invalidate a direction-layer memory — mark it invalid without deleting.

方向层偏好过时/被推翻时显式失效(Zep 失效语义:置 invalid_at 不删除, 保留可审计轨迹)。失效后不再进注入,也默认不出现在 memory_list。

两种定位方式,二选一:memory_id 精确定位,或 content_match 子串定位 (手里只有原文时免去先查一次 id——被配额顶回来的那一刻正是这种处境)。 子串必须唯一命中当前上下文的有效条目:命中 0 条或多条一律不动数据,多条时 返回候选让你给出更精确的子串。两种方式可达的条目相同:global + user + 当前项目的 project 桶,别的项目的条目按不存在处理。

global / user 条目被所有项目的会话继承,未带确认时拒绝并交回条目原文 (requires_confirmation=true,不动数据):把原文交用户过目,确认后带 confirm_shared_scope=true 重试。当前项目的条目不需要确认。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
memory_idNo要失效的方向层记忆 id(与 content_match 二选一)
content_matchNo唯一定位子串,在有效条目正文中精确匹配(与 memory_id 二选一)
confirm_shared_scopeNo目标是 global/user 共享条目时须为 true,表示用户已过目 确认失效;默认 false,此时共享条目一律拒绝不动

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.15.0
    • addedInput schema / properties / confirm_shared_scope
      Added value: +{
      +  "default": false,
      +  "description": "目标是 global/user 共享条目时须为 true,表示用户已过目\n确认失效;默认 false,此时共享条目一律拒绝不动",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changedv1.11.2
    • addedInput schema / properties / content_match
      Added value: +{
      +  "default": "",
      +  "description": "唯一定位子串,在有效条目正文中精确匹配(与 memory_id 二选一)",
      +  "type": "string"
      +}
    • addedInput schema / properties / memory_id / default
      Added value: +""
    • changedInput schema / properties / memory_id / description
      Previous value: -"要失效的方向层记忆 id"New value: +"要失效的方向层记忆 id(与 content_match 二选一)"
    • removedInput schema / required
      Removed value: -[
      -  "memory_id"
      -]
  3. First observedv1.9.0

TDQS

A4.8/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 does so: it discloses non-destructive invalidate semantics (invalid_at set, audit trail preserved), exclusion from injection and default listing, the refusal-with-原文 behavior on shared scope (requires_confirmation=true, no mutation), and the 0-match/ambiguous-match no-op with candidate return.

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?

Front-loaded with the core verb and the non-deletion guarantee, then layers the branches. Dense but mostly earns its length; the parenthetical about Zep semantics and the quota aside are mildly redundant with the surrounding sentences.

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?

An output schema exists, so return values need not be explained, and the remaining agent-critical facts (mutation safety, confirmation gate, ambiguity handling, reachable scope) are all present. Nothing needed to invoke this correctly 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, but the description adds real meaning: it enforces the either/or exclusivity of memory_id vs content_match, states content_match must uniquely hit a currently-valid entry, and explains that the two methods reach the same bucket set (global + user + current project). It does not add syntax detail beyond that.

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 precise verb+resource ('Invalidate a direction-layer memory') and immediately scopes the semantic difference from deletion. It also clarifies downstream effects (no longer injected, absent from memory_list by default), which distinguishes it from siblings like memory_list and memory_add.

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?

Explicit trigger ('方向层偏好过时/被推翻时'), an explicit choice between two mutually exclusive locating strategies, and the exact condition under which the global/user-scope confirmation branch fires. It even names the practical scenario (quota-blocked, only raw text in hand) that selects content_match over memory_id.

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