Skip to main content
Glama
chinwe

compound-memory

by chinwe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memory_write

Stores durable facts, insights, decisions, and skills in a shared agent memory store, using keys, namespaces, validity dates, and project scopes to preserve reusable context and flag conflicts.

Instructions

Write a memory. type: episode|fact|insight|skill|decision; source: writing agent id; ns: '_shared' or 'agent-'. key: stable id for fact/insight/skill/decision (enables conflict review). Write only stable facts (preferences, conventions, environment constraints, pitfalls), not session-temporary details; volatile status notes (in-progress work, remaining todos) either carry valid_until or stay out — a stale status memory is worse than none; prefer reusing an existing key over a new entry. valid_from/valid_until: optional ISO dates (YYYY-MM-DD) marking the fact's validity window — once valid_until has passed, the memory is excluded from search results but still readable via memory_get. project: optional lowercase-slug scope tag (lowercase alphanumeric segments joined by dashes) for workspace-specific memories — tagged memories are hidden from searches that do not pass the same project, while untagged (global) memories stay visible everywhere; declare your workspace project per the host usage rules and pass it on every write/search in that workspace. lesson_role: optional 'lesson' or 'avoid' (omit for an ordinary memory) — write a lesson as insight (or a steady decision) and an avoid as decision plus this field; do not invent a memory type or encode the role in the key. links may start with avoid:, fixes:, or contradicts: plus a target id or key; other link strings stay free-form. content is capped at 262144 characters — longer payloads are rejected and nothing is written. Returns the stored memory; conflict: true means a different version with the same key exists and a review entry was queued.

Input Schema

NameRequiredDescriptionDefault
nsNo_shared
keyNo
typeYes
linksNo
sourceYes
contentYes
projectNo
valid_fromNo
lesson_roleNo
valid_untilNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.8
    • addedInput schema / properties / lesson_role
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Lesson Role"
+}
  2. First observedv0.4.3

TDQS

A4.9/5.0
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: it discloses the 262144-character cap with rejection semantics ('nothing is written'), the returned conflict:true signal plus queued review entry, and the post-expiry behavior where valid_until-past memories drop out of search but remain readable via memory_get. It also states the visibility consequence of project tagging and the fact that lesson_role must not be encoded in the key.

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 organized parameter-by-parameter with semicolon separators; nearly every clause adds a real constraint. It is a dense run-on block with no line breaks or bullets, which slightly hurts scanability for a 10-parameter tool.

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 10 parameters, zero schema documentation, no annotations, and no output schema, the description covers the full call surface: input semantics, size limits, failure behavior, and the meaning of the returned conflict flag. Nothing an agent needs to invoke it correctly appears to be missing.

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 description coverage is 0%, so the description must compensate and does — it defines semantics for type, source, ns, key, valid_from/valid_until (with YYYY-MM-DD format and expiry behavior), project (lowercase-slug format plus visibility rules), lesson_role (allowed values and pairing constraints), links (avoid:/fixes:/contradicts: prefixes vs free-form), and content (size cap). This is meaning well beyond bare schema field names.

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?

Opens with a specific verb+resource ('Write a memory') and immediately delimits the resource space by enumerating the allowed types (episode|fact|insight|skill|decision) and namespaces. An agent can distinguish this write-path tool from memory_search/memory_get without opening any schema.

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 when-to-use and when-not-to-use rules: write stable facts (preferences, conventions, environment constraints, pitfalls), exclude session-temporary details, and either attach valid_until or omit volatile status notes. It also prescribes reusing an existing key over creating a new entry, and routes the agent to declare a workspace project per host rules.

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

Deploy Server

Other Tools