Skip to main content
Glama
0Mattias
by 0Mattias

memory_write

Persist conversation details as structured memories with scopes, categories, and optional grounding checks against the codebase to prevent stale claims.

Instructions

Create a new memory. Call PROACTIVELY when something durable enters the conversation — aggressive writing is safe; the guardrails below catch bad writes. Trigger→category mapping: the server instructions block.

Parameters:

  • content: the memory body.

  • scopes: non-empty list. Avoid the catch-all 'general'; prefer narrow tags like tools, infrastructure, projects:<name>, learning-style.

  • category (default 'fact'): one of fact, user-inference, ambient.

    • fact: project / infra / reference / tooling. Commits immediately (unless require_write_confirmation).

    • user-inference: claims ABOUT THE USER. Always returns {status:'pending', pending_id} regardless of config — ask the user in plain language, then memory_write_confirm or memory_write_cancel. Misattribution sticks; user gets the veto.

    • ambient: atmospheric context that shapes replies without being cited. Commits like fact but excluded from dead-weight curation; long bodies (>500 words) attach a non-blocking ambient_body_long warning.

  • confidence ('low' / 'medium' / 'high'), source ('explicit-statement' / 'inferred').

  • claims (optional): claims the body makes about this repo — path, path::symbol, path::NAME=literal. Checked against the worktree NOW (false ⇒ refused); drift then watches the claimed bindings, not whole files. Declare when citing code.

  • groundedness_check=True + source_transcript: optional gate. Sentences with <30% token overlap to the transcript return {status:'ungrounded', claims:[…]}. Override via acknowledge_ungrounded=True when you have grounding sources outside the transcript (file reads, tool results). Off by default; opt in for a paper trail.

Return statuses:

  • committed — write succeeded; payload carries the new id and related medium-overlap matches.

  • duplicate — content dedup fired; the matched memory is credited a corroboration (corroboration_recorded: true, once per session) — recurrence is evidence; the hint carries the remedy.

  • transient_warning / credential_warning / previously_removed / scope_mismatch — gate rejects. Each returns what matched and a hint carrying the remedy and its acknowledge_* / force=True override.

  • user_claim_warning — the body reads as a claim ABOUT THE USER but category isn't user-inference. Re-issue as that (the user gets the veto) or pass acknowledge_user_claim=True if the subject is someone else.

  • pendingcategory='user-inference' or require_write_confirmation. pending_reason distinguishes.

  • ungrounded — groundedness gate fired.

A committed or memory_write_confirm response may inline a one-shot per-session curation_hint block when dead_weight + drifted + cold_endorsement_memories pressure crosses the configured threshold. Shape: {pressure, threshold, counts: {dead_weight, drifted, cold_endorsement_memories}, message}. Passive notification — call memory_health for full buckets, memory_remove / memory_verify to resolve.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNo
claimsNo
scopesYes
sourceNoexplicit-statement
contentYes
categoryNofact
confidenceNomedium
source_transcriptNo
groundedness_checkNo
acknowledge_transientNo
acknowledge_credentialNo
acknowledge_ungroundedNo
acknowledge_user_claimNo
acknowledge_scope_mismatchNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: commit vs. pending vs. duplicate behavior, deduplication/corroboration, gate rejections with overrides, user-claim warning, groundedness threshold (30% token overlap), and a one-shot curation_hint. This is comprehensive behavioral disclosure far beyond the schema.

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 long but well-structured: front-loaded action sentence, parameter bullets, and a clear return-status list. Every major behavior earns its place, though some references are a bit opaque (e.g., 'Trigger→category mapping: the server instructions block' and 'require_write_confirmation') and the text could be tightened without losing value.

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?

Given 14 parameters, no annotations, and a complex tool, the description is remarkably complete. It covers parameter semantics, all possible return statuses, override flags, grounding behavior, and curation notifications. The existence of an output schema means return-value details need not be repeated, and the description goes well beyond what the schema provides.

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?

The input schema has 0% description coverage, but the prose describes almost every parameter with meaningful semantics: scopes should avoid 'general', category determines commit/pending behavior, claims are checked against the worktree, groundedness_check uses transcript overlap, and each acknowledge_* override is explained. This fully compensates for the schema's bare types/defaults.

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 opens with a specific verb and resource ('Create a new memory') and immediately adds proactive guidance ('Call PROACTIVELY when something durable enters the conversation'). It clearly differentiates this write-operation from sibling tools like memory_write_confirm, memory_update, and memory_search by focusing on creation and its return statuses.

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 strong usage context: write aggressively, safe guardrails, trigger-to-category mapping, and scope guidance. It also gives explicit alternative actions for handling curation ('call memory_health', 'memory_remove / memory_verify') and for pending user-inference claims (memory_write_confirm/cancel), though it does not systematically contrast with every sibling write/update/remove tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0Mattias/bettermemory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server