graph-mind

Overview Schema Source Related Servers Discussions Admin

brain_folder

Idempotent

Set, inspect, or share where your personal Graph-MIND memory lives: choose a synced folder or local Postgres for access across your own PCs.

Instructions

Where the user's own personal memory lives, and which of their own PCs share it.

    Not for teams: project brains shared with teammates are brain_checkpoint.

    Call it with `path` when the user names a folder for their memory, e.g. "use my Google
    Drive's Graph-MIND folder as my brain". A folder that OneDrive, Google Drive or Dropbox
    syncs makes the same memory available on every PC where the user chooses it too; nothing
    else is needed. Without `path` it reports the current folder and the devices writing to it.
    `path="local"` keeps the brain in this PC's own Postgres instead, shared the instant it is
    written (no sync delay).

    Other PCs: when the user asks to let their other PCs use this brain ("다른 PC도 붙게 해줘"),
    call it with `path="share"`. It opens this PC's Postgres to the local network and Tailscale
    (Windows may ask the user to approve a firewall rule once) and returns a
    `connection_code`. Show the user that code and tell them to paste it to the AI on the
    other PC; it contains the password, so say not to post it anywhere public.
    Codes: when the user pastes any Graph-MIND code ("gm1." for their own other PC, "gmt1."
    for a team invite), call this with `path=<the code>`; it does the right thing for either,
    so never ask the user which kind it is.

    `share_existing=true` sends what this PC remembers and the shared memory lacks (only that:
    it also repairs turns that missed a hub that was down). It uploads
    it to wherever the folder syncs. Set it only when the user has explicitly agreed to that.

    `reindex=true` brings the search index up to date (links new memories, embeds unembedded
    ones). Saving already does this; it is for a large imported backlog.

    Moving a whole memory as one file ("내 기억 파일로 내보내줘", "이 기억 파일 가져와"):
    `export_to=<file path>` writes every memory and conversation turn into that file;
    `import_from=<file path>` adds such a file's contents to this memory, skipping what is
    already here. Only when the user asks. Tell them the file holds their entire memory
    (secrets were masked when saved), so keep it private like a diary.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	No
`reindex`	No
`export_to`	No
`import_from`	No
`share_existing`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.9.0Oct 16, 2026

addedInput schema / properties / export_to

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Export To"
+}

addedInput schema / properties / import_from

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Import From"
+}

First observedv0.1.0Oct 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses real side effects: `path="share"` opens Postgres to the LAN/Tailscale, may trigger a one-time firewall prompt, and returns a connection_code containing a password with an explicit warning not to post it publicly. It also flags that export files contain the entire memory (secrets masked) and that share_existing uploads to the sync folder.

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?

Purpose and the team exclusion are front-loaded, then usage follows mode-by-mode, which is the right order. It is still long and repetitively framed around quoted user utterances, but almost every sentence adds a distinct operational rule rather than restating the schema.

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 five-parameter tool with no schema descriptions but a present output schema, the description covers every parameter, the side effects of each mode, the privacy caveats, and the sibling boundary. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does so: `path` is defined across its value space (a named sync folder, `"local"` for on-PC Postgres, `"share"`, or a pasted gmt1./gm1. code), and reindex, export_to, import_from, and share_existing each get a concrete meaning, trigger, and effect.

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 opening states the resource (the user's personal memory folder and which PCs share it), and the second paragraph explicitly excludes the sibling case: 'Not for teams: project brains shared with teammates are brain_checkpoint.' However, the tool is an omnibus of modes (folder config, share, code redemption, export/import, reindex) that the name 'brain_folder' does not signal, so an agent must read the whole description to learn the full scope.

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?

Nearly every mode is gated on an explicit trigger: call with `path` when the user names a folder, use `path="share"` when the user asks other PCs to connect, use `path=<the code>` when any Graph-MIND code is pasted, and 'Set it only when the user has explicitly agreed' for share_existing. It also names the alternative (brain_checkpoint) and pre-empts a question ('never ask the user which kind it is').

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

Deploy Server