Skip to main content
Glama

memory_save

Store decisions, facts, and preferences as persistent memories for AI agents, making project context retrievable across sessions.

Instructions

Save a persistent memory (decision, fact, preference, etc.).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoPROJECT
sourceNomcp
contentYes
summaryNo
confidenceNo
importanceNo
project_idNo
memory_typeNoFACT

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds one genuine piece of context beyond that: the memory is 'persistent', implying durability across sessions. It says nothing about what persistence means operationally, whether repeated saves duplicate, or where the record lands, so it is only a modest addition.

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?

A single front-loaded sentence with zero filler or redundancy. It is efficient, though its brevity is part of why the surrounding semantics are missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An 8-parameter mutation tool with 0% schema coverage needs far more than one line. The presence of an output schema relieves it of explaining return values, but the storage semantics, parameter meanings, and save-vs-update routing are all absent.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description must carry the load. The enumeration 'decision, fact, preference' loosely maps to the content/memory_type fields, but scope, source, summary, confidence, importance, and project_id are completely unexplained in either the schema or the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Save a persistent memory') and enumerates the kinds of content it stores (decision, fact, preference). It is distinguishable from memory_search/memory_get/memory_delete by verb, though it never explicitly contrasts itself with memory_update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is given. With a sibling named memory_update, the key ambiguity for an agent — whether to save a new memory or update an existing one, and how duplicates are handled — is left entirely unaddressed.

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