Skip to main content
Glama

save_memory

Store durable context, decisions, or research for future AI conversations, with duplicate warnings and auto-tags to keep shared memory organized.

Instructions

Save a piece of context/memory for future conversations. Warns about likely duplicates (consider append_memory instead) and adds configured auto-tags.

Args: topic: Short title (e.g. "billing-api Postgres migration decision", "AAPL stock analysis") content: Detailed context to remember — include conclusions, data, links, action items category: One of: conversation, decision, incident, research, person, project, howto, config, other tags: Comma-separated tags (e.g. "postgres,database,billing") importance: One of: low, normal, high, critical source: Where this came from (default: the connected client's name, e.g. "claude-code") thread_id: Link related memories together with the same thread ID (e.g. "incident-2026-03-24") entities: JSON array of objects, e.g. [{"type":"service","value":"billing-api"},{"type":"person","value":"alice"}] expires_at: Optional expiry date (YYYY-MM-DD) after which this memory is less relevant

Input Schema

NameRequiredDescriptionDefault
tagsNo
topicYes
sourceNo
contentYes
categoryNoother
entitiesNo
thread_idNo
expires_atNo
importanceNonormal

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden itself: it discloses that duplicates only produce a warning (not a rejection), that configured auto-tags are added, and that source defaults to the connected client name. It still leaves out things like retention/permission behavior and what happens if duplicates are confirmed, so it is strong but not exhaustive.

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?

The one-line summary and the append_memory pointer are front-loaded before the Args block. The Args list is long but every entry adds information the bare schema lacks; only the illustrative examples could be trimmed.

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 9-param write tool with no annotations, the description covers all parameters plus the two non-obvious behaviors (duplicate warning, auto-tagging). An output schema exists so return values need not be explained; the remaining gap is around overwrite/update semantics versus update_memory.

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 description coverage is 0%, so the description must compensate — and it does, documenting all nine params with the allowed category and importance values, a comma-separated tags format, a default for source, the thread-linking convention, and a concrete entities JSON example.

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 and resource ('Save a piece of context/memory for future conversations') and names the sibling it overlaps with ('consider append_memory instead'), so an agent can tell it apart from append_memory/update_memory without opening schemas.

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

Usage Guidelines4/5

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

Gives one explicit routing rule — if the content likely duplicates an existing memory, use append_memory — which is exactly the decision an agent faces here. It does not say when to prefer update_memory or whether to search first, so it falls short of full when/when-not coverage.

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