Skip to main content
Glama

memory_write

DestructiveIdempotent

Create or update a durable memory to capture key constraints, conventions, decisions, or runbooks that future sessions must not miss. Replace outdated memories by superseding them.

Instructions

Create or update a durable memory -- the compact knowledge a future session must not miss (a constraint, gotcha, decision, runbook). Long-form write-ups belong in notes_create; put the one-line lesson here. Writing an existing name updates it in place (its id is stable). On a new name, a semantically similar existing memory is reported as an advisory hint; the write still proceeds. The hint is withheld when the target project's content is fenced from you (see the withheld marker on the response) -- the write lands either way. Pass supersedes to replace a DIFFERENT, now-outdated memory: it is marked invalid and leaves every index (briefing, recall) but stays readable with a pointer here. If superseding fails, the new memory is still written and kept; the error says how to retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesmarkdown body (aliases: content, text)
kindYesmemory kind; constraint = what any agent must or must not do regardless of task; convention = a project-local choice or layout fact (naming, branding, where things live or deploy, which files sync together); for kind=stage, open the body with Status: open|in_progress|blocked|done and optionally Gate: human|ai, and flip the status with memory_edit (or a full memory_write) -- append cannot change the header, which is parsed from the top of the body
nameYeskebab-case identifier, unique within the project
tagsNotags, replacing all (a comma-separated string is also accepted); omit to leave an existing memory's tags untouched, and note an empty list reads as absent, not as a clear
projectNoproject slug; defaults to the bound/ambient session's project. An unknown slug CREATES that project -- naming a new one is normal and never an error. Pass project=global ONLY for knowledge that belongs in EVERY project's briefing; it is not a neutral default. With no session and no explicit project the call is rejected as ambiguous. A session bound to a confidential or sealed project can write ONLY into that project.
supersedesNoname of an existing memory this one replaces; that memory is marked superseded (invalid) and pointed here
descriptionYesone line, <=150 chars -- the only text shown in indexes
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses rich behavioral details: updating an existing name in place with stable id, the advisory similarity hint on new names, the withheld hint due to project fencing, supersedes marking the old memory invalid while keeping it readable, and the fallback when superseding fails. These add significant context that annotations alone don't provide.

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?

Although the description is long, every sentence carries essential information. It is front-loaded with the core purpose, then systematically covers update semantics, similarity hints, fencing, supersedes, and error recovery. There is no fluff or repetition; the density is justified by the tool's complexity.

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?

For a tool with 7 parameters, rich annotations, and no output schema, the description covers the key behavioral aspects: update-in-place, advisory hints, fencing, supersedes, and error handling. It also mentions response markers (withheld hint, error retry) that help the agent interpret outcomes. Combined with the schema, this is highly complete for an agent to select and invoke correctly.

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?

The schema already has 100% parameter coverage, so the baseline is 3. The description adds extra meaning for 'name' (update-in-place semantics), 'supersedes' (index behavior, pointer, failure fallback), and 'project' (fencing and unknown slug creation), which goes beyond the schema descriptions and helps the agent use these parameters correctly.

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 'Create or update a durable memory' — a specific verb and resource — and immediately distinguishes itself from siblings: 'Long-form write-ups belong in notes_create; put the one-line lesson here.' It clearly scopes the tool to compact, must-not-miss knowledge and differentiates from memory_append, memory_edit, and notes_create.

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 when-to-use guidance: it tells the agent to use this for one-line lessons and points to notes_create for long-form content. It also explains a specific scenario for supersedes (replacing a different outdated memory) and notes the failure behavior, giving clear decision criteria versus alternatives.

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

Install Server

Other Tools

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/0spoon/seamless'

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