Skip to main content
Glama
ClickHouse Loom

ClickHouse Loom

Official

loom_memory_set

Idempotent

Saves user facts, preferences, and decisions to shared AI memory across tools, with auto-tagging and TTL support for temporary states.

Instructions

Save a fact to Loom — shared across every AI tool the user runs; native memory is the Claude-only scratchpad.

Call this proactively whenever the user states a personal fact, decision, preference, or current state — even without 'remember' or 'save'. Declarative statements ARE save triggers: 'my X is Y', 'I prefer X over Y', 'we decided X', 'we're at X', 'I deploy on X' — one call per fact.

Don't search before saving. A stated fact is a write, not a recall; the server dedups. Revision policy: if a read this session returned the key of a fact that has now changed or got more precise, update it under that same key with memory.update — never save a second copy and never delete + re-save. A fact about a new subject or scope gets its own memory_key (include the project / scope token in the key).

Auto-tag from scope words: 'for billing, X is Y' → tags=['billing']; same for person / topic mentions.

Do NOT save: questions, code help, world knowledge, acknowledgements, hypotheticals, echoes of your own words.

Writes land in ONE namespace (the caller's home); pass namespace=<name> only to write elsewhere. Don't override memory_type (defaults semantic); use tags for classification. Cite the response's namespace and memory_key in your confirmation; conflict_verdict, peers and next say what the store held (dry_run=true checks without writing). value is stored verbatim — never base64 (kills search; see advisories).

A fact with a natural lifetime gets one at write time. A deadline, a temporary state ('on call this week'), a rotating value: pass ttl_seconds AND on_expire (tombstone | demote | anonymize) in the SAME call — the sweep applies it when the time passes. Without on_expire the row just stops being current.

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": {
      "memory_key": "<memory_key>",
      "value": "<value>"
    },
    "name": "loom_memory_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNo
filesNo
valueYes
pinnedNo
run_idNo
dry_runNo
entitiesNo
proposedNo
valid_atNo
valid_toNo
namespaceNo
on_expireNo
confidenceNo
memory_keyYes
memory_typeNosemantic
sensitivityNo
ttl_secondsNo
clear_expiryNo
expire_reasonNo
if_match_sha256No
source_resource_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, and the description still adds real value: server-side dedup, the single-home namespace default, verbatim storage with a base64 warning, TTL sweep semantics requiring ttl_seconds plus on_expire in the same call, and what dry_run does. It stops short of describing conflict resolution behavior or permission requirements for writing outside the home namespace.

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?

Bold front-loaded rules ('Call this proactively', 'Don't search before saving', 'Do NOT save') make it scannable despite the length, and the length is defensible for a 21-parameter tool. A few sentences, such as the auto-tagging example block, could be trimmed without losing meaning.

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?

With no output schema, the description helpfully names the response fields an agent should act on (namespace, memory_key, conflict_verdict, peers, next, advisories). For a 21-parameter mutation tool the main remaining hole is the undocumented long tail of optional parameters like if_match_sha256, sensitivity, and valid_at/valid_to.

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 coverage is 0% across 21 parameters, so the description must carry the load; it explains namespace, memory_type, tags, value, ttl_seconds, on_expire, memory_key, and dry_run meaningfully. Roughly fourteen parameters (files, pinned, run_id, entities, proposed, valid_at/valid_to, confidence, sensitivity, clear_expiry, expire_reason, if_match_sha256, source_resource_id) get no explanation at all, so the coverage gap is real.

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?

Names a specific verb and resource ('Save a fact to Loom') and immediately scopes it against a contrasting store ('native memory is the Claude-only scratchpad'). The later revision policy also separates it from memory.update, so an agent can distinguish the write paths without opening a 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 states when to call ('Call this proactively whenever the user states a personal fact...'), enumerates trigger patterns, and gives exclusions ('Do NOT save: questions, code help, world knowledge, acknowledgements, hypotheticals'). It also resolves ordering ambiguity with the sibling ('Don't search before saving') and routes revisions to memory.update under the same key.

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