Skip to main content
Glama
Skitchy

Rekindle

by Skitchy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

update_memory

Modify an existing memory in SQLite by changing only supplied fields, such as content, category, or importance, so you can correct or reclassify it without deleting and recreating it.

Instructions

Update an existing memory in the local SQLite database. Modifies only the fields you provide — omitted fields are left unchanged. The updated_at timestamp is set automatically. If content is changed, the full-text search index is rebuilt for this memory. Returns the full updated memory object on success, or {success: false, message: 'Memory not found'} if the ID does not exist. Use to correct inaccurate memories, adjust importance, or reclassify a memory's category without deleting and re-creating it.

Input Schema

NameRequiredDescriptionDefault
idYesThe UUID of the memory to update. Obtain from store_memory, search_memory, or list_memories results.
contentNoReplacement content for the memory. Omit to keep the existing content unchanged.
categoryNoNew category for the memory. Omit to keep the existing category unchanged.
importanceNoNew importance score from 1 (low) to 10 (critical). Omit to keep the existing score unchanged.
provenanceNoWrite attribution. Required when REKINDLE_REQUIRE_WRITE_PROVENANCE=1; never proof of authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / provenance
      Added value: +{
+  "description": "Write attribution. Required when REKINDLE_REQUIRE_WRITE_PROVENANCE=1; never proof of authorization.",
+  "properties": {
+    "author_identity": {
+      "description": "Claimed writer identity; attribution, not authentication.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "authorization_reference": {
+      "description": "Caller-supplied authority reference. Stored as unverified and never treated as authorization.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "client": {
+      "description": "Client performing the write, for attribution only.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "request_id": {
+      "description": "Unique caller request identifier.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "thread_id": {
+      "description": "Calling thread or session identifier.",
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "client",
+    "thread_id",
+    "request_id",
+    "author_identity",
+    "authorization_reference"
+  ],
+  "type": "object"
+}
  2. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / category / description
      Previous value: -"New category"New value: +"New category for the memory. Omit to keep the existing category unchanged."
    • changedInput schema / properties / content / description
      Previous value: -"New content"New value: +"Replacement content for the memory. Omit to keep the existing content unchanged."
    • changedInput schema / properties / id / description
      Previous value: -"The memory ID to update"New value: +"The UUID of the memory to update. Obtain from store_memory, search_memory, or list_memories results."
    • changedInput schema / properties / importance / description
      Previous value: -"New importance score"New value: +"New importance score from 1 (low) to 10 (critical). Omit to keep the existing score unchanged."
  3. First observedv0.2.0

TDQS

A4.1/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 behavioral load and largely delivers: partial-update semantics, automatic updated_at, FTS index rebuild on content change, and both success and not-found return shapes. It omits the conditional write-provenance requirement and any authorization/permission expectations, which the schema alone covers.

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?

The core patch semantics and the use-case sentence are front-loaded, and each sentence carries information (state model, auto-timestamp, index rebuild, return contract). It is on the long side — five sentences for a mutation tool — but nothing is filler.

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?

A mutation tool with no annotations and no output schema, so the description must cover behavior and returns — and it does, including the not-found error object. The one gap is the nested provenance object's conditional requirement, which is pushed entirely to the schema and unmentioned in prose.

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 the baseline is 3. The description adds only the semantic that omitted fields are preserved and that changing content triggers a reindex; it does not clarify the importance scale, category enum choices, or provenance nesting beyond what the schema already documents.

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?

States a specific verb and resource (update an existing memory) plus the patch semantics that define it, and explicitly contrasts with delete-and-recreate. An agent can distinguish it from store_memory and delete_memory without reading either schema.

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?

Gives concrete use cases — correct inaccurate memories, adjust importance, reclassify category — and frames it as the alternative to deleting and re-creating. It does not explicitly say when to prefer store_memory instead (i.e., for new memories), so the routing guidance is clear but not exhaustive.

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