Skip to main content
Glama
sleepunit-agents

loom

by sleepunit-agents
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

knowledge_maintain

Read-only

Audit the knowledge store for thin expansion candidates, cold pages, misfiled notes, and person-page conflicts, then pair with knowledge_write to act on findings.

Instructions

Read-only health report for the knowledge store. Four branches: (1) expansion candidates — thin body + high hit_count (needs deepening); (2) cold pages — not accessed recently (unused or undiscovered); (3) misfile audit — provisional sourcing or conversation-only citations (world/ class: should be in the memory store instead — including pages that drifted in as personal/inner-monologue content rather than shared-ready synthesis, which matters more now that knowledge is read by other identities and by Jonathan, not just you; ours/ class with internal sourcing are NOT misfiles — they are correct); (4) person-page check — an active page whose slug or title names a person card (its slug or exact name, whole words) may belong on the card instead; a report, not enforcement. Only the full loom server runs (4); the knowledge-only server says it was not run. Cold/expansion ranking reads the shared hit_count/last_accessed aggregate (any reader's access keeps a page warm), not a per-identity breakdown — per-reader stats exist (knowledge_access) for attribution, but splitting cold-ranking by identity would make the list miss pages a different reader keeps alive. Pair with knowledge_write to act on findings.

Input Schema

NameRequiredDescriptionDefault
cold_daysNoDays without access before a page is cold (default 30)
thin_body_thresholdNobody char ceiling to consider a page thin (default 500)
expansion_hit_thresholdNohit_count floor for expansion candidates (default 3; 0 considers every page)

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.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description goes well beyond them: it explains that cold/expansion ranking uses the shared hit_count/last_accessed aggregate rather than a per-identity split (and why), that only the full loom server runs branch (4) while the knowledge-only server skips it, and that the output is 'a report, not enforcement.' That is substantive behavioral context beyond the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, which is good, but the body is a dense wall of nested parentheticals and self-referential asides that is hard to scan. The content largely earns its place given the four-branch scope, but the structure could be tightened into clearly delineated branches.

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?

No output schema exists, so the description carries the full burden of describing what the report contains, and it does so thoroughly via the four named branches plus the ranking caveat and the server-variant note. An agent knows what it will get back and how to interpret ambiguous cases (e.g., ours/ with internal sourcing is not a misfile).

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 100%, so the schema already documents cold_days, thin_body_threshold, and expansion_hit_threshold with defaults and bounds. The description adds no parameter syntax or edge-case meaning beyond what the schema provides, so the baseline 3 is correct.

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+resource immediately: 'Read-only health report for the knowledge store,' then enumerates four concrete branches (expansion candidates, cold pages, misfile audit, person-page check). An agent can distinguish this from knowledge_recall, knowledge_verify, and knowledge_history without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the branch descriptions, and 'Pair with knowledge_write to act on findings' is a useful action hint. However, there is no explicit statement of when to invoke this versus siblings like knowledge_verify or memory_audit, and no exclusions are drawn regarding tool selection (only interpretation of the report).

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