Skip to main content
Glama

revise

Update an existing memory item by ID: omitted fields keep current values, empty strings clear them. Fix changes without recreating the entry.

Instructions

Code lane: corrects an EXISTING item by id, through the same write gate as remember, plus one more rule: a field left unmentioned keeps its current value, and none may silently vanish - clear one on purpose with an empty string (severity, project, expires, key, falsifier) or check_kind "" (clears the check). On a replica this queues instead of writing ('queued for the main machine' is not an error). Prefer this over remember for anything that already exists and merely changed. Refuses, with the exact reason, on the same grounds as remember, plus a field dropped without being named. Replies with the revised id and event sequence, or the refusal text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe id of the existing item to correct.
keyNoOmit to keep the current key; pass "" to clear it.
tagsNoReplaces the whole tag list. Omit to keep the current tags; pass an empty list to clear them on purpose - the same omit-keeps/empty-clears convention as severity/project/expires/key/falsifier, spelled with a list: omitted means unmentioned, an empty array means deliberately cleared, a real list replaces the whole set.
textNoNew text, replacing the whole body. Omit to keep the current text unchanged. For a SMALL correction to a long item, prefer `append` or `replace_from`/`replace_to` below - retyping a 290-character rule to fix one word is friction on exactly the maintenance this memory needs most, and it is the reason corrections get skipped.
alwaysNoReplaces whether this item is bound Always - see `moments`' own note.
appendNoAdd this to the END of the current text, with one space between. Refused together with `text` (say what the body is, or say what to add to it, never both). The result still goes through the whole gate, so a 300-character limit is enforced on what comes out, not on what you typed.
expiresNoOmit to keep the current expiry; pass "" to clear it.
momentsNoReplaces the moment bindings. Give this, `targets`, and/or `always` TOGETHER to replace the WHOLE binding list in one call - when none of the three are given, the existing bindings are kept untouched. See RememberArgs' own note on which moments actually fire - a NEW answer/ claim_done binding is refused here too, though one the item already carried stays correctable.
projectNoOmit to keep the current project; pass "" to make it global.
targetsNoReplaces the target bindings - see `moments`' own note on how the three binding fields combine.
severityNoOne of: irreversible, costly, house_style. Omit to keep the current value; pass "" to clear it.
falsifierNoOmit to keep the current falsifier; pass "" to clear it (a Rule or Orientation left with none is refused, same as at creation).
check_kindNoOne of: path_exists, contains, absent, absent_all, forbidden, requires. Omit all four check_* fields to keep the current check untouched; pass check_kind as "" to clear it (refused if check_path/check_literal/check_literals is also given). Give check_kind plus whichever of check_path/check_literal/check_literals the kind takes, together, to replace the check wholesale - see RememberArgs' own check_kind note for what each kind needs and which to prefer.
check_pathNoSee check_kind's own note on the omit/clear/replace convention, and RememberArgs' own note on check_path for the directory shape contains/absent/absent_all also accept (every regular file DIRECTLY inside it, never a subdirectory). Refused outright if check_kind is "forbidden" - that kind carries no path at all.
replace_toNoWhat `replace_from` becomes. Pass an empty string to delete the substring.
replace_fromNoReplace the FIRST occurrence of this substring in the current text with `replace_to`. Refused unless `replace_to` is given too, refused together with `text`, and refused when the substring is not actually in the current text - a silent no-op would report success while changing nothing.
check_literalNoSee check_kind's own note on the omit/clear/replace convention.
check_literalsNoThe set form of check_literal, for check_kind absent_all or forbidden - see RememberArgs' own note on why this is a repeatable field rather than a delimited string. Same omit/clear/replace convention as check_kind: an empty list here reads the same as omitting it, since a list has no separate way to say 'given, but deliberately empty'.
new_collection_named_by_ownerNoTHE OWNER JUST NAMED A NEW COLLECTION - repeat that name here, exactly as he gave it. Same field, same rule and same one flow as on remember: only after nothing fitted, you showed him the refusal and he answered with a name. It must match the project (or key) this call files the item under.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it delivers: it discloses the write-gate mutation path, the omit-keeps/empty-clears merge semantics, the replica queueing behavior, the refusal grounds (including the unnamed-field-drop rule), and the reply format (revised id and event sequence, or refusal text). This is exceptional disclosure for an unannotated write tool.

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?

The description is dense but tightly structured: purpose first, then the core merge rule, then the replica caveat, then usage preference, then refusals and reply. Roughly 120 words cover a 19-parameter tool's essential contract with zero filler; every sentence earns its place.

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?

Despite high complexity (19 params) and no annotations or output schema, the description covers the full operational contract: what it does, the merge/clear model, replica behavior, refusal conditions, and the response shape. The schema covers all parameter details at 100%, so nothing an agent needs to invoke it correctly is left unaddressed.

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 baseline is 3. The description earns one extra point by synthesizing the cross-cutting convention — 'a field left unmentioned keeps its current value, and none may silently vanish' — which unifies the per-parameter omit/clear semantics that the schema spells out individually. It adds a conceptual frame the schema alone does not provide.

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 opening states a specific verb and resource: 'corrects an EXISTING item by id,' which immediately distinguishes revise from create-oriented siblings like remember. It also explicitly contrasts itself ('Prefer this over remember for anything that already exists and merely changed'), so an agent can select it without inspecting the 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?

The description gives explicit routing advice: 'Prefer this over remember for anything that already exists and merely changed.' It also tells the agent when behavior differs ('On a replica this queues instead of writing') and how to interpret the non-error response. This is clear when-to-use guidance with a named alternative.

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