Skip to main content
Glama

muninn_memory_update

DestructiveIdempotent

Update an existing memory's text, tags, decay score, occurredAt, or project. memoryId may be a short-form (8-char) prefix. Two ways to change text: pass text to replace the WHOLE body, OR pass replacements:[{old,new}] for surgical find-and-replace — each old must match EXACTLY ONCE or the whole update is rejected atomically (nothing is written), so a two-line edit to a long memory costs one pair instead of resending thousands of words. Regenerates the embedding ONLY if text actually changes. tags REPLACES the whole list. Returns a compact {id, tags, project, updatedAt, embeddingRegenerated, length} — length is the stored char count, your self-verify signal (the body is never echoed back). When you used replacements, the result also carries replacements: so you can confirm how many spots were hit. For a tags-only edit, prefer muninn_memory_tag. hideRank:true takes a memory out of Ranking and boot's mostAccessed, false puts it back; omit it to leave it as it is. This is also how you EDIT AN ARTIFACT'S BODY — an artifact's artifactId IS its memoryId; there is no separate muninn_artifact_update. If the artifact is currently published, its public link is refreshed automatically. Optional expectedRev: pass the rev your last muninn_memory_get / muninn_artifact_get returned and the write is REJECTED (nothing written) if someone changed the body since you read it, instead of silently overwriting them. Omit it when you read and write in the same breath.

Input Schema

NameRequiredDescriptionDefault
tagsNoNew tags (replaces existing tags)
textNoNew text content — replaces the WHOLE body. Mutually exclusive with replacements.
previewNoUpdated 1–2 sentence summary. Pass when text changed. If omitted, existing preview is preserved.
projectNoNew project slug. Pass empty string '' to clear back to global. Omit to leave unchanged.
hideRankNoKeep this memory out of the Ranking view and out of the "most accessed" block of session boot. Set true for anything whose reads come from tooling, not from interest: session state, a checkpoint, carryover notes, a run or sync log, a scratch note for the next session of one tool. Leave false for anything a person might want surfaced because it keeps coming up: a decision, a profile, a preference, an article, a changelog entry. When unsure, leave false; a hidden memory is still found by search, tag and get. Omit to leave the current setting.
memoryIdYesThe memory ID to update (full UUID or unique 8-char prefix)
decayScoreNoNew decay score between 0 and 1
occurredAtNoCorrected ISO 8601 datetime of when the event actually happened. Used for chronological ordering.
expectedRevNoThe `rev` from the read you based this edit on. Rejects the write if the body has changed since. Omit to skip the check.
replacementsNoSurgical find-and-replace pairs applied in order. Each `old` must match exactly once or the entire update is rejected (atomic). Use instead of `text` to edit a few lines of a long memory cheaply.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: atomic rejection if any `old` fails to match exactly once, embedding regeneration only when text actually changes, tags replacing the whole list, automatic public-link refresh for published artifacts, and expectedRev conflict rejection instead of silent overwrite. These are the failure modes an agent cannot infer from destructiveHint/idempotentHint alone.

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 purpose and the mutually exclusive edit modes, and most sentences carry distinct information. It is long and repeats some schema-level detail (notably hideRank and replacements atomicity), but given 10 parameters with no output schema the density is largely justified.

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?

Since no output schema exists, the description supplies the return contract itself ({id, tags, project, updatedAt, embeddingRegenerated, length}) and explains that length is the self-verify signal because the body is never echoed. Combined with concurrency (expectedRev) and artifact-editing coverage, nothing needed to call it correctly is missing.

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, but the description adds genuine meaning beyond it: the replacements-as-cost-saving device, the embedding-regen condition, the short-form memoryId prefix, and concrete guidance for setting expectedRev. Some content (tags replaces existing, replacements order) is duplicated from the schema, which keeps this from a 5.

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?

Opens with a specific verb+resource and enumerates exactly which fields are mutable (text, tags, decay score, occurredAt, project). It also distinguishes itself from siblings by naming muninn_memory_tag for tags-only edits and stating there is no separate muninn_artifact_update, which is real disambiguation an agent can act on.

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: 'For a tags-only edit, prefer muninn_memory_tag', two named text-edit strategies with the cost tradeoff between them, and clear when/when-not for expectedRev ('omit it when you read and write in the same breath'). It also covers the non-obvious case of editing an artifact body through this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources