MemAI

edit_memory

Correct a memory's content, source reference, title, or tags while keeping the previous version. Choose append mode to add new facts to a memory instead of replacing its body.

Instructions

Correct a memory's content or its source reference, keeping the previous version.

Corrections are common in append-only memory stores that only support delete, not edit; this preserves the old content instead of losing it.

mode='append' adds new_content as a new line at the end instead of replacing the body. Use it when a memory gains a fact rather than turning out to be wrong: the alternative is reading the whole thing, restating it and sending it back, which pays for the body twice and stakes the existing text on it being copied faithfully. Append what THIS memory gained. A fact about a further subject is a new memory plus an edge, not a line at the bottom -- appended text is ranked as part of the body it lands in and comes back with it.

source_ref points the memory at what its claim came from -- the field note() takes at write time, and the one a later pass checks the claim against. It is settable on its own, with no new_content, for the common case of a body that is right and a reference that is missing or has moved; an empty source_ref leaves the stored one alone, and clearing one is a dashboard edit. Passing neither is an error rather than a silent no-op.

title renames the memory: the one line a list shows it by, and the field weighing most in search, at most 120 characters. Settable on its own, like source_ref. A diagram is renamed through its graph instead -- its title is part of what generates the body, so a rename here would be overwritten by the next structural change.

tags REPLACES the tag set, comma-separated: pass the whole set that should survive, not the one being added. Settable on its own, and indexed, so this is how an untagged memory becomes findable by the words its body never uses. An empty string leaves the stored tags alone -- clearing them, like clearing a source_ref, is a dashboard edit.

Refuses to rewrite a diagram's content: that is generated from the graph, so a hand-written replacement would be silently overwritten by the next structural change -- edit the flow through diagram_node/diagram_edge. Its source_ref is ordinary metadata and is editable here like any other memory's.

Input Schema

TableJSON Schema

Name	Required	Default
`uid`	Yes
`mode`	No	replace
`note`	No
`tags`	No
`title`	No
`source_ref`	No
`new_content`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.1.1Sep 13, 2026

addedInput schema / properties / mode

Added value: +{
+  "default": "replace",
+  "title": "Mode",
+  "type": "string"
+}

addedInput schema / properties / new_content / default
```
Added value: +""
```

addedInput schema / properties / source_ref

Added value: +{
+  "default": "",
+  "title": "Source Ref",
+  "type": "string"
+}

addedInput schema / properties / tags

Added value: +{
+  "default": "",
+  "title": "Tags",
+  "type": "string"
+}

addedInput schema / properties / title

Added value: +{
+  "default": "",
+  "title": "Title",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "uid",
-  "new_content"
-]New value: +[
+  "uid"
+]

First observedv0.1.0Jul 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it preserves prior versions, refuses to rewrite diagram content (and why), treats empty strings as no-ops while an empty call is an error, caps titles at 120 characters, and states tags replace rather than merge. This is unusually rich behavioral disclosure.

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?

Front-loaded with purpose and organized per-parameter, with each paragraph earning its place. It is on the long side and the append rationale is somewhat discursive, but little is pure 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?

For a 7-parameter, no-annotation, no-output-schema mutation tool the coverage is strong: safety of prior versions, per-field semantics, error vs no-op behavior, and the diagram exclusion are all present. The unexplained `note` parameter and absent return-value behavior are the remaining 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 0%, so the description must compensate, and it thoroughly explains mode, new_content, source_ref, title, tags, and uid. However, the `note` parameter is never addressed as an argument (only 'note()' as a function), and the relationship between `note` and `new_content` in replace mode is left to inference, which is a real gap given zero schema documentation.

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?

Names a specific verb and resource ('Correct a memory's content or its source reference') and adds the distinguishing constraint 'keeping the previous version'. This separates it clearly from siblings like forget, purge_memory, and note, which an agent can tell apart without opening any schema.

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 states when to use mode='append' (a memory gaining a fact vs turning out wrong), when source_ref/title/tags are settable alone, that clearing is a dashboard edit rather than a call here, and that passing neither content nor source_ref is an error. It also names diagram_node/diagram_edge as the alternative for diagram edits and warns that an unrelated fact belongs in a new memory plus an edge.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit_memory

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools