Skip to main content
Glama
worakorn-prince

th-memory-mcp

by worakorn-prince
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update a memory

update_memory

Modify mutable memory fields such as summary, importance, confidence, or validity in place, and supersede content changes by default to preserve history.

Instructions

Update mutable fields (summary/importance/confidence/valid_from/valid_until/metadata) in place. If content changes, a superseding memory is created by default (set supersede=false to edit in place).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesMemory id to update
contentNoNew content. When provided, a superseding memory is created (supersede=true) unless supersede=false.
summaryNoNew summary
metadataNoNew metadata object (replaces)
supersedeNoIf content changes, create a superseding memory instead of editing in place (default true)
validFromNoISO timestamp or null to clear
confidenceNo
importanceNo
validUntilNoISO timestamp or null to clear

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.2.9
    • addedInput schema / properties / validFrom
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "ISO timestamp or null to clear"
+}
    • addedInput schema / properties / validUntil / anyOf
      Added value: +[
+  {
+    "$ref": "#/properties/validFrom/anyOf/0"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / validUntil / type
      Removed value: -[
-  "string",
-  "null"
-]
  2. First observedv2.2.1

TDQS

A3.7/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 it does disclose the single most important non-obvious trait: changing content creates a superseding memory by default rather than mutating the row. It still omits permissions requirements, reversibility, and what happens to the prior memory (invalidation vs retention), so it is strong but not complete.

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?

Two dense sentences with zero filler; the in-place scope comes first and the default-fork side effect second, so the most consequential behavior is front-loaded. Nothing repeats the title or wastes tokens.

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 a 9-parameter mutation tool with no annotations and no output schema, the description covers field mutability and the supersede default but says nothing about the response (does the returned id change when a superseding memory is created?) or about failure modes such as an unknown id. Adequate, but gaps remain for an agent to call it confidently.

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 78%, so most parameters are already documented in the schema, including the supersede flag and the content/supersede interaction. The description restates the field set (with snake_case names that differ from the schema's camelCase) and adds no format or constraint detail beyond the schema, so it sits at the baseline.

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 (update) and resource (memory), and enumerates the mutable fields plus the in-place vs supersede distinction. This separates it from write siblings like remember and merge_memory, but it never names an alternative explicitly, so an agent must infer routing from the field list alone.

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?

Usage is implied by 'Update mutable fields ... in place' and by the supersede=false escape hatch, which tells the agent how to force an edit rather than a fork. However, there is no explicit when-to-use vs remember/merge_memory/consolidate guidance and no stated preconditions (e.g. that the id must exist and be live).

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