Skip to main content
Glama

append_to_note

Append text to a note without resending its existing content. Ideal for journals, logs and running lists; simultaneous appends from two sessions are preserved, not overwritten.

Instructions

Add text to a note without resending the rest — prefer it over update_note for journals, logs and running lists. A blank line separates your text from what was there. The note is locked for the read-modify-write, so two sessions appending at the same moment keep both additions instead of the later one overwriting the earlier. Re-embeds in the background like any content change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "append_to_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
atNoWhere the text lands. Defaults to section_end when section is given, else note_end. note_end: the very end. note_start: above the first heading nested under the opening one — NOT offset 0, except on a note with no headings at all, where it is; on a note whose only heading is the opening one it falls to the end instead. before_section: above the section's own heading line. section_start: directly under that heading line, above the section's body. section_end: after the section and everything nested inside it. after_section: the same position as section_end. The four section-relative values require `section` and are refused without it.
idNoThe note's UUID. Alternative to title
titleNoAlternative to id; resolved like get_note
contentYesText to add. Trailing whitespace is trimmed and a blank line is inserted before it, so the addition never runs into the preceding paragraph
sectionNoTarget this section (heading text or slug) instead of the whole note. Valid values come from a search hit's `section`, get_note's `headings`, or a heading line in the note's own text — the slug form is only needed when two headings share a text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.3.1
    • changedInput schema / properties / at / description
      Previous value: -"Default section_end if section given, else note_end. note_start is after the H1/intro, before its first nested heading — not offset 0."New value: +"Where the text lands. Defaults to section_end when section is given, else note_end. note_end: the very end. note_start: above the first heading nested under the opening one — NOT offset 0, except on a note with no headings at all, where it is; on a note whose only heading is the opening one it falls to the end instead. before_section: above the section's own heading line. section_start: directly under that heading line, above the section's body. section_end: after the section and everything nested inside it. after_section: the same position as section_end. The four section-relative values require `section` and are refused without it."
    • addedInput schema / properties / content / description
      Added value: +"Text to add. Trailing whitespace is trimmed and a blank line is inserted before it, so the addition never runs into the preceding paragraph"
    • addedInput schema / properties / id / description
      Added value: +"The note's UUID. Alternative to title"
    • removedInput schema / properties / id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • changedInput schema / properties / section / description
      Previous value: -"Target this section (heading text or slug) instead of the whole note"New value: +"Target this section (heading text or slug) instead of the whole note. Valid values come from a search hit's `section`, get_note's `headings`, or a heading line in the note's own text — the slug form is only needed when two headings share a text"
  2. First observedv1.3.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the blank-line separator that gets inserted, the per-note lock during read-modify-write and the concurrency outcome (both appends survive), and background re-embedding. It leaves out return value and any permission/authorization requirements.

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?

Four sentences, front-loaded with the core distinction and preferred-use case, then concurrency and indexing behavior. No wasted framing or restatement of the tool name; each sentence delivers a distinct fact.

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

Completeness4/5

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

For a mutation tool with no annotations and no output schema, the description covers insertion semantics, concurrency, and side effects well. It stops short of saying what the call returns or whether the note must be unlocked/owned, which is the remaining gap an agent would want.

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%, including a detailed enum description for `at`, so the schema does the heavy lifting and baseline 3 applies. The description only adds the blank-line/trailing-whitespace behavior for `content`, which is already partly in the schema, and says nothing extra about `section` or `title` resolution 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 ('Add text to a note') plus the defining constraint ('without resending the rest'), and explicitly distinguishes itself from update_note. An agent can tell append apart from update_note or replace_in_note 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 Guidelines4/5

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

Names the alternative it beats and the scenarios that select it ('journals, logs and running lists'). It does not name replace_in_note, which is the other plausible sibling for modifying existing note text, nor state an explicit when-not-to-use condition.

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