Skip to main content
Glama

memory_write

Save a fact, preference, decision, or note to the user's cross-model memory. Any MCP client can read this back later. Include written_by (e.g. 'claude-code', 'gpt-5', 'kimi-k2') for provenance and session_id to group related writes. Long content (>400 chars) is automatically compressed on write to a structured-facts form optimized for LLM reading — the raw text is preserved. Pass no_optimize:true to skip. Writes are deduped by default: (1) SHA-256 of trim(content) short-circuits byte-identical writes with { id, exact_duplicate:true } for free (no embed call); (2) failing that, semantic dedup returns { id, deduped:true, matched_score } when cosine ≥ 0.85. Pass force:true to bypass both, or use memory_supersede to explicitly correct a prior memory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional short labels for filtering (e.g. ['preference','stack']).
forceNoBypass semantic dedup and write anyway. Default false.
contentYesThe fact or note to remember. Plain text, max 8000 characters.
session_idNoOpaque identifier grouping related writes from the same conversation.
written_byNoIdentifier of the model / client writing this (e.g. 'claude-code', 'gpt-5', 'kimi-k2', 'manual').
no_optimizeNoSkip AI compression of long content. Default false.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description must disclose all behavioral aspects. It does so thoroughly: automatic compression for long content (>400 chars), two-stage dedup (byte-identical SHA-256 then semantic embedding), bypass options (force, no_optimize), and the exact response structure (id, exact_duplicate, deduped, matched_score). No contradictions.

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 description is slightly long but well-organized: purpose first, then usage details, then specific behaviors. Every sentence adds value, and it avoids fluff. Could be tightened slightly, but the density of information warrants the length.

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 tool with 6 parameters (1 required) and no output schema, the description covers all aspects: purpose, parameter behavior, dedup logic, compression, and return fields. It also addresses cross-model access (any MCP client can read). No missing context given the tool's complexity.

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 coverage is 100%, but the description adds substantial meaning beyond field labels. It explains why written_by and session_id matter, how no_optimize bypasses compression, how force overrides dedup, and the dedup threshold (cosine ≥ 0.85). This transforms opaque parameters into actionable guidance.

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?

The description starts with 'Save a fact, preference, decision, or note to the user's cross-model memory,' clearly defining the action (save) and target (memory). It distinguishes from siblings like memory_list or memory_search by focusing on writing rather than reading or querying. The verb 'save' is specific and appropriate.

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?

The description provides excellent usage guidance: recommending written_by for provenance, session_id for grouping, explaining when to use force or no_optimize, and noting memory_supersede for corrections. However, it does not explicitly contrast with sibling tools like memory_list (when to read vs write), so it slightly misses perfect clarity on when to choose this tool over others.

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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: write (single/bulk), search, list, forget, supersede. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'memory_' prefix and verb pattern, using snake_case throughout. Naming is predictable and clear.

Tool Count5/5

6 tools is well-scoped for a memory management server, covering essential operations without being excessive or insufficient.

Completeness4/5

Covers write (single/bulk), search, list, soft-delete, and supersede. Minor gap: no direct single-item retrieval by ID, but search can serve that purpose.