Skip to main content
Glama

update_note

Update an existing note. Only the fields you pass are changed — omitted fields keep their current value, except labels, which is a full replace (see below). content, if passed, overwrites the whole body; use append_to_note instead if you only want to add text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
colorNoNote color
titleNo
labelsNoReplaces the full label list, not additive — omitting an existing label removes it. Use add_label/remove_label instead if you only want to change one label without touching the rest.
pinnedNoPin or unpin the note
contentNoNote body. Wrap copyable snippets/commands in a fenced code block (```lang ... ```) to render a one-click copy button. Checklist items MUST be written as "- [ ] text" (unchecked) or "- [x] text" (checked) — the space inside the brackets is required, e.g. "[] text" or "[]text" will NOT render as a checkbox and shows up as plain text instead. Nest an item under the one above it with two leading spaces per level, e.g. " - [ ] sub-item" (one level) or " - [ ] deeper" (two levels) — indentation must be a multiple of two spaces. Section headings are written as "## Heading" (1-3 #'s). Inline `code spans` (single backticks) and **bold** are supported inline within text. Links and other markdown are NOT supported — they render as literal characters, so don't use them.
archivedNoArchive or unarchive the note
reminderAtNoISO datetime for a due reminder, or null to clear it. Call get_settings first to get the user's IANA timezone and convert any spoken local time correctly — never guess. A past timestamp is clamped to now.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden. It discloses partial update semantics, label full-replace behavior, content overwrite, reminder clamping, exact markdown/checkbox formatting rules, and unsupported markdown — a very thorough transparency disclosure.

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 long, but every sentence carries useful information — no filler. Core behavior and alternatives are front-loaded, with detailed formatting rules placed under the content parameter where they belong. The length is justified by the complexity of content formatting requirements.

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 8 parameters and no annotations, the description is remarkably complete: it covers update semantics, label behavior, timezone handling, markdown syntax, and unsupported features. An agent has everything needed to call this tool correctly without further inference.

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 75%, so baseline is 3. The description adds value beyond schema: it clarifies the semantics of omitted fields, label replacement, and reminderAt timezone handling. It repeats some schema content (labels, content formatting) but also adds the important partial-update context that the schema doesn't convey.

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 'Update an existing note' — a clear verb+resource statement. It distinguishes itself from siblings by explicitly naming append_to_note for adding text and add_label/remove_label for single-label changes, so an agent can immediately tell what this tool is for and what it is not.

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?

Provides explicit when-to-use guidance: partial updates, full replace for labels, and direct alternatives ('use append_to_note instead...', 'Use add_label/remove_label instead...'). It also instructs calling get_settings first for timezone conversion on reminderAt — concrete prerequisites and routing to siblings.

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.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: note CRUD, checklist operations, label management, changelog entries, settings, and task queries. Descriptions explicitly differentiate between append vs. update, list vs. get, check vs. uncheck, and add vs. remove, so there is no ambiguity.

Naming Consistency5/5

All tool names follow a verb_noun snake_case pattern (e.g., add_label, get_note, check_item, update_note), with consistent verb choices. Even 'get_my_tasks' and 'uncheck_item' fit the pattern, so the naming is predictable and uniform.

Tool Count5/5

14 tools is well-scoped for a notes application with checklist, label, and changelog features. Each tool covers a distinct operation without redundancy or bloat, and the count sits comfortably within the ideal 3-15 range.

Completeness4/5

The tool set covers full CRUD for notes, plus checklist management (add, check, uncheck), label management (add/remove), changelog entries, settings retrieval, and task aggregation. Minor gaps like archive/unarchive and a dedicated label list are workable, so the surface is near-complete for the domain.

Resources