Skip to main content
Glama

memory_write

Store a long-term memory that persists across sessions and across every AI tool the user has connected to Mnemoverse (Claude, ChatGPT, Cursor, VS Code). Suited to durable information: a stated preference, a decision, a fact about people, roles or project setup, a lesson learned; transient chatter that only matters this turn does not belong here. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records. Behavior: outside shared rooms, a novelty gate refuses a write the embedder cannot tell apart from a memory already stored in the same domain, so the result tells you whether the memory was stored or refused. Write content as a self-contained statement that still makes sense when recalled out of context.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoNamespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme'). Matched byte-for-byte — a leading space, a different case, or an invisible character opens a SEPARATE, permanent store, so reuse an exact name from memory_stats rather than retyping one. To write into a shared room, pass its address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms.
contentYesThe memory to store as a self-contained statement, e.g. 'User prefers TypeScript strict mode' or 'Decided to deploy the API on Cloudflare Workers (2026-06)'.
conceptsNoKey concepts for linking related memories (e.g. ['deploy', 'friday', 'staging'])

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoThe memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. "Below importance threshold (0.047 < 0.1)". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display, and the value is capped at 400 characters. Absent when the service sent no explanation, or when nothing remains after that normalization.
storedYesWhether the memory passed the novelty gate and was stored.
memory_idYesIdentifier of the stored memory, or null when it was not stored.
importanceNoNovelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. Outside shared rooms, a write that scores below the service's importance threshold is not stored, and `reason` says why when the service sends one. The score is approximate and can read lower for non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. Changed1 schema field changed
    • changedOutput schema / properties / importance / description
      Previous value: -"Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. A first-generation metric UNDER ACTIVE DEVELOPMENT and known to be unreliable — the same content has measured ~0.08 in Russian against ~0.55 in English, so it under-reads non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score."New value: +"Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. Outside shared rooms, a write that scores below the service's importance threshold is not stored, and `reason` says why when the service sends one. The score is approximate and can read lower for non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score."
  3. Changed7 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / concepts
      Added value: +{
      +  "description": "Key concepts for linking related memories (e.g. ['deploy', 'friday', 'staging'])",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 256,
      +  "type": "array"
      +}
    • changedInput schema / properties / content / description
      Previous value: -"The text to remember (1-10,000 chars). Do not store passwords, API keys, payment data, MFA codes, government IDs, or health records."New value: +"The memory to store as a self-contained statement, e.g. 'User prefers TypeScript strict mode' or 'Decided to deploy the API on Cloudflare Workers (2026-06)'."
    • changedInput schema / properties / domain / description
      Previous value: -"Namespace: 'general', 'user:X', 'project:Z' (default 'general')."New value: +"Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme'). Matched byte-for-byte — a leading space, a different case, or an invisible character opens a SEPARATE, permanent store, so reuse an exact name from memory_stats rather than retyping one. To write into a shared room, pass its address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms."
    • removedOutput schema / properties / memory_id / anyOf
      Removed value: -[
      -  {
      -    "format": "uuid",
      -    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / memory_id / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / reason / description
      Previous value: -"The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. \"Below importance threshold (0.047 < 0.1)\". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display. Absent when the service sent no explanation."New value: +"The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. \"Below importance threshold (0.047 < 0.1)\". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display, and the value is capped at 400 characters. Absent when the service sent no explanation, or when nothing remains after that normalization."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the novelty gate that can refuse near-duplicate writes outside shared rooms, noting that the result reports stored vs refused, specifying that domain matching is byte-exact so a stray space opens a separate permanent store, and listing forbidden content classes. This is exactly the kind of behavior an agent cannot infer from destructiveHint=false or idempotentHint=false.

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-loads purpose and durability scope, then usage criteria, then constraints, then behavior. Dense but each sentence earns its place, with only mild overlap between the closing sentence and the schema's own description of the content field.

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 three-parameter write tool with an output schema and annotations, the description covers the remaining gaps an agent needs: durability semantics, privacy boundaries, refusal behavior, and content authoring rules. Return structure is correctly left to the output schema while its outcome meaning is still summarized.

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 coverage is 100%, so the baseline is 3, and the description adds real meaning on top: content must be a self-contained statement that still makes sense when recalled out of context, which the schema only demonstrates by example. Domain semantics are mostly delegated to the schema, so it lands at 4 rather than 5.

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 (store) and resource (long-term memory) plus scope: persists across sessions and across every connected AI tool. This clearly separates it from siblings like memory_read, memory_list_recent, and memory_create_room, which read or set up rather than persist content.

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 explicit inclusion criteria (stated preference, decision, fact, lesson learned) and exclusion criteria (transient chatter that only matters this turn does not belong here), plus a hard prohibition list. It stops short of naming sibling tools an agent should use instead for retrieval or routing, so it is strong but not a full 5.

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.