Skip to main content
Glama

Engram Obsidian Memory Sync

by io.github.engram-app
OverviewDiscussionsAdmin

Edit Note

edit_note
Destructive

Change part of an existing note. mode replace_text finds exact text and replaces it (first occurrence by default); mode replace_section replaces everything under one heading; mode insert_section adds content under a heading, at the start or end of that section, keeping what is there. Fails without writing if the text or heading is not found, or if expected_replacements does not match. To add text at the top or bottom of the note use append_to_note. To rewrite the whole note use write_note.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
findNoreplace_text only: exact text to find
modeYesreplace_text, replace_section or insert_section
pathYesPath of the note, e.g. "Projects/Alpha.md"
levelNoreplace_section and insert_section: heading level 1-6 (default 2)
contentNoreplace_section: new content for under the heading; insert_section: content to add
headingNoreplace_section and insert_section: heading text without the # prefix
replaceNoreplace_text only: text to put in its place
positionNoinsert_section only: start (directly under the heading) or end (default; after the section's last line, including its subsections)end
vault_idNoTarget vault: its name (e.g. "Engram") or its UUID. REQUIRED when you own more than one vault; the server keeps no active-vault state between calls, so it must be passed on every vault-scoped call. Omit only if you have a single vault. Call list_vaults if a name does not resolve.
occurrenceNoreplace_text only: 0 = first (default), 1 = second, -1 = all
expected_replacementsNoreplace_text only: fail without writing unless exactly this many are replaced

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
pathYes
headingNoreplace_section and insert_section: the heading edited; null for replace_text
replacementsNoreplace_text: occurrences replaced; null for the section modes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / content / description
      Previous value: -"replace_section only: new content for under the heading"New value: +"replace_section: new content for under the heading; insert_section: content to add"
    • changedInput schema / properties / heading / description
      Previous value: -"replace_section only: heading text without the # prefix"New value: +"replace_section and insert_section: heading text without the # prefix"
    • changedInput schema / properties / level / description
      Previous value: -"replace_section only: heading level 1-6 (default 2)"New value: +"replace_section and insert_section: heading level 1-6 (default 2)"
    • changedInput schema / properties / mode / description
      Previous value: -"replace_text or replace_section"New value: +"replace_text, replace_section or insert_section"
    • changedInput schema / properties / mode / enum
      Previous value: -[
-  "replace_text",
-  "replace_section"
-]New value: +[
+  "replace_text",
+  "replace_section",
+  "insert_section"
+]
    • addedInput schema / properties / position
      Added value: +{
+  "default": "end",
+  "description": "insert_section only: start (directly under the heading) or end (default; after the section's last line, including its subsections)",
+  "enum": [
+    "start",
+    "end"
+  ],
+  "type": "string"
+}
    • changedOutput schema / properties / heading / description
      Previous value: -"replace_section: heading updated"New value: +"replace_section and insert_section: the heading edited; null for replace_text"
    • changedOutput schema / properties / replacements / description
      Previous value: -"replace_text: occurrences replaced"New value: +"replace_text: occurrences replaced; null for the section modes"
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, and the description adds genuinely new behavioral detail: atomic failure with no write on missing text/heading or an expected_replacements mismatch. It does not mention permission or auth requirements, but the safety-critical transaction semantics are covered.

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?

Front-loads the core action, then mode semantics, then failure behavior, then sibling routing. Four sentences, no filler, and every clause carries either behavior or a routing decision.

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 an 11-parameter mutation tool, the description covers mode semantics, failure/atomicity, and alternatives, and an output schema exists so return values need not be explained. Vault scoping and level/position defaults are left to the schema, which is acceptable but means the description is not fully self-contained.

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, and the description goes beyond it by explaining mode-level semantics: replace_text takes the first occurrence by default, replace_section wipes everything under a heading, and insert_section preserves existing content while placing content at section start or end.

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?

States a specific verb and scope ('Change part of an existing note') and then enumerates the three modes with what each targets. It explicitly names the siblings append_to_note and write_note and the conditions that select them, so an agent can separate this tool from nearby note-writers 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?

Gives explicit when-to-use routing: append_to_note for top/bottom insertion, write_note for full rewrites, and the three modes here for targeted edits. Preconditions are also stated ('Fails without writing if the text or heading is not found').

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

All Engram Obsidian Memory Sync 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