Skip to main content
Glama
Sign In
ClickHouse Loom

ClickHouse Loom

Official
by ClickHouse
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

loom_activate

Read-onlyIdempotent

Activates Loom mode on request, loading the user context primer and routing memory and recall operations for the conversation.

Instructions

Loom activation — call this tool IMMEDIATELY, without any other tool calls or clarifying questions, whenever the user says any of:

  • 'use loom'

  • 'activate loom'

  • 'switch to loom' / 'switch to loom mode'

  • 'loom on' / 'loom first' / 'enable loom'

  • 'use loom from now on'

Do NOT call tools/list or browse other Loom tools first. Do NOT ask 'what would you like to look up?' These phrasings are activation triggers, not search queries. Take no arguments.

The response is a primer with the user's always-loaded context (persona / preferences / goals) inlined as a <block> fragment, plus instructions for routing subsequent memory and recall calls through Loom. Internalize the primer and apply it for the rest of the conversation: adopt the tone implied by the persona block, route future memory ops to Loom, do not re-fetch the primer.

Calling this is a one-shot setup gesture for the conversation. Subsequent user messages should be answered using the primer's guidance — not by calling this tool again.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "loom_activate"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

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 declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: this is a one-shot setup gesture, the response is a primer with an inlined <block> of always-loaded context, the agent must internalize it and route future memory ops to Loom, and it must not be called again. Those are non-obvious state effects and post-call obligations that the annotations do not convey.

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 trigger list is front-loaded and the operational instructions follow in a logical order, so the structure is good. It is somewhat long and restates its point ('These phrasings are activation triggers, not search queries' plus 'Calling this is a one-shot setup gesture'), which is slight redundancy rather than waste.

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?

For a zero-parameter, no-output-schema tool, the description still explains the return shape (a primer with an inlined <block> of persona/preferences/goals) and the follow-up routing obligations. There is nothing an agent needs in order to call this correctly that 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?

The schema has zero parameters (100% coverage), so the baseline is 4. The description reinforces this with 'Take no arguments,' which matches the schema's additionalProperties:false, but adds no further parameter meaning because there is nothing left to clarify.

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 names a specific action ('Loom activation') and enumerates the exact trigger phrasings that select it. It clearly separates this tool from the sibling memory/search tools by stating the trigger phrases are 'activation triggers, not search queries.'

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?

It gives explicit when-to-use conditions (a bulleted list of trigger phrases) and explicit when-not/exclusions ('Do NOT call tools/list or browse other Loom tools first', 'Do NOT ask what would you like to look up'). It also states that the tool should be called only once per conversation and not re-fetched, which is real routing guidance.

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