MemAI

edit_memory

Destructive

Correct a memory's content, source_ref, title, or tags while preserving the previous version in edit history. Use append mode to add a fact without rewriting the 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. Each field is settable on its own; passing none of new_content, source_ref, title, tags and goal is an error rather than a silent no-op.

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. A task's content is generated from its goal and items the same way: rewrite its goal with goal, and its items through task_item().

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uid`	Yes	the memory.
`goal`	No	a task's new goal, held to the rules task() states; the previous goal stays in the edit history. Refused on any other type.
`mode`	No	'replace' or 'append'. '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.	replace
`note`	No	why it changed, kept with the previous version in the edit history.
`tags`	No	REPLACES the tag set, comma-separated: pass the whole set that should survive, not the one being added. Indexed, so this is how an untagged memory becomes findable by the words its body never uses. Empty leaves the stored tags alone -- clearing them, like clearing a source_ref, is a dashboard edit.
`title`	No	renames the memory: the one line a list shows it by, and the field weighing most in search, at most 120 characters. 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.
`source_ref`	No	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. Settable with no `new_content`, for the common case of a body that is right and a reference that is missing or has moved; empty leaves the stored one alone, and clearing one is a dashboard edit.
`new_content`	No	the corrected body, or with mode='append' the line to add.

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv0.16.1Oct 16, 2026

addedInput schema / properties / goal

Added value: +{
+  "default": "",
+  "description": "a task's new goal, held to the rules task() states; the previous goal stays in the edit history. Refused on any other type.",
+  "type": "string"
+}

addedInput schema / properties / mode / description

Added value: +"'replace' or 'append'. '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."

removedInput schema / properties / mode / title
```
Removed value: -"Mode"
```

addedInput schema / properties / new_content / description

Added value: +"the corrected body, or with mode='append' the line to add."

removedInput schema / properties / new_content / title
```
Removed value: -"New Content"
```

addedInput schema / properties / note / description

Added value: +"why it changed, kept with the previous version in the edit history."

removedInput schema / properties / note / title
```
Removed value: -"Note"
```

addedInput schema / properties / source_ref / description

Added value: +"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. Settable with no `new_content`, for the common case of a body that is right and a reference that is missing or has moved; empty leaves the stored one alone, and clearing one is a dashboard edit."

removedInput schema / properties / source_ref / title
```
Removed value: -"Source Ref"
```

addedInput schema / properties / tags / description

Added value: +"REPLACES the tag set, comma-separated: pass the whole set that should survive, not the one being added. Indexed, so this is how an untagged memory becomes findable by the words its body never uses. Empty leaves the stored tags alone -- clearing them, like clearing a source_ref, is a dashboard edit."

removedInput schema / properties / tags / title
```
Removed value: -"Tags"
```

addedInput schema / properties / title / description

Added value: +"renames the memory: the one line a list shows it by, and the field weighing most in search, at most 120 characters. 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."

removedInput schema / properties / title / title
```
Removed value: -"Title"
```
addedInput schema / properties / uid / description
```
Added value: +"the memory."
```
removedInput schema / properties / uid / title
```
Removed value: -"Uid"
```
removedInput schema / title
```
Removed value: -"edit_memoryArguments"
```

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.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructive/non-idempotent), disclosing that the previous version is preserved in edit history, that no-op calls with all fields empty are an error rather than silent success, that empty tag/source_ref values leave stored values alone (clearing is a dashboard edit), and that diagram/task bodies are generated and would be silently overwritten.

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 the core operation, and the modal/refusal guidance is dense and useful. The rationale sentence about append-only stores is justificatory filler, and three paragraphs is on the long side, so it stops short of maximal conciseness.

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

Completeness5/5

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

For an 8-parameter mutation tool with no output schema, the description covers modes, partial-field semantics, the all-empty error case, and which memory types are editable. Combined with 100% schema coverage and annotations carrying the safety profile, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the per-parameter descriptions already carry most meaning. The prose adds one genuinely new rule not in the schema ('passing none of new_content, source_ref, title, tags and goal is an error'), which lifts it slightly above baseline.

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+resource+scope: 'Correct a memory's content or its source reference, keeping the previous version.' It also distinguishes itself from siblings by noting it is not delete (which it contrasts against the append-only store) and not the diagram/task editors, so an agent can route correctly.

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?

Explicit routing: use mode='append' when a memory gains a fact vs. mode='replace' when it turns out wrong; rewrite a diagram's flow via diagram_node/diagram_edge; rewrite a task's goal with `goal` and its items through task_item(). Both when-to-use and when-not are present.

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