Skip to main content
Glama

notes_update

DestructiveIdempotent

Update a note's fields by ID. Preserves omitted fields; an optional expected hash prevents overwriting concurrent edits.

Instructions

Update a note's fields by id (title, description, body, project, tags). Omitted fields are untouched; the slug and id stay stable. body replaces the WHOLE body, so pass expect_hash (notes_read returns it) to have the write refused rather than silently overwriting an edit that landed after you read the note -- and use notes_append when you only mean to add to it. Tags come in three flavors: tags replaces the whole set, while tags_add and tags_remove edit it in place; prefer add/remove, since a replace discards whatever another agent tagged in between and tags_remove is the only way to clear a tag at all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesnote id (ULID)
bodyNonew body, replacing the whole body (aliases: content, text)
tagsNotags, replacing all (a comma-separated string is also accepted); an empty list is read as absent and leaves the tags untouched -- to drop a tag use tags_remove
titleNonew title
projectNonew project slug ("" or "global" = global scope)
tags_addNotags to add, leaving the rest in place; a tag already on the note is not duplicated. Applied after tags.
descriptionNonew description
expect_hashNooptional precondition: the content_hash you last read for this item (memory_read/notes_read return it). The write is refused if the stored file has changed since -- another agent or the owner edited it -- so re-read and re-apply your change instead of overwriting theirs. Omit it to write unconditionally.
tags_removeNotags to drop, matched exactly; a tag the note does not carry is ignored. Applied last, so it also removes what tags/tags_add just set.
Behavior5/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral details: omitted fields are untouched, slug/id stay stable, body replaces the whole body, and tag operations apply in a specific order. It also explains the meaning of expect_hash and the empty-list trap for tags, going far beyond the annotation hints.

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?

The description is front-loaded with the core purpose, then expands into necessary caveats. Every sentence adds value: concurrency control, tag semantics, and ordering rules. Though long, the density of information justifies the length, with no redundant or filler phrases.

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?

With 9 parameters, no output schema, and complex tag/body semantics, the description covers all critical edge cases and alternatives. It explains the concurrency model, tag replacement risks, and clear strategies (expect_hash, notes_append, tags_remove). This is more than complete for an agent to invoke correctly.

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?

Despite 100% schema coverage, the description enriches parameter semantics substantially. It clarifies that body has aliases (content, text), tags accepts a comma-separated string, tags_add/tags_remove are applied in sequence relative to tags, and expect_hash acts as a concurrency guard. This guidance is not present in the schema.

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 precise verb and object: 'Update a note's fields by id (title, description, body, project, tags).' It clearly defines the tool's scope and differentiates from siblings like notes_append and notes_read, which are explicitly referenced for alternative operations.

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?

The description gives explicit usage guidance: when appending instead of replacing the body, use notes_append; for tags, prefer tags_add/tags_remove over replace to avoid clobbering other agents' changes. It also explains when to use expect_hash for concurrency safety, providing clear when-to and when-not-to scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0spoon/seamless'

If you have feedback or need assistance with the MCP directory API, please join our Discord server