Skip to main content
Glama

Write memory

write_memory
DestructiveIdempotent

Create or update a keyed memory entry to store durable facts, decisions, and next steps, with prior contents saved automatically for later history review.

Instructions

Create or update a memory by key; previous contents are saved automatically and readable with get_memory_history. Keep entries concise and actionable: save durable facts, decisions, and useful next steps rather than raw transcripts or repeated detail, and provide a short summary. When current evidence corrects an existing fact, update its existing key instead of adding a contradictory duplicate; archive obsolete entries with archive_memories. memory_at is optional and defaults to this save's time; supply an ISO timestamp to preserve an earlier time. is_archived=true hides the entry from normal search/context; false restores it. Tier controls context priority independently of archiving. Requires memory:write or full permission; with memory:propose the write is saved as a proposal (status pending_review) that changes nothing until the owner or an editor approves it. Pass playbook_id as the UUID or GUID of the playbook this call should target.

Input Schema

NameRequiredDescriptionDefault
keyYesMemory key
tagsNoTags for categorization
tierNoMemory tier (default: contextual)
valueYesJSON value to store
statusNoTask status (for hierarchical task tracking)
summaryNoCompact summary for context views
metadataNoFree-form metadata: dependencies, thread assignment, progress. Two keys have a defined shape and are validated: metadata.episode as {location, task, outcome} makes the entry findable by where through get_memory_context, while when it happened is memory_at; and metadata.recording holds demonstration references in the same shape a skill uses, as a list of {provider, ref, fidelity, role, segments}. Everything else is stored untouched.
priorityNoPriority 1-100 (default: 50)
memory_atNoMemory time including timezone; defaults to save time
parent_keyNoParent memory key for hierarchical organization
descriptionNoHuman-readable description
is_archivedNoHide from normal search; false restores an archived entry
memory_typeNoflat (default) or hierarchical for task graphs
playbook_idYesUUID or GUID of the target playbook

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?

Annotations declare destructiveHint=true and idempotentHint=true, and the description reconciles the destructive flag by explaining previous contents are saved and retrievable via get_memory_history. It goes beyond structured fields with permission requirements (memory:write / full vs memory:propose producing a pending_review proposal) and archive/tier behavior.

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-loads the core action and follows with the highest-value policies (concise saving, dedup-by-key, archiving). It is dense and covers many concerns in one block, but nearly every sentence carries actionable instruction; minor looseness around the playbook_id sentence.

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?

For a 14-parameter, nested-metadata mutation with no output schema, the description covers the risky and non-obvious angles (permissions, proposals, history retention, archiving, tiers). It omits any mention of return shape and barely touches several optional parameters, but schema coverage is complete so the gap is small.

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: memory_at defaults to save time and accepts ISO, is_archived toggles visibility, tier controls context priority independently of archiving, and playbook_id is UUID or GUID. It does not add guidance for tags, priority, parent_key, status, or memory_type, so it stops short of full value-add.

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 pair and resource ('Create or update a memory by key') and immediately clarifies the create-vs-update semantics that distinguish it from read_memory, delete_memory, or archive_memories. An agent can identify the operation and its target without opening 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?

Gives explicit when-to-do-what: update an existing key rather than duplicating a contradictory fact, archive obsolete entries with archive_memories, save durable facts not raw transcripts. It names the corrective alternative (archive_memories) and the review path (memory:propose).

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