Skip to main content
Glama

remember

Declare new memory items—rules, orientations, reports, lookups, or chunks—through a write gate that refuses invalid entries with exact fixes; call lookup first to avoid near-duplicates.

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 (or, if costly or irreversible, only a project name, which reaches no tool call), no falsifier, or exceeds 300 characters, when a Report/Chunk names no project scope, or when the text or falsifier carries a real secret token (never echoed back; store where it lives, never the value; no override); 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. Every Rule/Orientation is TRIED as it is written: a check that bites is stored on the rule track, a rule with no working tooth is stored as a note (no check), and a tooth THOR builds from the rule's own words that bites refuses the write, naming the exact check to hang - the reply's 'teeth:' note says which. Replies with the stored id, kind and event sequence, or the refusal text.

Input 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.
becauseNoREQUIRED with legitimate_calls, may_change or accept_refusing, and never needed otherwise: one sentence of at least 20 characters saying WHY the named span may change, or why the call is legitimate, while the rule stays true. It is kept in this item's history and shown to the owner at the next evaluation. First try to hang a check on the literal that IS the rule's subject; dispute only an incidental span.
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.
may_changeNoONLY after a refusal said THOR derived a contains check from this rule's text and a file: the span you name as one that MAY CHANGE in that file - e.g. ["version"] for a rule that names the version line of package.json. It must be exactly the derived check's literal. Then the rule is stored as a note by dispute, which doctor lists for the owner. Needs `because`. Leave it out otherwise.
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 except requires, which takes the trigger first - one of this item's own command bindings, or a specific literal inside the bound command such as "-p my-dev" in an ssh call - then every answer that satisfies it.
accept_refusingNoONLY after a refusal said your check would refuse most of the real calls it reaches: one of the calls it listed, named because refusing it IS the intent - e.g. ["git push origin main"] for a "never push this repository until the owner says so" ban. The rule stays on the rule track, and doctor lists every rule kept this way. Needs `because`. Otherwise narrow the check instead.
legitimate_callsNoONLY after a refusal said THOR built a tooth from this rule's own text and it bites: a real, whole call you name as LEGITIMATE although that tooth refuses it - e.g. ["git push --force-with-lease origin main"] for a rule whose text names `--force`. It must reach the tooth's command, be refused by it, differ from the forbidden form THOR built itself, and carry something beyond the command and the literal. Then the rule is stored as a note by dispute, which doctor lists for the owner. Needs `because`. Leave it out otherwise.
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. Changed5 schema fields changedv2.6.0
    • addedInput schema / properties / accept_refusing
      Added value: +{
      +  "default": [],
      +  "description": "ONLY after a refusal said your check would refuse most of the real calls it reaches: one of\nthe calls it listed, named because refusing it IS the intent - e.g. [\"git push origin main\"]\nfor a \"never push this repository until the owner says so\" ban. The rule stays on the rule\ntrack, and doctor lists every rule kept this way. Needs `because`. Otherwise narrow the check instead.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / because
      Added value: +{
      +  "default": null,
      +  "description": "REQUIRED with legitimate_calls, may_change or accept_refusing, and never needed otherwise:\none sentence of at least 20 characters saying WHY the named span may change, or why the\ncall is legitimate, while the rule stays true. It is kept in this item's history and shown\nto the owner at the next evaluation. First try to hang a check on the literal that IS the\nrule's subject; dispute only an incidental span.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedInput schema / properties / check_literals / description
      Previous value: -"A SET of literals to forbid together, for check_kind absent_all (in one file) or forbidden\n(everywhere, no file). One rule forbidding several things at once (e.g. every banned\npunctuation character) is ONE item with a set here, never several near-identical items each\nforbidding one literal. Each literal is its own array entry, never joined into one delimited\nstring. Refused together with check_literal, refused empty, and refused with any other\ncheck_kind."New value: +"A SET of literals to forbid together, for check_kind absent_all (in one file) or forbidden\n(everywhere, no file). One rule forbidding several things at once (e.g. every banned\npunctuation character) is ONE item with a set here, never several near-identical items each\nforbidding one literal. Each literal is its own array entry, never joined into one delimited\nstring. Refused together with check_literal, refused empty, and refused with any other\ncheck_kind except requires, which takes the trigger first - one of this item's own command\nbindings, or a specific literal inside the bound command such as \"-p my-dev\" in an ssh call -\nthen every answer that satisfies it."
    • addedInput schema / properties / legitimate_calls
      Added value: +{
      +  "default": [],
      +  "description": "ONLY after a refusal said THOR built a tooth from this rule's own text and it bites: a real,\nwhole call you name as LEGITIMATE although that tooth refuses it - e.g. [\"git push\n--force-with-lease origin main\"] for a rule whose text names `--force`. It must reach the\ntooth's command, be refused by it, differ from the forbidden form THOR built itself, and\ncarry something beyond the command and the literal. Then the rule is stored as a note by\ndispute, which doctor lists for the owner. Needs `because`. Leave it out otherwise.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / may_change
      Added value: +{
      +  "default": [],
      +  "description": "ONLY after a refusal said THOR derived a contains check from this rule's text and a file: the\nspan you name as one that MAY CHANGE in that file - e.g. [\"version\"] for a rule that names\nthe version line of package.json. It must be exactly the derived check's literal. Then the\nrule is stored as a note by dispute, which doctor lists for the owner. Needs `because`. Leave it out otherwise.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses the refusal conditions with the exact fix, that nothing is written on refusal, that secrets are never echoed, that checks are TRIED at write time with rule-vs-note outcomes, and the reply shape. The annotations only cover the safety profile; the description carries the real behavioral burden.

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?

Purpose is front-loaded ('Code lane: declares a NEW item...') and the return/refusal behavior is placed last. The middle preconditions are dense and clause-heavy, but for a 21-parameter gated write tool most sentences carry non-redundant information rather than filler.

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 21 parameters, no output schema, and only partial annotation coverage, the description fills the gaps: it explains refusal semantics, the replica queue path, check-kind behavior, and the reply ('stored id, kind and event sequence, or the refusal text'). Nothing critical is left undocumented.

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 95%, so the baseline is 3 and the schema already documents most fields. The description adds cross-parameter integration semantics (check_kind/check_path/check_literal(s) attach a proof alongside falsifier, refusal logic pairing falsifier and binding), which goes beyond isolated field text.

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 ('declares a NEW item (Rule, Orientation, Report, Lookup or Chunk) through the write gate') and the 'NEW' qualifier is a real distinguisher. It explicitly routes to siblings: call lookup first to correct, and use shelve for the owner's own life, never this.

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?

Gives explicit when-to-use (call lookup first to avoid near-duplicates), when-not (owner's-life facts go to shelve), and the consequences of the replica path ('queues instead of writing ... is not an error'). Alternatives and exclusions are named, not inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.