Skip to main content
Glama
ClickHouse Loom

ClickHouse Loom

Official

loom_search

Read-onlyIdempotent

Search Loom memory, profile sections, uploaded documents, past conversations, and repository docs/decisions in one query to answer questions about prior decisions and discussed topics.

Instructions

Unified search across the user's Loom content — memory (facts, preferences, decisions), profile (always-loaded persona sections), knowledge (uploaded documents) and past conversations — four searches, one round-trip; under a code scope, also the repository's docs and decisions. This is THE search tool: call it before answering any 'what do I / what did we decide / have we discussed X' question.

One call per question. If the answer is in the response, use it; if it is empty, fall through to native memory rather than declaring 'nothing in Loom'. Re-call on a NEW question, never on the same question in the same turn.

Paging. memory.candidates_total is how many memories matched; memory.results is the top of that list. When memory.next_page is set AND the answer is not in hand (a list, a count), call again with page = memory.next_page to read the next slice. Stop when next_page is empty or the answer is complete.

Namespaces are selected server-side (your own memory-kind namespaces, up to a cap; code/QA indexes have their own tools); no namespace argument. Do NOT call for general knowledge, arithmetic, or code/syntax help.

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": {
      "query": "<query>"
    },
    "name": "loom_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoA `memory.next_page` handle from a previous loom_search response: serves the next slice of that same ranked list without searching again. Leave empty for a new question.
tagsNoKeep only rows carrying ANY of these tags. A coding session's rows carry `project:<folder>` and `repo:<id>` (the id the session primer names); pass the repo tag to stay within this repository.
queryYes
top_kNo
bodiesNoHow much of each memory body to return: excerpt (the default: 200 chars, a decision or constraint as stored; fetch the rest with memory.get), full (the 1,200-char stored clip), unit (whole stored values by rank until body_budget_tokens), or none (keys and scores only).excerpt
recipeNoOptional retrieval profile. Empty uses Loom's default; fast is cheapest, quality widens hybrid recall, verbatim/code favor lexical matches, temporal and graph specialize retrieval.
explainNoAppend a `why:` note per memory hit naming the ranking terms that placed it (key match, date proximity, entity, plane gate, …) and the server's provenance note.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly/idempotent/non-destructive), yet the description still adds real behavior: one-call-per-question policy, the meaning of memory.candidates_total vs memory.results vs memory.next_page, paging stop conditions, and that namespaces are chosen server-side up to a cap. That is substantive context an agent cannot get from the structured fields.

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?

Three bolded sections with the imperative call-first rule front-loaded, and each sentence carries usable instruction. Some emphatic phrasing ('This is THE search tool') is slightly redundant but not wasteful enough to hurt.

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?

With no output schema, the description supplies the return shape an agent needs (candidates_total, results, next_page, why notes), plus the fallback behavior when results are empty. For a seven-parameter, multi-plane search this is complete enough to call correctly without further reading.

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 71% and the schema already documents page, tags, bodies, recipe and explain well. The description still adds operational meaning the schema only implies: that page is a resume handle for the same ranked list rather than a new search, and that no namespace argument exists because selection is server-side. top_k is untouched in the prose, a minor gap.

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?

Opens with a specific verb+resource and enumerates the four content planes it spans (memory, profile, knowledge, conversations), then adds the code-scope extension to repo docs and decisions. It explicitly carves territory away from sibling tools by noting that code/QA indexes have their own tools and that namespace selection is server-side.

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?

Gives a concrete trigger ('what do I / what did we decide / have we discussed X'), explicit exclusions (general knowledge, arithmetic, code/syntax help), and a fall-through rule when results are empty rather than declaring nothing exists. It also states a re-call discipline (new question only, not the same question in the same turn).

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