MemAI

reasoning

Record a hypothesis, how you tested it, and what the result changed. Capture the process behind a conclusion, not just the fact it produced.

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(). See note() on what a body holds and when it is two memories.

title: one line naming what this memory is about, in the words someone would look for it by. It is what a list shows 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, and a name that needs more than that is summarizing the body instead of naming it.

hypothesis: what you believed going in, as a claim that could be wrong. reasoning: how you tested it -- what you read, ran or compared. result: what came back. The measurement, not the interpretation. revised_belief: what you believe now, and where it differs from the hypothesis. Say plainly when the hypothesis survived unchanged. next_time: what someone hitting this again should do differently.

also, review_after and source_ref behave as in note().

tags carries the synonyms the body never uses: retrieval is BM25 over content and tags, so a memory with none is reachable only by quoting itself. See note() for what belongs there.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`also`	No
`tags`	No
`title`	Yes
`domain`	No
`result`	Yes
`session`	No
`next_time`	Yes
`reasoning`	Yes
`hypothesis`	Yes
`source_ref`	No
`review_after`	No
`revised_belief`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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

Behavior4/5

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

With no annotations, the description carries the full burden and does much of it: it discloses the storage type ('type=reasoning'), the retrieval mechanism ('BM25 over content and tags'), and search-ranking behavior ('a title ... outweighs every other field in search'). It omits auth/permission needs, error behavior, and any body-size limits, so it falls short of full 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?

The purpose and the note() routing are front-loaded, and the required-field explanations are laid out in sequence. It is on the long side — the title paragraph in particular runs several sentences — but nearly every sentence carries field-level or retrieval information rather than 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 12-parameter, 6-required mutation tool with no annotations and no output schema, the description supplies purpose, storage semantics, retrieval behavior, and field meanings. The gaps are domain and session semantics, and nothing about failure or permission behavior, but the core calling information an agent needs is present.

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 0%, so the description must compensate and largely does: it gives explicit semantics for all six required fields (title, hypothesis, reasoning, result, revised_belief, next_time) plus tags, and delegates also/review_after/source_ref to note(). domain and session, however, are never explained anywhere, leaving two of twelve parameters undocumented.

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: 'For the PROCESS, not the fact it produced -- note() takes the fact.' An agent can route between reasoning() and note() 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?

Names the alternative (note()) and the condition that selects it, plus the cardinality rule ('ONE analysis per memory: a second hypothesis tested in the same session is its own reasoning()'). It also tells the agent how to retrieve these later (filter search/list_* with type='reasoning'), which is explicit when-to-use guidance.

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