Skip to main content
Glama
sleepunit-agents

loom

by sleepunit-agents
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

knowledge_move

Re-key or re-domain knowledge pages in place, preserving the same UUID, citations, and verification history. Supports single-page, slug-list batch, and domain-prefix subtree moves.

Instructions

Re-key or re-domain a knowledge page in place — same row, same uuid, citations and verification history preserved. Three modes: (1) Single-page: provide slug + new_slug and/or new_domain. Slug rename writes a supersessions pointer (old→new) unless leave_pointer=false. If new_slug already exists, the call is rejected — use knowledge_merge instead. (2) Batch by slug list: provide slugs array + new_domain to re-home multiple pages atomically. (3) Batch by domain prefix: provide from_domain_prefix + to_domain_prefix to re-home a whole subtree in one transaction.

Input Schema

NameRequiredDescriptionDefault
slugNoCurrent slug of the page to move (single-page mode)
slugsNoBatch mode: list of slugs to re-domain. Requires new_domain. Atomic — rolls back on any missing slug.
new_slugNoNew slug (re-slug). Collision with an existing page is rejected — use knowledge_merge instead.
new_domainNoNew domain for the page (single-page re-domain or shared target for batch-by-slugs mode)
leave_pointerNoWrite a supersessions pointer old_slug→new_slug when the slug changes. Default true.
to_domain_prefixNoBatch prefix mode: replacement domain prefix (e.g. "instruments/elektron").
from_domain_prefixNoBatch prefix mode: domain prefix to replace (e.g. "gear/elektron"). Requires to_domain_prefix.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv0.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the coarse profile (mutating, non-idempotent, not destructive). The description adds substantive behavior beyond that: a supersessions pointer old→new is written on rename unless leave_pointer=false, collisions are rejected rather than merged, and batch modes are atomic with rollback on any missing slug.

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 action and the in-place guarantee, then structured as three numbered modes. Information-dense with little waste, though the long single paragraph could be trimmed slightly around the mode labels.

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 7-parameter, zero-required-parameter mutation tool with no output schema, the description covers all three invocation shapes, the atomicity guarantees, and the cross-tool escape hatch. An agent has everything needed to call it correctly.

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 by mapping parameters to modes (which combinations are valid per mode) and clarifying leave_pointer's default-on pointer semantics and the collision behavior of new_slug.

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 specific verb (re-key/re-domain) and resource (knowledge page), and explicitly scopes it in place: 'same row, same uuid, citations and verification history preserved.' It also names the sibling it is distinguished from (knowledge_merge), so an agent can route without opening either 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?

Enumerates three concrete modes with the exact parameters each requires (slug + new_slug/new_domain; slugs + new_domain; from_domain_prefix + to_domain_prefix). It states the negative condition explicitly: a colliding new_slug is rejected, so use knowledge_merge instead.

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