Skip to main content
Glama

Patch Note

vault_patch_note
Destructive

Surgically edit markdown notes by appending, prepending, replacing, or inserting content under specific headings while preserving frontmatter.

Instructions

Surgical edits to a markdown note — append, prepend, replace, or insert content by heading. Frontmatter values are preserved; YAML formatting may be normalized to block style on first edit.

Example: vault_patch_note({ path: "TASKS.md", operation: "append", heading: "Active", content: "- [ ] New task" })

Cross-section move (e.g. completing a task on a board):

  1. vault_read_note to get current content and verify exact text

  2. vault_replace_in_note({ path, old_text: "- [ ] Task text", new_text: "" }) to remove from source (for a large multi-line block, prefer vault_delete_span)

  3. vault_patch_note({ path, operation: "append", heading: "Done", content: "- [x] Task text" }) to add at target

When to use: Modifying part of an existing note without overwriting the entire body. Prefer vault_write_note for creating new notes or full rewrites. Prefer vault_replace_in_note for in-place text changes (typos, renaming) that stay in the same location.

Operations:

  • append: add content at end of section (or end of file if no heading)

  • prepend: add content after heading line (or at the top of the body, below frontmatter, if no heading — how you add a leading callout)

  • replace: replace section body (heading preserved; requires heading)

  • insert_before: insert content above the heading line (requires heading)

Heading-targeted ops keep the matched heading and write content verbatim — don't begin content with the target heading (it's rejected to avoid a duplicate).

Section boundaries: a section spans from its heading to the next heading of the same or higher level (or EOF). Child headings are included in the parent section.

Editing a leading callout: read it via vault_read_note(outline: true), then vault_replace_in_note the old block for the new one (a no-heading prepend would stack a second callout above it).

Errors:

  • "note not found" — path does not exist; check vault_list_notes for valid paths

  • "heading not found" — no heading matches the text; error lists available headings

  • "ambiguous heading" — multiple headings match; use heading_level to disambiguate, or rename a heading if they share the same level

  • "operation requires a heading target" — replace and insert_before need a heading

  • "content begins with the heading … which would duplicate it" — content's first line repeats the target heading; omit it (the matched heading is kept automatically)

  • "concurrent write in progress" — another write to this note is in flight; re-read the note and retry

Obsidian syntax: Content is Obsidian Flavored Markdown (no escaping applied). Watch for: #word = tag, [[ = wikilink, %% = comment block. Inserting heading-level content (## New Section) changes the note's structure — future heading-targeted ops may resolve differently. Table rows: send only the data row ("| cell1 | cell2 |"), not the header or separator — duplicating them splits the table.

Returns: Confirmation message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesVault-relative path to the note, including the ".md" extension (e.g. "TASKS.md", "Projects/plan.md")
contentYesMarkdown content to insert. Must not begin with the target heading text (it would duplicate the heading, which is kept automatically).
headingNoTarget heading text (case-sensitive exact match). Required for replace and insert_before. Optional for append/prepend (omit for file-level operation).
operationYesappend | prepend | replace | insert_before. replace and insert_before require a heading; append and prepend work with or without one.
heading_levelNoHeading level (1-6) for disambiguation when multiple headings share the same text
Behavior5/5

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

Annotations set destructiveHint: true, which the description complements by detailing behavioral traits: frontmatter preservation, YAML normalization, section boundaries, error messages for various scenarios, Obsidian syntax caveats, and table row handling. No contradictions with annotations.

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 well-structured with an introductory sentence, example, operations section, error list, and syntax notes. It is appropriately sized for the tool's complexity, but could potentially be more concise by merging some details. However, every sentence serves a purpose and is front-loaded with key information.

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 the tool has 5 parameters, no output schema, and is destructive, the description thoroughly covers operations, parameters, common errors, Obsidian syntax, section boundaries, and usage patterns. It leaves no significant gaps for an AI agent to understand how to use it correctly.

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% (all 5 parameters described in schema). The description adds significant value: explains operation enum values ('append: add content at end of section...'), heading usage, heading_level for disambiguation, and content placement rules (e.g., 'Must not begin with the target heading text'). This exceeds the baseline of 3.

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 begins with a clear statement: 'Surgical edits to a markdown note — append, prepend, replace, or insert content by heading.' It specifies the verb (edit) and resource (markdown note) with precise operations, and distinguishes from sibling tools like vault_write_note and vault_replace_in_note in the 'When to use' section.

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?

The description explicitly states when to use this tool versus alternatives: 'Prefer vault_write_note for creating new notes or full rewrites. Prefer vault_replace_in_note for in-place text changes (typos, renaming) that stay in the same location.' It also provides a cross-section move example with step-by-step instructions, giving clear context for usage.

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/aliasunder/vault-cortex'

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