MemAI

note

Save a long-term fact, decision, or finding as timeless memory so agents can recall it by relevance, not recency, across sessions.

Instructions

Save a general long-term memory (fact, decision, finding). Stored as type='note'.

Timeless knowledge -- retrieved by relevance, not recency. Bring it back with recall() (or search(type='note')); must_read(type='note') lists the most recent ones as headers.

Input Schema

TableJSON Schema

Name	Required	Description
`also`	No	other domain paths this belongs to, comma-separated: the subjects that cut across the tree `domain` sits in, such as the end-to-end flow a routine is one step of. Every read scoped to one of them returns it. A path `domain` already sits under is dropped as redundant. At most 200 characters each.
`tags`	No	comma-separated keywords and synonyms. Retrieval is BM25 over content, tags and domain paths, and tags weigh second only to the body, so they make a memory findable by words its own text never uses: the identifier, the error string, the plain phrasing someone will type. A memory with none is reachable only by quoting itself. At most 1000 characters.
`title`	Yes	one line naming what this memory is about, in the words someone would look for it by. A list shows it instead of the opening of the body, and it outweighs every other field in search, so a title that repeats the type ("note about the parser") names nothing. At most 120 characters; a name that needs more is summarizing the body.
`domain`	No	the subject this belongs to, as a path from the outermost scope in ('acme/x100/p200'). File it as deep as the fact is specific -- a note about one routine goes on the routine, and still comes back when someone asks about the module or the product above it. At most 200 characters.
`content`	Yes	ONE fact, and what a reader needs to use it -- what holds, where it holds, what it rules out. Retrieval ranks whole memories, so a body answering four questions comes back for all four and is read for one: write the second subject as its own memory, on its own domain, and connect the two with link_memories(). A [[uid]] typed inside a body is a reference a reader can follow, not an edge -- get_relations() and the graph do not see it until link_memories() creates one. Past a couple of thousand characters, a body is usually several memories written as one.
`session`	No	groups what one conversation writes. Leave it empty to use this server process's own stamp.
`source_ref`	No	what the fact came FROM -- a path, a URL, a table name -- so a later pass can check the claim against the thing itself instead of inferring what to check from the wording. At most 500 characters.
`review_after`	No	when this stops being safe to trust unchecked, as a date ('2026-11-01') or a span from today ('90d'). pulse() counts what is overdue in a scope as `scope.stale` and optimize_scan lists it. Leave it empty for anything that does not go stale -- most facts do not, and a date nobody meant is worse than none.

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.16.1Oct 16, 2026

addedInput schema / properties / also / description

Added value: +"other domain paths this belongs to, comma-separated: the subjects that cut across the tree `domain` sits in, such as the end-to-end flow a routine is one step of. Every read scoped to one of them returns it. A path `domain` already sits under is dropped as redundant. At most 200 characters each."

removedInput schema / properties / also / title
```
Removed value: -"Also"
```

addedInput schema / properties / content / description

Added value: +"ONE fact, and what a reader needs to use it -- what holds, where it holds, what it rules out. Retrieval ranks whole memories, so a body answering four questions comes back for all four and is read for one: write the second subject as its own memory, on its own domain, and connect the two with link_memories(). A [[uid]] typed inside a body is a reference a reader can follow, not an edge -- get_relations() and the graph do not see it until link_memories() creates one. Past a couple of thousand characters, a body is usually several memories written as one."

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

addedInput schema / properties / domain / description

Added value: +"the subject this belongs to, as a path from the outermost scope in ('acme/x100/p200'). File it as deep as the fact is specific -- a note about one routine goes on the routine, and still comes back when someone asks about the module or the product above it. At most 200 characters."

removedInput schema / properties / domain / title
```
Removed value: -"Domain"
```

addedInput schema / properties / review_after / description

Added value: +"when this stops being safe to trust unchecked, as a date ('2026-11-01') or a span from today ('90d'). pulse() counts what is overdue in a scope as `scope.stale` and optimize_scan lists it. Leave it empty for anything that does not go stale -- most facts do not, and a date nobody meant is worse than none."

removedInput schema / properties / review_after / title
```
Removed value: -"Review After"
```

addedInput schema / properties / session / description

Added value: +"groups what one conversation writes. Leave it empty to use this server process's own stamp."

removedInput schema / properties / session / title
```
Removed value: -"Session"
```

addedInput schema / properties / source_ref / description

Added value: +"what the fact came FROM -- a path, a URL, a table name -- so a later pass can check the claim against the thing itself instead of inferring what to check from the wording. At most 500 characters."

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

addedInput schema / properties / tags / description

Added value: +"comma-separated keywords and synonyms. Retrieval is BM25 over content, tags and domain paths, and tags weigh second only to the body, so they make a memory findable by words its own text never uses: the identifier, the error string, the plain phrasing someone will type. A memory with none is reachable only by quoting itself. At most 1000 characters."

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

addedInput schema / properties / title / description

Added value: +"one line naming what this memory is about, in the words someone would look for it by. A list shows it instead of the opening of the body, and it outweighs every other field in search, so a title that repeats the type (\"note about the parser\") names nothing. At most 120 characters; a name that needs more is summarizing the body."

removedInput schema / properties / title / title
```
Removed value: -"Title"
```
removedInput schema / title
```
Removed value: -"noteArguments"
```

Changed5 schema fields changedv0.1.1Sep 13, 2026

addedInput schema / properties / also

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

addedInput schema / properties / review_after

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

addedInput schema / properties / source_ref

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

addedInput schema / properties / title

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

changedInput schema / required

Previous value: -[
-  "content"
-]New value: +[
+  "title",
+  "content"
+]

First observedv0.1.0Jul 10, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false; the description adds the useful trait "timeless knowledge -- retrieved by relevance, not recency," which explains how it will resurface. It does not disclose that repeat saves create separate memories (non-idempotent) or anything about the write's side effects, so with annotations carrying the safety profile this is a moderate add.

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?

Three short sentences, front-loaded with purpose and the type marker before the retrieval guidance. There is no padding, though the retrieval sentence could be tightened slightly.

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?

No output schema exists, but the tool is a write operation whose result is well understood, and all 8 parameters are fully documented in the schema. The description covers purpose, storage type and retrieval path, leaving only the non-idempotent write behavior unstated.

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% and each of the 8 parameters has a rich, self-contained description, so the baseline is 3. The description adds only the implicit type='note' value, which corresponds to no actual parameter, so it does not extend parameter meaning beyond the schema.

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+resource ("Save a general long-term memory (fact, decision, finding)") and pins the stored type as type='note', which separates it from type-specific siblings like task_note and anti_pattern. It is clear, but it never explicitly contrasts itself against the save-side siblings (checkpoint, reasoning, anti_pattern), so it stops short of full sibling differentiation.

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 clear retrieval context and names the alternatives for reading it back (recall(), search(type='note'), must_read(type='note')), so an agent knows the round-trip. It does not say when to prefer note over other save tools, so the when-to-write guidance is implied rather than stated.

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

note

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools