brain-core

Overview Schema Source Related Servers Discussions Admin

brain_remember

Idempotent

Store a fact, decision, correction, preference, or relationship across sessions in one call, writing to every memory store and flagging duplicates or changed facts instead of silently overwriting.

Instructions

Write one memory item to every store in one call, in order: markdown vault, SQLite, Hindsight, and the entity graph (relations only).

    Use it the moment the user states a fact, decision, correction, preference or
    relationship worth keeping across sessions; one call per item. Not for whole documents
    or web pages (brain_distill) and not for the end-of-session summary (brain_session).

    Never deletes. A near-duplicate fact returns `status: duplicate` with the existing entry
    and writes nothing. A changed value is appended under a `⚠ Fact changed` banner with the
    old line kept, reported as `contradiction`. `layers` reports each store as
    written|exists|pending|failed|refused, so a dead store is visible, never silent. Text
    that looks like a secret is refused.

Input Schema

Name	Required	Description
`kind`	Yes	One of fact\|pattern\|decision\|correction\|note\|raw\|relation.
`text`	Yes	The memory itself, one item, plain text.
`extra`	No	Kind-specific fields. decision: title, reason, classification, confidence. correction: title, error, correction, rule, theme. relation: subject, predicate, object (or text 'S —[p]→ O'). note: section.
`force`	No	Write even when a near-duplicate exists.
`domain`	No	Topic tag such as 'trading' or 'system'; empty = none.
`source`	No	Where it came from: a URL, file path or 'user'.
`mission`	No	Mission id to tag, e.g. 'M-012'.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.2.6Nov 2, 2026

addedInput schema / properties / domain / description

Added value: +"Topic tag such as 'trading' or 'system'; empty = none."

addedInput schema / properties / extra / description

Added value: +"Kind-specific fields. decision: title, reason, classification, confidence. correction: title, error, correction, rule, theme. relation: subject, predicate, object (or text 'S —[p]→ O'). note: section."

addedInput schema / properties / force / description

Added value: +"Write even when a near-duplicate exists."

addedInput schema / properties / kind / description

Added value: +"One of fact|pattern|decision|correction|note|raw|relation."

addedInput schema / properties / mission / description
```
Added value: +"Mission id to tag, e.g. 'M-012'."
```

addedInput schema / properties / source / description

Added value: +"Where it came from: a URL, file path or 'user'."

addedInput schema / properties / text / description

Added value: +"The memory itself, one item, plain text."

First observedv0.1.0Nov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations: it discloses that nothing is ever deleted, that a near-duplicate returns status duplicate with the existing entry and writes nothing, that changed values are appended under a '⚠ Fact changed' banner with the old line preserved and reported as a contradiction, and that secrets are refused. It also explains the per-store `layers` report (written|exists|pending|failed|refused), which makes partial-failure behavior legible. Only auth/permission requirements are left unstated, keeping it just off a 5.

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 tight paragraphs ordered by importance: what it does, when to use it, then the behavioral contract. The multi-line formatting is slightly denser than necessary and the store enumeration could be a single clause, but every sentence carries information an agent needs.

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 7-parameter multi-store write with an output schema present, the description covers the missing pieces: mutation semantics, duplicate/contradiction handling, partial-failure visibility, and safety refusals. An agent has enough to call it correctly and interpret the outcome without further context.

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%, so `kind`, `text`, `extra`, `force`, `domain`, `source` and `mission` are already documented in the schema, and the description does not add new syntax or format detail for them. It only implicitly reinforces `kind` values by naming fact/decision/correction/preference/relationship in the usage sentence and by pairing the duplicate behavior with `force`. Baseline 3 is appropriate when the schema carries the load.

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 ('Write one memory item to every store in one call') and enumerates the target stores in write order (markdown vault, SQLite, Hindsight, entity graph). It explicitly names the two siblings it is not (brain_distill for documents, brain_session for summaries), so an agent can route 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 Guidelines5/5

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

Gives a concrete trigger ('the moment the user states a fact, decision, correction, preference or relationship worth keeping across sessions'), a cardinality rule ('one call per item'), and explicit exclusions mapped to the correct alternatives. Nothing about when-to-use is left to inference.

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

Deploy Server