Skip to main content
Glama
Sign In
engram

engram

by TushaeBXN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

engram_correct

Save a correction: a new memory that replaces an outdated one (same wing/room/hall). The old memory stays searchable but is marked superseded, and search shows the correction first. Safe to retry.

Instructions

Save a correction: a new memory that replaces an outdated one (same wing/room/hall). The old memory stays searchable but is marked superseded, and search shows the correction first. Safe to retry.

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": {
      "memory_id": "<memory_id>",
      "content": "<content>"
    },
    "name": "engram_correct"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonNoWhy it changed
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)
contentYesThe corrected, current information
based_onNoIDs of memories that support the corrected version
memory_idYesID (or unique prefix) of the outdated memory
source_refNoCitation, URL or document it came from

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.10.5
    • addedInput schema / properties / based_on
      Added value: +{
+  "description": "IDs of memories that support the corrected version",
+  "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.8/5.0
Behavior4/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 well: it discloses what happens to the old memory (stays searchable but marked superseded), how search ordering changes (correction shown first), and that the operation is idempotent ('Safe to retry'). It does not cover permissions or what happens to links/metadata on the superseded memory, but the mutation semantics are unusually well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no waste. The core action is front-loaded, the behavioral consequences follow, and the retry-safety note sits last in exactly the right place.

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 mutation tool with no annotations and no output schema, the description covers what changes, what survives, and retry safety, which is most of what an agent needs before calling. The remaining gap is its relationship to the overlapping engram_supersede and engram_dispute siblings.

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 100%, so all six parameters, including the source enum and based_on array, are already documented in the schema. The description adds no parameter-level detail beyond the implicit wing/room/hall scoping, so the baseline 3 applies.

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 specific verb and resource ('Save a correction: a new memory that replaces an outdated one') and adds the scope constraint (same wing/room/hall). It does not differentiate itself from the sibling engram_supersede, which from the name alone sounds like it does the same replacement, so an agent cannot fully disambiguate the two from the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The constraint 'same wing/room/hall' implies context for use, and 'Safe to retry' hints at retry behavior, but the description never says when to use this rather than engram_supersede or engram_dispute, which are the closest alternatives. Usage is implied, not stated.

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