Skip to main content
Glama
Sign In
engram

engram

by TushaeBXN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

engram_add_memory

Store a new memory drawer in the château. The result lists 'possible_updates': existing memories this one may replace. If it does, call engram_supersede (or pass 'supersedes' here).

Instructions

Store a new memory drawer in the château. The result lists 'possible_updates': existing memories this one may replace. If it does, call engram_supersede (or pass 'supersedes' here).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "engram_add_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
hallNofacts
roomNogeneral
wingNodefault
pinnedNo
reasonNoWhy it replaces it (used with 'supersedes')
sourceNoWhere it came from: user (the person said it), primary (original document, law, ruling, data), secondary (reporting or analysis), tool (search or program output), inference (your own conclusion)
contentYesMemory content to store
based_onNoIDs of memories that are evidence for this one
source_refNoCitation, URL or document it came from
supersedesNoID of a memory this one replaces (optional)
derived_fromNoIDs of memories this one was inferred from

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.10.5
    • addedInput schema / properties / based_on
      Added value: +{
+  "description": "IDs of memories that are evidence for this one",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / derived_from
      Added value: +{
+  "description": "IDs of memories this one was inferred from",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / source
      Added value: +{
+  "description": "Where it came from: user (the person said it), primary (original document, law, ruling, data), secondary (reporting or analysis), tool (search or program output), inference (your own conclusion)",
+  "enum": [
+    "user",
+    "primary",
+    "secondary",
+    "tool",
+    "inference"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / source_ref
      Added value: +{
+  "description": "Citation, URL or document it came from",
+  "type": "string"
+}
  2. First observedv1.7.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses a return-value behavior ('possible_updates') that signals implicit duplicate/replacement detection, which is genuinely non-obvious. But it says nothing about mutation semantics, permissions, or whether storage is append-only.

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?

Two tight sentences, front-loaded with the action and followed immediately by the actionable follow-up. No filler, though the jargon slightly obscures the payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter write tool with no output schema and no annotations, the description covers the critical routing case but omits the organizational taxonomy (hall/room/wing) and provenance fields that a caller must supply meaningfully. Adequate but with clear gaps.

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 coverage is 64% and the description only clarifies the supersedes/reason flow, adding a bit beyond the schema. It leaves the hall/room/wing taxonomy, pinned, based_on, and derived_from entirely to schema text, so it neither compensates for the gap nor adds much parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ("store a new memory drawer") and even hints at the supersede relationship. However, the metaphorical vocabulary ("château", "drawer") without definition makes the resource ambiguous, and it doesn't distinguish this from engram_kg_add or engram_diary_write among the many siblings.

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?

Explicitly tells the agent to inspect 'possible_updates' and route to engram_supersede or use the 'supersedes' parameter here — a real conditional rule with a named alternative. It stops short of saying when to prefer this store over sibling ingest tools like engram_kg_add.

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