Skip to main content
Glama

Update note

update_note

Change an existing entry: tick a todo off (done: true) or reopen it, rename it, add to or edit a note's text, add or remove tags, move it to a folder, pin it, mark it favorite, mark a card to come back to in drills, or mark it as reference material for its tags' behaviors. Only the fields you pass change. To edit a note, read_note it first: edits are find-and-replace pairs matched against the Markdown read_note showed, and text replaces the whole body. The text a note had before an edit is kept in its version history, where the user can restore it. Edits rebuild only the paragraphs, lists or tables they touch, so drawings and pictures elsewhere stay as they are; coloured highlights and text read as and and can be changed like any other text; an edit inside a part holding something Markdown cannot carry (a drawing) is refused, and so is replacing the whole text of a note that has one. append_text always works. An empty line the user left between paragraphs shows as a line holding only  , and an edit can remove it like any other text. Name the entry by id, or by its exact title; a vaguer name comes back as candidates to choose from rather than a guess.

Input Schema

NameRequiredDescriptionDefault
doneNoTodos: true ticks it off, false reopens it.
noteYesThe entry to change. Its id (from any other tool's output) or its exact title.
textNoMarkdown that replaces the note's whole body (not its title). Prefer edits for a change to part of it.
editsNoFind-and-replace pairs applied in order to the note's Markdown as read_note showed it. Each find must appear exactly once; replace may be empty to delete it.
titleNoA new title (for a todo, its text).
folderNoFolder path to move a note into (created if missing), or "/" for no folder.
pinnedNoPin to (or unpin from) the top of its lists.
add_tagsNoTag paths to add. Missing tags are created.
favoriteNoMark (or unmark) as favorite.
referenceNoMark (or unmark) as reference material the behaviors of its tags read.
append_textNoMarkdown to add at the end of a note.
needs_drillNoDrills: true when the user missed a card (it comes back), false when they got it.
remove_tagsNoTags to take off (the entry itself stays).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses version history retention and restoration, targeted paragraph/list/table rebuilding, preservation of drawings and pictures, special handling of coloured highlights, refusal conditions for edits involving drawings, and append_text's guaranteed behavior. This is unusually rich behavioral context for a mutation tool.

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?

The description is front-loaded with the action list and then moves into editing guidance, with no irrelevant sentences. It is dense and somewhat run-on, but the length is justified by a 13-parameter mutation tool with complex editing rules.

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?

Given the absence of an output schema and the complexity of editing Markdown-backed notes, the description supplies the critical behavioral details an agent needs: version history, refusal cases, append_text fallback, naming-by-title behavior, and targeted edit semantics. Annotations already cover safety hints, so no important gap remains.

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 schema already carries the baseline parameter descriptions. The description still adds meaningful semantics: only passed fields change, edits must match Markdown as read_note showed, text replaces the whole body and not the title, and naming by exact title yields candidates when ambiguous.

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?

The description opens with a specific verb and resource ('Change an existing entry') and enumerates the exact mutation categories supported: todos, titles, text, tags, folders, pinning, favorite, drills, and reference. It distinguishes this tool from siblings like read_note, restore_note, and trash_note by focusing entirely on updating an existing entry.

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?

It gives explicit operational routing: read_note first before editing, prefer edits for partial changes versus text for whole-body replacement, append_text always works, and how to name the entry by id or exact title. It also explains that a vaguer name returns candidates rather than guessing, which directly guides invocation behavior.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources