Skip to main content
Glama
liza-studio

skillmem — long-term memory for Claude Code & Codex

by liza-studio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mem_write

Create a new memory record (note, rule, or pointer) as unapproved agent data. It stays untrusted until the owner approves it; near-duplicates are refused.

Instructions

Create a new memory (a note, a rule, a pointer). WRITES: inserts one record marked origin='agent' and UNAPPROVED — it reaches other agents as data until the owner runs skillmem trust <slug> at a terminal; there is no tool to approve. slug must be new: an existing slug with different text is refused (use mem_update with a reason); byte-identical text is returned unchanged and keeps its approval. check_conflicts (default true) refuses a near-duplicate and names the overlapping records — pass false only deliberately. ttl_days sets an expiry; on an existing record a field sent as null clears it. Returns ok, slug and id. Use mem_learn for a procedure learned by doing; mem_update to change text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
kindNonote
slugYes
tagsNo
titleYes
topicsNo
projectNo
ttl_daysNo
check_conflictsNoReject if word overlap (shared words / smaller set) > 0.7 with an existing memory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.12.0
    • changedInput schema / properties / project / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / tags / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedInput schema / properties / topics / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedInput schema / properties / ttl_days / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
  2. Changed2 schema fields changedv0.11.0
    • removedInput schema / properties / agent
      Removed value: -{
-  "type": "string"
-}
    • changedInput schema / properties / check_conflicts / description
      Previous value: -"Reject if Jaccard word overlap > 0.7 with an existing memory."New value: +"Reject if word overlap (shared words / smaller set) > 0.7 with an existing memory."
  3. First observedv0.10.5

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses that writes are marked origin='agent' and UNAPPROVED, that approval only happens out-of-band via `skillmem trust <slug>` with no approving tool, the conflict-refusal behavior, and the idempotency rule (byte-identical text returned unchanged, keeping approval). This is exactly the behavioral context annotations would otherwise supply.

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?

Densely packed but front-loaded: the purpose lands in the first sentence, then write/approval semantics, then slug rules, then conflict and ttl rules, then sibling routing. Nearly every clause carries information, though the run-on second sentence could be split for readability.

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 9-parameter mutation tool with no annotations and no output schema, this covers the critical unknowns: mutation effect, approval flow, idempotency, conflict default, and return shape (ok, slug, id). The remaining gap is the semantics of the non-core parameters (kind, tags, topics, project).

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 only 11% across 9 parameters, so the description must compensate and does so for slug, check_conflicts and ttl_days (including the null-clears behavior). However, kind, tags, topics, project, title and body get no semantic treatment beyond their names, leaving roughly half the surface undocumented.

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 and resource — 'Create a new memory' — and immediately qualifies the scope with the note/rule/pointer distinction. It also distinguishes itself from siblings by naming mem_learn and mem_update for the adjacent jobs.

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?

Explicitly routes the agent: 'Use mem_learn for a procedure learned by doing; mem_update to change text.' It also gives conditional guidance on check_conflicts ('pass false only deliberately') and states what to do when a slug already exists (use mem_update with a reason).

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