Skip to main content
Glama
nworks3d

thor-memory-bible

by nworks3d
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

remember

Persist a new rule, orientation, report, lookup, or chunk through the write gate, with validation that rejects duplicates, unfalsifiable claims, and missing project scope.

Instructions

Code lane: declares a NEW item (Rule, Orientation, Report, Lookup or Chunk) through the write gate. Call lookup first so this corrects an existing item instead of storing a near-duplicate; for anything about the owner's own life use shelve, never this. On a replica this queues instead of writing ('queued for the main machine' is not an error). Refuses, with the exact reason and the fix, when a Rule/Orientation has no binding, no falsifier, or exceeds 300 characters, or when a Report/Chunk names no project scope; nothing is written on a refusal. check_kind/check_path/check_literal(s) optionally attach a machine-runnable proof alongside the falsifier - see server instructions for the six check kinds. Replies with the stored id, kind and event sequence, or the refusal text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesCaller-chosen id, kept forever. Pick something short, stable and grep-able (e.g. "no-force-push-main"), not a sentence.
keyNoRequired for a Lookup: the exact key a future `lookup` call names to get this item back. Meaningless for the other four kinds.
kindYesOne of: rule, orientation, report, lookup, chunk.
tagsNo
textYesThe fact itself. A Rule/Orientation is refused past 300 characters - move reasoning into a Report instead of lengthening this.
alwaysNoBind this item to the pinned Always layer (served in full at every session start). Only a Rule/Orientation may set this.
expiresNoISO-8601 date. Only a Report may carry this - a Rule, Orientation, Lookup or Chunk with an expiry is refused (they last until revised).
momentsNoAction names this item fires on (repeatable), e.g. ["push"]. Only a Rule/Orientation may bind to a moment. The ones that actually fire are derived from a real command or file path (publish, commit, push, deploy and the rest - see intent::from_command/from_path), plus remember itself. answer and claim_done are refused on a NEW binding: nothing produces either yet, so a rule bound only to one would store cleanly and never fire.
projectNoProject this item belongs to. Omit for a global, cross-project item.
targetsNoExact targets this item fires on (repeatable). Only a Rule/Orientation may bind to a target; the value must be the real path/command/etc, never a glob and never a bare role name.
severityNoOne of: irreversible, costly, house_style. Meaningless (and refused as a binding target would be) on a Report/Lookup/Chunk.
falsifierNoWhat observation would prove this fact wrong, one sentence. Required for a Rule or Orientation - they never expire, so this is the only thing that ever names when one has gone stale.
check_kindNoOne of: path_exists, contains, absent, absent_all, forbidden, requires. An optional machine-runnable check, alongside (never instead of) falsifier - only a Rule/Orientation may carry one, and only while it currently HOLDS can it block a write. Every kind except forbidden needs check_path; path_exists refuses check_literal/check_literals; contains/absent/requires need one of them; absent_all/forbidden need check_literals. requires catches something FORGOTTEN rather than written - see server instructions. Omit all four check_* fields for no check at all.
check_pathNoThe exact file this check inspects, relative to the checker's root - or, for contains/absent/absent_all only, a DIRECTORY: every regular file directly inside it, never one in a subdirectory. Use the directory form when one fact spans more than one file there (e.g. a setting duplicated across two config files). Required with every check_kind except forbidden, which carries no path at all and is refused if one is given.
check_literalNoThe exact literal a "contains" or "absent" check_kind looks for. Refused together with "path_exists", or together with check_literals; required with "contains"/"absent".
check_literalsNoA SET of literals to forbid together, for check_kind absent_all (in one file) or forbidden (everywhere, no file). One rule forbidding several things at once (e.g. every banned punctuation character) is ONE item with a set here, never several near-identical items each forbidding one literal. Each literal is its own array entry, never joined into one delimited string. Refused together with check_literal, refused empty, and refused with any other check_kind.
new_collection_named_by_ownerNoTHE OWNER JUST NAMED A NEW COLLECTION - repeat that name here exactly as he gave it, and it will be opened. The only way an unopened collection can be written to: nothing existing fit, you showed him the refusal (it lists both lanes), you asked, and he answered with a name. Never fill this in on your own judgement or to get past a refusal. Must match the project (or key) on this same call, or the write is refused anyway.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations: it discloses replica queueing, refusal conditions with exact reason and fix, that nothing is written on refusal, optional check attachment, and the reply format. The annotations state readOnlyHint=false, consistent with a write operation, and there is no contradiction.

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

Conciseness5/5

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

Four dense sentences, each earning its place: purpose, usage routing, replica/refusal behavior, and optional checks plus reply format. The action is front-loaded and there is no filler or repetition of schema content.

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 complex 17-parameter write tool with no output schema, the description covers the essential behavioral context: what counts as new, when to use alternatives, what happens on a replica, refusal conditions, optional check fields, and what the response contains. The schema handles the parameter details, so nothing critical is missing.

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 94%, so the schema already documents the 17 parameters thoroughly. The description adds a useful but general note about check_kind/check_path/check_literal(s) and the six check kinds, yet it does not substantially deepen parameter meaning beyond the schema. Baseline 3 is appropriate because the schema carries the burden.

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 states a specific verb and resource: "declares a NEW item (Rule, Orientation, Report, Lookup or Chunk) through the write gate." It also distinguishes itself from siblings by saying to call lookup first for existing items and to use shelve for the owner's own life. The title "Remember a fact" reinforces, but the description carries the real clarity.

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?

Explicit guidance is given: "Call lookup first so this corrects an existing item instead of storing a near-duplicate" and "for anything about the owner's own life use shelve, never this." It also pre-empts a common misunderstanding by noting that a queued response on a replica is not an error. This is unusually clear routing relative to siblings.

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