Skip to main content
Glama

remember

Store a new rule, orientation, report, lookup, or chunk in persistent agent memory; the write gate validates bindings/falsifiers, refuses invalid entries, and returns the stored id or exact fix.

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. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full transparency burden. It does well: refusal conditions are spelled out, 'nothing is written on a refusal' is stated, replica queuing is disclosed, and the reply shape is described. It could go further on permissions or side effects, but the core behavior is unusually well covered.

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?

One dense paragraph, but each sentence earns its place: purpose, pre-call lookup, life-item exclusion, replica behavior, refusal guarantees, check semantics, and response shape. The core purpose is front-loaded, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a complex 17-parameter tool with no output schema, the description supplies the missing operational context: when to call it, when not to, what happens on a replica, refusal behavior, and what the reply will contain. It deliberately delegates itemized check-kind details to server instructions, which is reasonable alongside a heavily documented schema.

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 parameters thoroughly. The description adds only a high-level note about check_kind/check_path/check_literal(s) being an optional machine-runnable proof and points to server instructions, which is helpful but not essential beyond the schema.

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 opens with a precise verb and resource: 'declares a NEW item (Rule, Orientation, Report, Lookup or Chunk) through the write gate.' It immediately distinguishes itself from siblings by saying lookup is for correcting existing items and shelve is for the owner's life, so an agent can tell what this tool is for.

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 routing guidance is given: 'Call lookup first' to avoid near-duplicates, and 'for anything about the owner's own life use shelve, never this.' It also tells the agent what to expect on a replica ('queued for the main machine' is not an error), which is a useful when-to-use signal.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nworks3d/THOR-memory-bible-for-AI'

If you have feedback or need assistance with the MCP directory API, please join our Discord server