Skip to main content
Glama
ClickHouse Loom

ClickHouse Loom

Official

loom_blacklist_add

Idempotent

Block future memory writes that match a pattern and, when sweep=true, tombstone already-saved matching rows in the chosen scope.

Instructions

WHAT: Every later memory write in the pattern's scope (this namespace by default) whose value matches pattern is refused. Refused to a token bounded to one user: a pattern refuses every user's writes. WHEN: An explicit 'never remember X' or 'don't store anything about Y'. Pass sweep=true only when the user also asks to forget what is already saved: it tombstones the matching rows up to the sweep cap, other writers' too. swept_truncated: true or a non-empty sweep_error means it did not finish: tell the user, and do not add the pattern again. WHEN NOT: Forgetting one saved fact is memory.delete. ARGS: pattern; optional pattern_type (substring | regex); scope: namespace (default), org (needs org admin) or global (needs platform admin); reason; sweep.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pattern": "<pattern>"
    },
    "name": "loom_blacklist_add"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNonamespace
sweepNo
reasonNo
patternYes
namespaceNo
created_byNo
pattern_typeNosubstring

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior3/5

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

The description adds substantial behavior beyond the annotations: admin requirements for org/global scope, a sweep cap, cross-writer tombstoning, and the `swept_truncated`/`sweep_error` completion signals. However, the disclosed sweep behavior (tombstoning matching rows, including other writers' rows) conflicts with the declared destructiveHint=false, so an agent reading only annotations would be misled about the destructive path.

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 WHAT/WHEN/WHEN NOT/ARGS layout is front-loaded and scannable, with no filler sentences. One line ('Refused to a token bounded to one user: a pattern refuses every user's writes') is grammatically murky and costs the reader a re-read.

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 7-parameter mutation tool with no output schema and no annotation detail, the description covers the important ground: privilege requirements, sweep risk and caps, and the failure-mode fields the caller must check. Only the undocumented `namespace` and `created_by` parameters keep it from being complete.

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 0%, so the description carries the burden. It documents 5 of 7 params meaningfully — the scope enum with its privilege gates, pattern_type enum, reason, sweep, and pattern — but omits `namespace` and `created_by` entirely, leaving two parameters undocumented in both schema and description.

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 WHAT section states a specific effect: every later memory write in the pattern's scope whose value matches `pattern` is refused. That is a concrete verb-plus-resource behavior an agent can distinguish from sibling tools, and the WHEN NOT line explicitly separates it from loom_memory_delete.

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 WHEN ('never remember X', 'don't store anything about Y'), explicit WHEN NOT with a named alternative (forgetting one saved fact is memory.delete), and a conditional rule for when to set `sweep=true`. It also tells the agent what to do on incomplete sweeps (report and do not re-add), which is actionable guidance, not just context.

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