Skip to main content
Glama
tan-yong-sheng

TriliumNext Notes' MCP Server

update_note

Modify existing notes in TriliumNext by updating titles, replacing or appending content, or changing files while maintaining data integrity and preventing conflicts.

Instructions

Update note with support for title-only updates, content overwrite, content append, or file replacement. ⚠️ REQUIRED: ALWAYS call get_note first to obtain current hash. ⚠️ SIMPLER RULES: Note type and MIME type are IMMUTABLE - cannot be changed after creation. MODE SELECTION: Use 'append' when user wants to add/insert content (e.g., 'append to note', 'add to the end', 'insert content', 'add more content', 'continue writing', 'add to bottom'). Use 'overwrite' when replacing entire content (e.g., 'replace content', 'overwrite note', 'update the whole note', 'completely replace'). TITLE-ONLY: Efficient title changes without content modification. FILE UPDATES: Replace file content only with SAME file type (image→image, file→file). To change file types, create a new note instead. PREVENTS: Type mismatches, file type conflicts, and overwriting changes made by other users. ONLY use when user explicitly requests note update. WORKFLOW: get_note → review content → update_note with returned hash

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteIdYesID of the note to update
titleNoNew title for the note. If provided alone (without content), performs efficient title-only update without affecting note content or blobId.
contentNoContent of the note. Content requirements by note type: TEXT notes require HTML content (plain text auto-wrapped in <p> tags, e.g., '<p>Hello world</p>', '<strong>bold</strong>'); CODE/MERMAID notes require plain text ONLY (HTML tags rejected, e.g., 'def fibonacci(n):'); ⚠️ SYSTEM NOTES MUST REMAIN EMPTY: RENDER (HTML handled by note type), SEARCH (queries in search properties), RELATION_MAP (visual maps), NOTE_MAP (visual hierarchies), BOOK (container notes), WEBVIEW (use #webViewSrc label); IMPORTANT: When updating notes with template relations (Board, Calendar, Grid View, List View, Table, Geo Map), the note must remain EMPTY - these templates provide specialized layouts and content should be added as child notes instead.
fileUriNoFile data source for file/image note updates. Replaces the existing file content with new file data. ⚠️ FILE TYPE MUST MATCH: The new file must have the same type as the current note (image files for image notes, other files for file notes). Supports: 1) Local file path: '/path/to/new_document.pdf', 2) Base64 data URI: 'data:application/pdf;base64,JVBERi0xLjcK...', 3) Raw base64 string. To change file types, create a new note instead.
expectedHashYes⚠️ REQUIRED: Blob ID (content hash) from get_note response. This is Trilium's built-in content identifier that ensures data integrity by verifying the note hasn't been modified since you retrieved it. If you see an error about missing blobId, you MUST call get_note first to get the current blobId.
revisionNoWhether to create a revision before updating (default: true for safety, title-only updates skip revision for efficiency)
modeNoContent update mode. REQUIRED when updating content for text/code notes, optional for file-only updates. CRITICAL: Choose based on user intent: 'append' = add/insert content while preserving existing content (use for 'add to', 'append', 'insert', 'add more', 'continue writing'); 'overwrite' = completely replace all existing content (use for 'replace', 'overwrite', 'update all', 'completely replace'). Default behavior is not available - you MUST explicitly choose when updating content.
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers comprehensive behavioral disclosure. It explains immutability constraints (note type and MIME type), concurrency protection (expectedHash prevents overwriting other users' changes), mode selection logic, file type matching requirements, revision behavior, and workflow prerequisites. No contradictions exist since annotations are absent.

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 appropriately front-loaded with core functionality and warnings, but it's lengthy due to necessary detail for a complex tool. Every sentence earns its place by providing critical guidance (e.g., mode selection rules, immutability constraints, workflow steps). Some redundancy exists (e.g., multiple warnings about get_note), but overall structure supports clarity.

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?

For a complex mutation tool with 7 parameters, no annotations, and no output schema, the description provides exceptional completeness. It covers prerequisites (get_note), constraints (immutable types, file matching), behavioral nuances (revision defaults, mode selection), error prevention (hash verification), and alternatives (create_note for type changes). No significant gaps remain given the context.

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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter interactions and semantics: it clarifies when to use title-only updates, distinguishes between append/overwrite modes with user intent examples, explains fileUri constraints, and emphasizes the critical role of expectedHash. However, it doesn't fully detail all 7 parameters' nuances beyond what the schema already covers well.

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 clearly states the verb 'update' with the resource 'note' and specifies multiple update types (title-only, content overwrite, content append, file replacement). It distinguishes from siblings by focusing on updates rather than creation (create_note), deletion (delete_note), or retrieval (get_note).

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?

Explicit guidance is provided on when to use this tool vs alternatives: 'ALWAYS call get_note first to obtain current hash', 'To change file types, create a new note instead', 'ONLY use when user explicitly requests note update'. It also distinguishes from sibling tools by outlining a specific workflow (get_note → review content → update_note).

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/tan-yong-sheng/triliumnext-mcp'

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