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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed5 schema fields changedv0.4.11
    • changedInput schema / properties / body / description
      Previous value: -"new body (aliases: content, text)"New value: +"new body, replacing the whole body (aliases: content, text)"
    • addedInput schema / properties / expect_hash
      Added value: +{
      +  "description": "optional 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.",
      +  "type": "string"
      +}
    • changedInput schema / properties / tags / description
      Previous value: -"tags, replacing all (a comma-separated string is also accepted); an empty list is read as absent and leaves the tags untouched"New value: +"tags, 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"
    • addedInput schema / properties / tags_add
      Added value: +{
      +  "description": "tags to add, leaving the rest in place; a tag already on the note is not duplicated. Applied after tags.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / tags_remove
      Added value: +{
      +  "description": "tags 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.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. First observedv0.1.0

TDQS

A5/5.0
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.

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