Skip to main content
Glama

Note panel actions

notes-panel
Destructive

Used only by the Hjarni note panel UI to reload, preview and save the note it shows. Assistants should not call this: read with notes-get and edit with notes-update. Actions: 'get' (id; known_lock_version answers status 'unchanged' when the note has not moved), 'search' (query: the panel's note picker, with a short preview per note; with id, only the notes that note can link to), 'browse' (place: one level of the folder tree, its folders and notes), 'preview' (id, body: renders Markdown without saving), 'save' (id, lock_version, title and/or body and/or add_tags/remove_tags; a lock_version that is no longer current saves nothing and answers status 'conflict' with the saved version and a line diff; resolve 'merge_hunks' with hunks {index: 'saved'|'draft'} applies a per-hunk choice), 'create_note' (place, title, body, add_tags), 'create_folder' (place, name), 'update_folder' (place folder:; name, description, llm_instructions, negative_space), 'instructions' (place personal: brain, personal; place team:: team), 'folder_options' (id: where that note can move), 'move' (id, place), 'trash' (id), 'restore' (id), 'favorite' (id, favorited), 'archive' (id, archived), 'history' (id; with seq, that version and its changes), 'revert' (id, seq, lock_version), 'verify' (id), 'file_description' (id, file_id, description), 'save_to_personal' (id of a team note), 'purge' (id of a trashed note: delete for good), 'folder_archive' (place folder:, archived), 'folder_delete' (place), 'folder_restore' (id), 'folder_purge' (id), 'folder_parents' (place), 'folder_move' (place, to), 'folder_reorder' (place, direction up|down), 'tag' (place tag:, op rename|merge|delete, name), 'share' (id, or place folder:; op status|enable|disable|editing_on|editing_off), 'bulk' (ids, op move|archive|unarchive|trash, place for move), 'toggle' (id, lock_version, index, checked: ticks one task checkbox; a lock_version that is no longer current ticks nothing and answers status 'stale' with the saved version).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNote ID (required for get, preview and save)
opNotag: rename|merge|delete; share: status|enable|disable|editing_on|editing_off; bulk: move|archive|unarchive|trash
toNofolder_move: the new parent: personal, team:<id> or folder:<id>
idsNobulk: the notes
seqNohistory, revert: the version
bodyNosave: new body (full replacement); preview: Markdown to render
nameNocreate_folder, update_folder: folder name; tag: the new name, or the tag to merge into
sortNobrowse: note order
teamNoinstructions (place team:<id>): the team's instructions (owners only)
brainNoinstructions (place personal): instructions for everything
hunksNosave with resolve: hunk index => 'saved' or 'draft'
indexNotoggle: which task checkbox, counted from 0 in the note
placeNobrowse: spaces, personal, shared, team:<id> or folder:<id> (default spaces), also inbox, favorites, tags, tag:<id>, archived, trash; create_note, create_folder, move: where; update_folder: folder:<id>; instructions: personal or team:<id>
queryNosearch: text to find; empty lists recently edited notes
spaceNosearch: only personal, shared or team:<id>
titleNosave: new title
actionYesWhat to do (required)
checkedNotoggle: the box's new state
file_idNofile_description: the file
resolveNosave: apply per-hunk choices from a conflict
summaryNosave: new summary
add_tagsNosave: tags to add (applied to the saved tags, never a conflict)
archivedNoarchive: archive (true) or unarchive (false)
personalNoinstructions (place personal): instructions for Personal
directionNofolder_reorder
favoritedNofavorite: the star's new state
source_urlNosave: new source URL
descriptionNoupdate_folder: what the folder is for; file_description: the file's description
remove_tagsNosave: tags to remove
lock_versionNosave: the lock_version the edit started from (required for save)
negative_spaceNoupdate_folder: what does not belong in the folder
llm_instructionsNoupdate_folder: the folder's AI instructions
known_lock_versionNoget: the lock_version the panel already shows

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only mark it as destructive/non-idempotent; the description adds real behavioral detail beyond them: optimistic-locking semantics for 'get', 'save' and 'toggle' (unchanged/stale/conflict statuses), the fact that a stale lock_version 'saves nothing', the line-diff and merge_hunks conflict resolution path, and that 'purge' deletes for good. This is exactly the concurrency and irreversibility context an agent needs for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical routing warning is correctly front-loaded in the first two sentences, but everything after is one dense, unbroken block enumerating 32 actions with no line breaks or hierarchy. For a mega-tool some enumeration is warranted, yet the format makes scanning for a single action costly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 33-parameter dispatcher with no output schema and destructive annotations, the description supplies the key missing pieces: the action inventory, parameter-to-action mapping, and concurrency/conflict behavior. What it does not describe is what most actions return, which is a real but secondary gap given the size of the surface.

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 baseline is 3. The description nonetheless adds per-action grouping (which params belong to which action) and a non-obvious cross-parameter rule not present in the schema: 'search' with an id returns only the notes that note can link to. It stops short of documenting return shapes or the remaining per-action combinations, so it is above baseline but not exhaustive.

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 opening sentence states exactly what the tool is and who it is for ('Used only by the Hjarni note panel UI to reload, preview and save the note it shows'), and it names the sibling tools an assistant should use instead (notes-get, notes-update). An agent can distinguish this from every other notes-* sibling without opening a schema.

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 an explicit negative rule ('Assistants should not call this') plus concrete alternatives for the two use cases an agent would otherwise pick this for (read via notes-get, edit via notes-update). This is the strongest form of routing guidance.

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.