Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Move Note

vault_move_note
Destructive

Move or rename a note while automatically rewriting incoming wikilinks, markdown links, embeds, properties, and Canvas cards, plus the note's relative links, so the vault's link graph stays intact.

Instructions

Move or rename a note and rewrite every link across the vault that points to it, like Obsidian's built-in rename. Incoming links in other notes — [[wikilinks]], [[wikilink|aliases]], [[wikilink#headings]], ![[embeds]], markdown, and links in properties (e.g. related:) — and Canvas cards that embed the note are updated to the new path; the moved note's own relative links are fixed so they still resolve from the new folder, including relative links to attachments (e.g. ![[../assets/photo.png]]). A link is only rewritten when leaving it unchanged would break it, so a short [[Note]] that stays unambiguous after a folder move is left alone.

Example: vault_move_note({ old_path: "Inbox/Draft.md", new_path: "Inbox/Spec.md" }) — pure rename. Example: vault_move_note({ old_path: "Inbox/spec.md", new_path: "Inbox/Spec.md" }) — case-only rename; works even where the filesystem treats both spellings as one file. Example: vault_move_note({ old_path: "Inbox/Spec.md", new_path: "Projects/Spec.md" }) — move to another folder. Example: vault_move_note({ old_path: "Inbox/Spec.md", new_path: "Projects/Spec.md", prune_empty_folders: true }) — also remove "Inbox" if the move empties it.

When to use: Renaming a note or relocating it to a different folder while keeping the link graph intact. Prefer this over vault_write_note + vault_delete_note, which would orphan every backlink. To only change a note's body or properties, use vault_patch_note or vault_update_properties. Protected paths can be neither moved nor moved into: About Me/ and the daily notes folder (Daily Notes/ by default; vault_get_daily_note's path shows the folder in use; not protected when Obsidian's Daily Notes folder setting is the vault root or blank).

Parameters:

  • prune_empty_folders keeps a folder that holds any file, even a hidden .DS_Store. An in-place rename or a move into a subfolder of the source prunes nothing. Pruning is best-effort: a folder that can't be removed never fails the call.

Errors:

  • "destination exists: …" — this tool never overwrites; pick a free new_path or delete the existing note first.

  • "note not found: …" — old_path does not exist; verify path with vault_list_notes.

  • "source and destination are the same path" — nothing to move; pass a different new_path.

  • "cannot move protected path …" / "cannot move into protected path …" — old_path or new_path sits under a protected folder; pick a new_path outside it, or leave a protected note where it is.

  • "cannot read daily notes config from .obsidian/daily-notes.json" — the file that names the protected daily notes folder can't be parsed; ask the vault's owner to repair it, or the server's operator to set DAILY_NOTES_FOLDER or PROTECTED_PATHS, then retry.

  • "path must end in …" — add the .md extension.

  • "absolute path blocked" / "path traversal blocked" / "hidden path blocked" — use vault-relative paths with no hidden (dot-prefixed) file or folder in them.

  • "concurrent write in progress" — a write is in flight; retry the move.

  • "backlink set did not stabilize" — the notes linking to the note kept changing while the move prepared; nothing was written; retry the move.

  • "move aborted: could not read …" — names the note, or a note linking to it, that could not be read; nothing was written. Fix that note, then retry.

  • "move aborted: could not rewrite …" — says why a note could not be saved with its links rewritten, and how to fix it; nothing was written.

  • "move aborted: could not write to …" / "move aborted: could not rename to …" (a case-only rename) — new_path could not be created, and new parent folders it needed may remain; retry once, then ask the vault's owner to fix the folder or disk.

  • "move incomplete: …" — the move failed partway; no data is lost, and the message names what failed, the state it left, and the step that finishes the move.

  • "ENAMETOOLONG: …" or another filesystem error — the message says what to do; nothing was written.

  • "[SqliteError]: …" — the search index failed and nothing was written; the message says what to do.

Obsidian syntax: Link rewrites preserve each link's existing form — embed marker (!), heading anchor (#…), and alias (|…) are kept; a markdown link keeps its original extension and link text.

Returns: JSON with moved_to (the new path), links_updated (count of link occurrences rewritten, including the moved note's own relative links), updated_notes (sorted paths of the other notes and Canvas files that were edited; the moved note is implied by moved_to), and pruned_empty_folders (count of empty parent folders removed).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "old_path": "<old_path>",
      "new_path": "<new_path>"
    },
    "name": "vault_move_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
