Skip to main content
Glama

add_memory

Save a MEMORY about a SPECIFIC person — something YOU worked out on your own, unprompted, that the user never told you (a pattern you spotted, a fact you inferred from their calendar or email). If the user ASKED you to remember it, it's their note, not your memory — use add_note. @mention a name in content to link someone in your network. Read them back via get_person (relationship.memories). For a general fact not about one person, use memory_save instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "person_id": "<person_id>",
      "content": "<content>"
    },
    "name": "add_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoOptional tags.
contentYesThe memory. @mention a name in your network to link them.
person_idYesThe person this memory is about.
occurred_atNoThe date this memory REFERS to, if different from now (ISO timestamp). Omit to anchor to write time. Use when recording a past event, e.g. 'met at conference last week'.
captured_viaNoThe skill capturing this — pass the active skill's slug (e.g. 'research-person', 'add-person') when a skill is driving the write; omit for an ad-hoc memory.

Output Schema

NameRequiredDescriptionDefault
okYesWhether noticed completed the operation.
dataNoThe operation result when ok is true.
errorNoA human-readable error when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "data": {
      +      "additionalProperties": true,
      +      "description": "The operation result when ok is true.",
      +      "properties": {},
      +      "type": "object"
      +    },
      +    "error": {
      +      "description": "A human-readable error when ok is false.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "Whether noticed completed the operation.",
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description's job is to add context and it does: it defines the epistemic bar for a valid memory and states that @mentioning links a person in the network. It doesn't warn that a non-idempotent write may create duplicate memories on retry, which would be the one remaining behavior worth disclosing.

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?

Four sentences, front-loaded with the defining constraint, then disambiguation, then the linking mechanic, then the read-back path — no filler. The ALL-CAPS emphasis is heavy-handed but each sentence carries a distinct routing or behavioral fact.

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 5-parameter write tool with full schema coverage, an output schema, and supporting annotations, the description supplies the missing piece — the judgment call about what counts as this agent's memory versus a user note. Only the retry/duplication behavior of a non-idempotent write is left unstated.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents person_id, content, tags, occurred_at, and captured_via. The description only adds the @mention linking behavior for content, which is largely duplicated in the schema's own content description, and says nothing about occurred_at or captured_via. Baseline 3 is appropriate when the schema carries the parameter burden.

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 MEMORY') and immediately narrows scope to 'a SPECIFIC person' and to information the agent inferred rather than was told. The negative definition ('something YOU worked out on your own, unprompted, that the user never told you') distinguishes it from add_note and memory_save without requiring schema inspection.

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?

Gives explicit routing rules both ways: if the user asked you to remember it, use add_note; if the fact isn't about one person, use memory_save. It also names the read path (get_person, relationship.memories) so the agent knows this tool is write-only in the workflow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources