MemAI

reasoning

Record the thinking behind a conclusion—hypothesis, method, result, revised belief—so future sessions reuse the analysis, not just the fact.

Instructions

Record an analysis worth keeping: what was thought, and what it settled.

For the PROCESS, not the fact it produced -- note() takes the fact. Stored as type='reasoning'; filter search/list_* with type='reasoning' to get these back. ONE analysis per memory: a second hypothesis tested in the same session is its own reasoning().

Input 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.
`result`	Yes	what came back. The measurement, not the interpretation.
`session`	No	groups what one conversation writes. Leave it empty to use this server process's own stamp.
`next_time`	Yes	what someone hitting this again should do differently.
`reasoning`	Yes	how you tested it -- what you read, ran or compared.
`hypothesis`	Yes	what you believed going in, as a claim that could be wrong.
`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.
`revised_belief`	Yes	what you believe now, and where it differs from the hypothesis. Say plainly when the hypothesis survived unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

Changed25 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 / hypothesis / description

Added value: +"what you believed going in, as a claim that could be wrong."

removedInput schema / properties / hypothesis / title
```
Removed value: -"Hypothesis"
```

addedInput schema / properties / next_time / description

Added value: +"what someone hitting this again should do differently."

removedInput schema / properties / next_time / title
```
Removed value: -"Next Time"
```

addedInput schema / properties / reasoning / description

Added value: +"how you tested it -- what you read, ran or compared."

removedInput schema / properties / reasoning / title
```
Removed value: -"Reasoning"
```

addedInput schema / properties / result / description

Added value: +"what came back. The measurement, not the interpretation."

removedInput schema / properties / result / title
```
Removed value: -"Result"
```

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 / revised_belief / description

Added value: +"what you believe now, and where it differs from the hypothesis. Say plainly when the hypothesis survived unchanged."

removedInput schema / properties / revised_belief / title
```
Removed value: -"Revised Belief"
```

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

Changed12 schema fields changedv0.1.1Sep 13, 2026

addedInput schema / properties / also

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

removedInput schema / properties / content

Removed value: -{
-  "title": "Content",
-  "type": "string"
-}

addedInput schema / properties / hypothesis

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

addedInput schema / properties / next_time

Added value: +{
+  "title": "Next Time",
+  "type": "string"
+}

addedInput schema / properties / reasoning

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

addedInput schema / properties / result

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

addedInput schema / properties / review_after

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

addedInput schema / properties / revised_belief

Added value: +{
+  "title": "Revised Belief",
+  "type": "string"
+}

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: +{
+  "title": "Title",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "content"
-]New value: +[
+  "title",
+  "hypothesis",
+  "reasoning",
+  "result",
+  "revised_belief",
+  "next_time"
+]

First observedv0.1.0Jul 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare the write/non-idempotent profile. The description adds genuinely new behavior: the record is stored as type='reasoning' and retrievable by filtering search/list_* on that type, plus the one-analysis-per-memory cardinality constraint. It does not cover dedup or overwrite behavior, so it stops short of full disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core definition, then two tight sentences covering the note() contrast, storage/retrieval, and cardinality. No filler; every sentence changes how an agent would call the tool.

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 6-required-parameter write tool with no output schema, the description covers purpose, sibling disambiguation, storage type, retrieval path, and granularity. It omits whether re-recording similar content is deduped or overwritten, a minor gap for an otherwise complete definition.

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% with 12 richly documented parameters (hypothesis, result, revised_belief, review_after, tags, domain, etc.), so the schema already carries parameter meaning. The description adds the type='reasoning' retrieval hint but no field-level semantics, matching the baseline-3 rule for high schema coverage.

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 ('Record an analysis worth keeping: what was thought, and what it settled'), and immediately distinguishes itself from the closest sibling by naming note() as the fact-taker. An agent can tell reasoning apart from note/anti_pattern/checkpoint 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 Guidelines4/5

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

Explicitly routes the agent: use this for the PROCESS, note() for the fact produced, and it states a granularity rule ('ONE analysis per memory; a second hypothesis is its own reasoning()'). It lacks exclusions against other memory-writing siblings (anti_pattern, checkpoint), so it is clear context without full alternative coverage.

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

reasoning

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools