Skip to main content
Glama
Sign In
ara-5

second-brain

by ara-5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Save a memory

brain_remember

Save reusable facts, patterns, constraints, or decisions as notes in a shared vault so future sessions can recall them instead of re-deriving the same knowledge.

Instructions

Write a new memory/research note into the shared Second Brain vault so future sessions, in this or any other project, can recall it later. Only for a genuine, reusable learning: a fact, pattern, constraint or decision that would change future behavior or save someone from re-deriving it. Not for routine task completions, raw output or status updates (the task queue records those). Test: would a future session be worse off without this note? If not, skip it. Prefer updating an existing relevant note over creating a near-duplicate one (use brain_search first, then brain_node_update). Creates a new note and never overwrites an existing one (a title clash gets a numbered filename). Returns { success, id, title, type, version }; keep the id to refer to the note later.

Input Schema

NameRequiredDescriptionDefault
tagsNoShort lowercase labels, e.g. ["database", "cache"]. Used by search and filtering.
typeNoKind of note: decision (a choice and its reason), insight (a non-obvious finding or fix), research (gathered findings), memory (general fact), note (anything else).memory
agentNoName of the calling project or agent; the note is stored under agents/<agent>/, which keeps each project's notes together. Same filename rules as title, so no slashes. If omitted, the note is stored at the vault root and its agent is recorded as "unknown".
titleYesSpecific, searchable title that becomes the note's filename, e.g. "Decision - Use SQLite for the cache". Must not contain : / \ ? * " < > | , start or end with a space, or end with a period; invalid titles are rejected with the reason.
contentYesMarkdown body. Link related notes with [[Note Title]] so recall can follow the graph. Never include secrets, credentials or personal data: notes are plain files and may be synced to git.
importanceNoHow long the note stays prominent in recall, 1 to 10. Recency only re-ranks, so old notes are never hidden, but 8-10 fades over months, 5-7 (default) over weeks, and 1-4 within days.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-destructive, non-idempotent mutation; the description adds real value on top by confirming it never overwrites (title clashes get a numbered filename), disclosing the return shape { success, id, title, type, version }, and warning that notes are plain files that may be synced to git so secrets must be excluded. The only minor gap is that it does not mention any permission or auth requirement before writing.

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?

Purpose is front-loaded in the first sentence, then gating criteria, then the alternative-path instruction, then behavioral/return details. The length is justified by the amount of decision-relevant content and the "Test:" framing keeps the qualification crisp rather than rambling.

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?

A mutation tool with no output schema, yet the description compensates by stating the exact return fields and advising the agent to retain the id for later reference. Combined with the no-overwrite behavior, the duplicate-avoidance workflow, and the secrets warning, an agent has everything needed to call it correctly.

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 coverage is 100%, so tags, type, agent, title, content and importance are all fully documented in the schema already, which sets the baseline at 3. The description adds only marginal parameter meaning — that a title clash yields a numbered filename — and does not explain importance or type trade-offs beyond what the schema states.

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 a new memory/research note into the shared Second Brain vault") plus the downstream purpose (recall in future sessions or other projects). It distinguishes itself from siblings by naming brain_search and brain_node_update as the preferred path for existing notes.

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 explicit inclusion criteria (genuine reusable learning: fact, pattern, constraint, decision), explicit exclusions (routine task completions, raw output, status updates — pointing at the task queue), and a concrete self-test question. It also routes to alternatives: search first, then update an existing note rather than duplicating.

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

Deploy Server

Other Tools