Skip to main content
Glama

hjarni

by com.hjarni
OverviewDiscussionsAdmin

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), 'keep_summary' (id, lock_version: clears summary_stale and leaves the summary as it is; a lock_version that is no longer current answers status 'stale'), '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

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); keep_summary: the version the person read
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. Changed2 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "get",
-  "search",
-  "browse",
-  "preview",
-  "save",
-  "toggle",
-  "create_note",
-  "create_folder",
-  "update_folder",
-  "instructions",
-  "folder_options",
-  "move",
-  "trash",
-  "restore",
-  "favorite",
-  "archive",
-  "history",
-  "revert",
-  "verify",
-  "file_description",
-  "save_to_personal",
-  "purge",
-  "folder_archive",
-  "folder_delete",
-  "folder_restore",
-  "folder_purge",
-  "folder_move",
-  "folder_reorder",
-  "folder_parents",
-  "tag",
-  "share",
-  "bulk"
-]New value: +[
+  "get",
+  "search",
+  "browse",
+  "preview",
+  "save",
+  "toggle",
+  "create_note",
+  "create_folder",
+  "update_folder",
+  "instructions",
+  "folder_options",
+  "move",
+  "trash",
+  "restore",
+  "favorite",
+  "archive",
+  "history",
+  "revert",
+  "verify",
+  "keep_summary",
+  "file_description",
+  "save_to_personal",
+  "purge",
+  "folder_archive",
+  "folder_delete",
+  "folder_restore",
+  "folder_purge",
+  "folder_move",
+  "folder_reorder",
+  "folder_parents",
+  "tag",
+  "share",
+  "bulk"
+]
    • changedInput schema / properties / lock_version / description
      Previous value: -"save: the lock_version the edit started from (required for save)"New value: +"save: the lock_version the edit started from (required for save); keep_summary: the version the person read"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint, non-idempotent), the description discloses rich behavioral detail: lock_version conflict semantics with status 'conflict' and hunk-level merge resolution, 'unchanged'/'stale' status answers, the fact that purge is delete-for-good, that add_tags never conflicts, and that save requires lock_version. These are exactly the behaviors annotations cannot convey.

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 two opening sentences are well front-loaded and high-value, but the action inventory is a single densely packed run-on with 30+ semicolon-separated clauses that is hard to scan. The content is largely necessary, yet the structure could have been grouped or tabulated for readability.

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 33 parameters, 33 actions and no output schema, the description covers the full action surface plus conflict/status semantics and the destructive purge behavior. Nothing essential for correct invocation appears to be missing.

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, but the description adds per-action semantic outcomes not in the schema (e.g., known_lock_version yields 'unchanged', a stale lock_version 'saves nothing', resolve/merge_hunks applies per-hunk choices). It maps actions to parameters, though much of that mapping is already duplicated in the schema text.

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 states a specific verb set (reload, preview, save) and the exact resource/consumer (the note shown in the Hjarni note panel UI), and explicitly distinguishes itself from the sibling tools an assistant should use instead (notes-get, notes-update). An agent can tell immediately what this tool is and is not for.

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 when-not-to-use directive ('Assistants should not call this') and names the correct alternatives (notes-get, notes-update), then enumerates every action with its triggering parameters. Nothing about routing or invocation conditions is left to inference.

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

All hjarni toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources