graph-mind

Overview Schema Source Related Servers Discussions Admin

brain_remember

Proactively save what the user says as memories, including preferences, plans, and changeable facts, and update prior values when the same person or attribute changes.

Instructions

Save what the user just told you, in their own words. Call this proactively.

    A fact that can change later (where they live or work, a pet, a preference, a plan, a
    number they track): also pass `about` (who or what, e.g. "Kongi", "me") and `attribute`
    (which property, a short English snake_case name, e.g. "breed", "home_city",
    "favorite_coffee"). A later value with the same `about` and `attribute` replaces this
    one and recall shows both: the value now and what it was before. Use the same
    `attribute` names every time, and never put the value in the name: "last_trip", not
    "last_trip_paris", or the next trip will not replace it.

    Use it the moment the user mentions anything about their life, work, plans, preferences,
    people, places, meals, purchases, health, decisions or events, e.g. "I had kimchi fried
    rice today", "my dog is called Kongi", "we moved the meeting to Tuesday". Do not ask
    whether to save it and do not wait to be told "remember this". Only `content` is
    required: put the user's own sentence there verbatim. Add `entities` (who or what it is
    about) and `effective_at` (when it happened, ISO time) when you know them. If it updates
    something remembered earlier, pass that memory's id as `supersedes_memory_id`.
    Decisions and their reasons are memories too: `memory_type="decision"`, the reason in
    `content`, the project or component in `entities`.

    Save silently. Do not tell the user you saved it ("I've noted that", "저장해 뒀어"); just
    carry on with the conversation. Talk about memory only if the user asks what you remember
    or whether something was saved.

Input Schema

TableJSON Schema

Name	Required	Default
`tags`	No
`about`	No
`scope`	No	global
`title`	No
`content`	Yes
`entities`	No
`modality`	No
`attribute`	No
`memory_id`	No
`retention`	No
`attributes`	No
`confidence`	No
`importance`	No
`source_ref`	No	conversation
`memory_type`	No	fact
`source_type`	No	mcp-client
`effective_at`	No
`memory_class`	No
`related_memory_ids`	No
`supersedes_memory_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only declare write/non-idempotent/non-destructive; the description adds the substantive mutation semantics — a later value with the same `about`+`attribute` replaces the earlier one, recall surfaces both old and new, and the attribute name must be stable ('last_trip', not 'last_trip_paris') or replacement silently fails. It also discloses the user-facing contract ('Save silently', never announce the save). This is exactly the non-obvious behavior an agent could not infer from the structured fields, and it is consistent with destructiveHint=false.

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 the core action and organized into short paragraphs, each carrying distinct content (what to save, how changeable facts work, when to trigger, how to behave). It is long for a single tool and repeats the silent-save instruction twice, but the length is largely justified by the 20-parameter surface and supersession subtlety.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations are present and an output schema exists, so return values need no explanation and the behavioral half is well covered. However, for a 20-parameter tool the description leaves the majority of parameters unexplained (notably `scope`, `retention`, `title`, `tags`), leaving an agent guessing on invocation details that materially affect where and how the memory lands.

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 0% across 20 parameters, so the description carries the full burden and only partially meets it: it meaningfully explains `content`, `about`, `attribute`, `entities`, `effective_at`, `supersedes_memory_id` and `memory_type`. Critical parameters such as `scope`, `title`, `tags`, `retention`, `memory_class`, `modality` and the object-typed `attributes` are left entirely undefined, and `attributes` vs `attribute` is a real confusion hazard the text does not disambiguate.

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?

The description states a specific verb and resource ('Save what the user just told you, in their own words') and makes the scope concrete by contrasting with recall's behavior ('recall shows both: the value now and what it was before'). It never names a sibling to route away from, so it is clear but not sibling-differentiating in the way a 5 requires.

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?

Usage is unusually explicit: 'Call this proactively,' 'Use it the moment the user mentions anything about their life, work, plans...', plus the exclusion-by-behavior 'Do not ask whether to save it and do not wait to be told "remember this".' It lacks any named alternative or 'do not use this when' exclusion (e.g. vs brain_checkpoint or brain_forget), which keeps it short of a 5.

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

Deploy Server