Skip to main content
Glama

Update a note

brain_node_update
Destructive

Update an existing note in place to avoid near-duplicates: append text or replace the full body, and change tags or importance. Checks the note version and retries on concurrent edits.

Instructions

Update an existing note in place instead of creating a near-duplicate. mode "append" (default) adds your text to the end and keeps everything already there; mode "replace" overwrites the whole body, so only use it when you have the full corrected text (read it with brain_node_get first). Tags and importance, if given, replace the existing values. Safe against concurrent edits: it checks the note version and retries once if another writer changed it in between. Returns { success: true, id, mode } (mode is omitted when only tags or importance changed). Errors: "not found" for an unknown id, "Nothing to update" if you pass only an id, and a conflict error if two other writers keep racing; in that case read the note again and retry. No credentials are needed from you: if the server was started with BRAIN_KEY, this MCP server sends it automatically.

Input Schema

NameRequiredDescriptionDefault
idYesNote id exactly as returned by brain_search, brain_recall or brain_remember, e.g. "agents/my-project/Decision - Use SQLite".
modeNo"append" (default) keeps the existing text and adds yours at the end. "replace" overwrites the whole body: read the note first with brain_node_get.append
tagsNoThe note's new complete tag list; it replaces the old tags rather than adding to them.
contentNoIn append mode, the text to add after the existing body. In replace mode, the complete new body (it overwrites everything, so include whatever you want to keep). Omit to change only tags or importance.
importanceNoNew importance, 1 to 10 (see brain_remember).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.1

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations, which only flag destructive/non-idempotent/non-read-only. The description spells out exactly what gets destroyed in replace mode, that tags and importance overwrite rather than merge, the optimistic-concurrency check with a single automatic retry, the return shape, three named error conditions, and that no credentials are needed when BRAIN_KEY is set. Nothing here contradicts destructiveHint=true or idempotentHint=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 distinction (update in place vs. duplicate) and then ordered by decision-relevance: mode semantics, overwrite rules, concurrency, return value, errors. Dense but a few clauses, particularly the credentials sentence, could be trimmed without loss.

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 destructive 5-parameter mutation with no output schema, the description covers everything an agent needs: mode choice, overwrite/merge behavior, concurrency and retry, response shape, error taxonomy with recovery, and auth expectations. No meaningful gap remains for correct invocation.

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 100%, so the baseline is 3; the description adds real value by tying mode to content (append vs. full-body replace), clarifying that tags/importance replace rather than merge, and noting that passing only an id yields "Nothing to update". Most of the per-parameter meaning, however, is already carried by the schema descriptions, so it edges just above baseline rather than redefining semantics.

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?

"Update an existing note in place instead of creating a near-duplicate" states the verb, the resource, and the failure mode it exists to prevent, which cleanly separates it from the sibling brain_remember (create). It also names brain_node_get as the read counterpart, so the agent can place the tool in a workflow without opening a 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?

Explicit routing guidance: default append for adding text, replace only when you have the full corrected body and have read it with brain_node_get first. It also states the alternative (creating a near-duplicate is what this avoids) and the recovery path on conflict (read again and retry).

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