Skip to main content
Glama
sleepunit-agents

loom

by sleepunit-agents
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

knowledge_verify

Verify a knowledge page's claims without editing its body by stamping verification time, recording the verifier and outcome, and optionally adding a dated note.

Instructions

Stamp a knowledge page as verified WITHOUT touching its body — sets verified_at and optionally freshness_anchor, and records an attributed verification (verifier, outcome, whether citations were checked) — the verifier is always YOUR loom identity, resolved server-side, never a field you can set. This is the verification engine's primitive: use it (never knowledge_write) to record "claims still hold". An optional note appends a dated "## Verification" section to the body (append-only, single-page mode). Batch mode (slugs) stamps many pages with a shared timestamp; archived pages are rejected; a batch with any unknown slug is rejected whole.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional verification note — appended to the body as a "## Verification — <date>" section. Never replaces the body. Single-page mode only.
slugNoSingle-page mode: slug of the page to verify.
slugsNoBatch mode: stamp many pages at once. Mutually exclusive with slug; note and freshness_anchor are not allowed in batch mode.
outcomeNoWhat this verification found. Defaults to "confirmed" (the claims still hold). "stale" flags it as out of date without fixing it — recorded in the audit trail but verified_at is NOT advanced, so the page stays at the front of the stale-first queue; "corrected" means you fixed it (pair with a knowledge_write, or the note field, describing the fix).
verified_atNoISO timestamp to stamp. Defaults to now.
citation_checkedNoDid you actually check the page's citations against their sources (not just the body text)? Defaults to false.
freshness_anchorNoNew freshness anchor (e.g. "Syntakt OS 1.41"). Preserved when omitted. Single-page mode only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields 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"
    • addedInput schema / properties / citation_checked
      Added value: +{
+  "description": "Did you actually check the page's citations against their sources (not just the body text)? Defaults to false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / outcome
      Added value: +{
+  "description": "What this verification found. Defaults to \"confirmed\" (the claims still hold). \"stale\" flags it as out of date without fixing it — recorded in the audit trail but verified_at is NOT advanced, so the page stays at the front of the stale-first queue; \"corrected\" means you fixed it (pair with a knowledge_write, or the note field, describing the fix).",
+  "enum": [
+    "confirmed",
+    "stale",
+    "corrected"
+  ],
+  "type": "string"
+}
  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 safety profile (non-read-only, non-destructive, closed-world). The description adds substantial behavioral context beyond that: the verifier is server-resolved and never a settable field, the note is append-only, batch mode uses a shared timestamp, and rejected inputs fail whole rather than partially.

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 scope, and every clause carries information. It is dense and run-on with heavy em-dash nesting, which slightly reduces scannability, but there is little filler to cut.

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 still covers both operating modes, rejection behavior, attribution semantics, and body-preservation guarantees — enough for an agent to invoke it correctly in either single-page or batch form.

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 schema already documents all seven parameters; the description reinforces meaning and adds cross-parameter rules (slug/slugs mutual exclusivity, note and freshness_anchor being single-page only) plus the server-side verifier identity that is not a parameter at all.

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 ('Stamp a knowledge page as verified') with precise scope ('WITHOUT touching its body') and enumerates what it sets. It explicitly contrasts itself with the sibling knowledge_write, so an agent can distinguish it 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?

Names the alternative explicitly ('use it (never knowledge_write) to record "claims still hold"') and states the selecting condition. It also gives when-not conditions: archived pages are rejected, and a batch with any unknown slug is rejected whole, with batch/single-page modes delineated.

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