new_pathYesDestination vault-relative path (e.g. "Projects/Spec.md"). Must end in .md; parent folders are created as needed. Use the exact letter case of existing folders; a different case can create a second folder.
old_pathYesCurrent vault-relative path of the note to move (e.g. "Inbox/Draft.md"). Must end in .md. Use the exact letter case.
prune_empty_foldersNoWhen true, also remove parent folders of old_path that the move leaves empty. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.55.4
    • changedInput schema / properties / new_path / description
      Previous value: -"Destination vault-relative path (e.g. \"Projects/Spec.md\"). Must end in .md and must not already exist; parent folders are created as needed. Use the exact letter case of existing folders; a different case can create a second folder."New value: +"Destination vault-relative path (e.g. \"Projects/Spec.md\"). Must end in .md; parent folders are created as needed. Use the exact letter case of existing folders; a different case can create a second folder."
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed3 schema fields changedv0.54.7
    • changedInput schema / properties / new_path / description
      Previous value: -"Destination vault-relative path (e.g. \"Projects/Spec.md\"). Must end in .md and must not already exist; parent folders are created as needed."New value: +"Destination vault-relative path (e.g. \"Projects/Spec.md\"). Must end in .md and must not already exist; parent folders are created as needed. Use the exact letter case of existing folders; a different case can create a second folder."
    • changedInput schema / properties / old_path / description
      Previous value: -"Current vault-relative path of the note to move (e.g. \"Inbox/Draft.md\"). Must end in .md."New value: +"Current vault-relative path of the note to move (e.g. \"Inbox/Draft.md\"). Must end in .md. Use the exact letter case."
    • changedInput schema / properties / prune_empty_folders / description
      Previous value: -"When true, remove the source folder(s) if the move leaves them empty, walking up to (but never including) the vault root. Default false matches Obsidian, which leaves empty folders in place. Only removes a folder with zero entries — an in-place rename or a move into a subfolder of the source leaves it non-empty and prunes nothing."New value: +"When true, also remove parent folders of old_path that the move leaves empty. Default false."
  4. Addedv0.32.1
  5. Removedv0.32.0
  6. Changed1 schema field changedv0.20.2
    • addedInput schema / properties / prune_empty_folders
      Added value: +{
      +  "default": false,
      +  "description": "When true, remove the source folder(s) if the move leaves them empty, walking up to (but never including) the vault root. Default false matches Obsidian, which leaves empty folders in place. Only removes a folder with zero entries — an in-place rename or a move into a subfolder of the source leaves it non-empty and prunes nothing.",
      +  "type": "boolean"
      +}
  7. Addedv0.20.0

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description adds substantial operational context: it never overwrites, rewrites preserve embed markers/anchors/aliases, links are only touched when leaving them would break, pruning is best-effort and skipped for hidden files and in-place renames, and most error paths guarantee nothing was written. The one real gap is preconditions such as concurrency/locking beyond the 'concurrent write in progress' error, and it does not say whether a partial 'move incomplete' can be safely re-run.

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?

Front-loaded with purpose and side effects, then usage, then parameters, then errors — a logical order. It is long, and the ~15-item error catalogue plus four examples push well past what most calls need, though each entry is actionable rather than filler.

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 destructive, side-effect-heavy mutation with no output schema, the description covers semantics, alternatives, protections, return shape (moved_to, links_updated, updated_notes, pruned_empty_folders), and recovery for every failure mode. An agent has everything needed to call it and to interpret the result.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: prune_empty_folders retains folders holding any file including a hidden .DS_Store, prunes nothing for in-place renames or moves into a subfolder of the source, and is best-effort and never fails the call. The four worked examples also disambiguate old_path/new_path pairings, notably case-only rename.

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 gives a specific verb pair and resource — 'Move or rename a note and rewrite every link across the vault' — and immediately scopes the side effects (incoming links, embeds, canvas cards, the note's own relative links). It is unambiguously distinguishable from siblings like vault_write_note, vault_patch_note, and vault_delete_note, which are named later.

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?

An explicit 'When to use' sentence states the scenario, followed by a 'Prefer this over vault_write_note + vault_delete_note, which would orphan every backlink' comparison, plus routing for body/property edits to vault_patch_note and vault_update_properties. Protected-path exclusions are spelled out with the default folder and how to discover the configured one.

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