Skip to main content
Glama

add_memory

Store a self-contained fact with absolute dates as a new memory in OpenMemory, optionally setting sector, tags, and metadata type for later filtering.

Instructions

Store a new memory. content: one self-contained fact, with absolute dates. sector: optional override of the automatic classification (episodic, semantic, procedural, emotional, reflective). tags/metadata optional; a metadata 'type' such as system_info, preference, decision, troubleshooting helps later filtering.

Input Schema

NameRequiredDescriptionDefault
tagsNo
sectorNo
contentYes
metadataNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a meaningful trait beyond the schema: that sector defaults to an automatic classification the caller can override, and that metadata 'type' improves later filtering. However, it says nothing about deduplication/uniqueness, permissions, or side effects, which matter for a write tool with no annotation coverage.

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-loaded with the core action, then a compact run-through of each parameter. No filler sentences, and the per-parameter notes are dense with useful guidance rather than padding.

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?

An output schema exists, so return values need not be described. With 0% schema description coverage across four params, the description compensates for all of them meaningfully. The main remaining gap is the absence of any durability/duplication or permission behavior for a write operation lacking annotations.

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 description coverage is 0%, so the description must carry parameter meaning, and it does: content is scoped to "one self-contained fact, with absolute dates," sector enumerates the five classification values as an override, and metadata 'type' is given concrete examples (system_info, preference, decision, troubleshooting). Only 'tags' is left with bare "optional" and no semantic guidance.

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?

Clear specific verb+resource: "Store a new memory." The action is unambiguous and easily distinguished from siblings like get_memory, delete_memory, search_memories, and reinforce_memory. It does not explicitly name or contrast with any sibling, so it stops short of the top band.

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

Usage Guidelines3/5

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

Usage is implied by the purpose (use this to persist a new fact), but there is no explicit when-to-use/when-not guidance and no routing to alternatives. Notably it does not address when to add a fresh memory versus reinforcing an existing one (reinforce_memory), leaving a real ambiguity for the agent.

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