Skip to main content
Glama

memory_save

Save a store note after user consent—record decisions, conventions, or pitfalls; add a new note or update an existing one by ID.

Instructions

Write a note of your own - ONLY after the user agreed to it: say the note first, with its name, category and kind, and write it when they say yes; what they did not agree to may go into your own folder, which can vanish. With id - the number memory_list shows - that note is changed, without it a new one is written; what you leave out keeps its old value. Worth offering is what you learned about THIS store and could not read out of the code: a decision and why it was taken, a convention the owner insists on while it takes shape, a trap that cost you an hour. Not what the code already says - that is what the map and the files are for. Notes are reviewed with the user and cleared: a settled rule of the project belongs in the charter of the store. kind_key says how the note binds: kCritical is read before any work, kDirect is an order of the user, kSkill is how to work with them, kDefault the rest. Where two disagree the order is the kCritical, kDirect and kSkill of everyone, then of a group, then your own, then every other note. The notes of groups and of everyone are the administrator's and are not written here. While the program holds the memory in its window, a write is refused and the note is not kept: offer the user to put it into the scheduler, if its AI-tool is granted to you. This table - not the host's own memory - is where anything about this store or its people's rules belongs: host memory stays on this machine, and the owner never sees it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe note of yours to change, as memory_list numbers it; left out, a new note is written.
bodyNoThe text in plain HTML - p, ul and li, b, code; never markdown, no styles or scripts.
infoNoOne line - it is what the list shows.
nameNoA short title in the language of the user; once given, keep it - other notes may name it. Required for a new note.
categoryNoFree words the notes are grouped by; left out, a new note has none and an old one keeps its own.
kind_keyNoThe kind from the registry of the store: kCritical, kDirect, kSkill, kDefault, or one the owner added. Left out, a new note is kDefault and an old one keeps its kind.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv6.5.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels: it discloses user-consent requirement, refusal when memory is in window, the ordering of notes, the fact that group/everyone notes are admin-owned, and that host memory is invisible to the owner. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a long, dense paragraph. While all content is relevant, it is not appropriately sized; it could be trimmed and structured with bullets or sections. The core action is front-loaded, but the volume overwhelms the reader.

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 write tool with no output schema, the description is exhaustive: it covers consent, content guidelines, update rules, kind semantics, ordering, refusal behavior, and storage location. An agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds deep meaning: id semantics (update vs new), kind_key semantics with detailed binding order, body format constraints (plain HTML, no markdown), and default behaviors. It goes far 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 states a specific verb and resource ('Write a note of your own') and clarifies the update behavior via id, distinguishing it from memory_list, memory_load, and memory_remove. It is clear that this tool creates or modifies personal notes.

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?

Provides explicit when-to-use guidance: only after user agreement, and what content is appropriate (learned about THIS store, not code facts). It also names an alternative (scheduler) and explains where notes belong vs host memory. This fully routes an agent.

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