MemAI

checkpoint

Snapshot current working state to let the next session resume with the right context.

Instructions

Snapshot current working state (intent/established/pursuing/open_questions).

A summary of where the work stands, so the next session picks up the right bearing via pulse(). Fields are free-length; still prefer a readable summary here and put timeless detail into note() -- checkpoints are read for bearing, not as an archive. One fact per note(), each cited back here by [[uid]] and linked with link_memories(); pulse() returns the latest checkpoint IN FULL, so every session pays for whatever was parked in these fields. Stored as type='checkpoint'.

A domain holds ONE active checkpoint. While one is already filed at domain, the call is refused and nothing is written: the refusal lists it under checkpoints. Read it with get_memory(uid) and decide whether its work is done. Done: forget(uid, reason='...'), then call again. Not done: carry what still holds into these fields and call again with supersedes='', which archives it as superseded by the new one. A checkpoint past the age limit set in the dashboard refuses every write under its domain the same way, flagged overdue, until it is settled.

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.
`intent`	Yes	what the work is for, in a sentence or two.
`session`	No	groups what one conversation writes. Leave it empty to use this server process's own stamp.
`pursuing`	Yes	what comes next, specific enough to start on.
`supersedes`	No	the active checkpoints this one replaces, comma-separated uids: every one already filed at `domain`, and every overdue one above it that a refusal named. Each is archived with this one as its successor.
`established`	Yes	what is done and what was decided, with the [[uid]] of each note that holds the detail.
`open_questions`	Yes	what is still undecided or unverified.

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 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 / 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 / established / description

Added value: +"what is done and what was decided, with the [[uid]] of each note that holds the detail."

removedInput schema / properties / established / title
```
Removed value: -"Established"
```

addedInput schema / properties / intent / description

Added value: +"what the work is for, in a sentence or two."

removedInput schema / properties / intent / title
```
Removed value: -"Intent"
```
addedInput schema / properties / open_questions / description
```
Added value: +"what is still undecided or unverified."
```
removedInput schema / properties / open_questions / title
```
Removed value: -"Open Questions"
```

addedInput schema / properties / pursuing / description

Added value: +"what comes next, specific enough to start on."

removedInput schema / properties / pursuing / title
```
Removed value: -"Pursuing"
```

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 / supersedes

Added value: +{
+  "default": "",
+  "description": "the active checkpoints this one replaces, comma-separated uids: every one already filed at `domain`, and every overdue one above it that a refusal named. Each is archived with this one as its successor.",
+  "type": "string"
+}

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: -"checkpointArguments"
```

Changed4 schema fields changedv0.1.1Sep 13, 2026

addedInput schema / properties / also

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

addedInput schema / properties / tags

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

addedInput schema / properties / title

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

changedInput schema / required

Previous value: -[
-  "intent",
-  "established",
-  "pursuing",
-  "open_questions"
-]New value: +[
+  "title",
+  "intent",
+  "established",
+  "pursuing",
+  "open_questions"
+]

First observedv0.1.0Jul 10, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and non-idempotency, so this is a write tool with tame safety semantics. The description adds real behavioral value beyond that: it discloses the refusal path, the single-active-checkpoint constraint, the `overdue` age-limit refusal that blocks all writes under a domain, and the archival-by-supersedes behavior. It does not describe the return/refusal payload shape beyond naming the `checkpoints` key.

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, then constraints, then the recovery workflow, so the critical constraint is reachable early. It is long for a description and repeats "call again" and the supersede instruction several times, but nearly every sentence carries a rule an agent needs; the redundancy is mild rather than padding.

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 a 10-param write tool with no output schema and rich annotations, the description covers purpose, write semantics, refusal handling, alternative tools, and storage type. An agent could execute the refusal-recovery loop correctly from this text alone, which is the main failure mode for this tool.

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 description coverage is 100%, so the baseline is 3. The description nonetheless adds operational meaning the schema does not carry: that these five required fields are consumed in full by every pulse() call, that they should be short and bearings-oriented, that detail belongs in note() cited via [[uid]], and how supersedes is populated from refusal output. That lifts it above the schema-only 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?

Opens with a specific verb+resource ("Snapshot current working state") and immediately enumerates the fields that constitute the snapshot. It explicitly distinguishes itself from sibling note() by contrasting bearing-reading checkpoints with timeless archive detail, so an agent can separate the two without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when/when-not routing: one active checkpoint per domain, refusal when one is already filed, and the exact decision tree (done -> forget then retry; not done -> supersede with the uid). It also names the sibling read path (pulse(), get_memory()) and the archive escape hatches, leaving nothing to inference.

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

checkpoint

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools