Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Delete Note

vault_delete_note
Destructive

Delete a markdown note from your Obsidian vault, moving it to .trash/ per your Deleted files setting or removing it permanently. Optionally prune folders left empty by the delete.

Instructions

Delete a markdown note, moving it to the vault's .trash/ folder or removing it for good as the vault's Obsidian "Deleted files" setting directs.

Example: vault_delete_note({ path: "Scratch/temp.md" }) Example: vault_delete_note({ path: "Archive/2024/old.md", prune_empty_folders: true }) — also remove "Archive/2024" (and "Archive") if deleting the note empties them.

When to use: Removing a note you no longer need. Prefer vault_delete_memory for removing individual dated entries from About Me/ memory files. To relocate a note, use vault_move_note instead. To replace a note's content, use vault_write_note with overwrite: true instead.

Behavior:

  • The "Deleted files" setting decides the outcome, which the caller can't choose or see in advance:

    • "Move to system trash" moves the note to .trash/. Notes this server moved there are deleted after its retention period (TRASH_RETENTION_DAYS: 30 days by default, never when set to none).

    • "Move to Obsidian trash" moves the note to .trash/ and keeps it forever.

    • "Permanently delete" removes the note for good.

  • Links to the note from other notes become broken; list them first with vault_get_backlinks. Protected paths are refused: 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. Pruning is best-effort: a folder that can't be removed never fails the call.

Errors:

  • "cannot delete protected path" — the path sits under a protected folder; use vault_delete_memory for a memory entry, or ask the vault's owner to delete the note in Obsidian

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

  • "absolute path blocked" / "path traversal blocked" / "hidden path blocked" — pass a vault-relative path with no dot-prefixed part

  • "concurrent write in progress" — another write to this note is in flight; retry

  • "note not found: …" — verify path with vault_list_notes

  • "cannot move to trash … — 100 collisions in .trash/" — .trash/ holds this name and 100 numbered copies; ask the vault's owner to clear old copies, then retry

  • "cannot move to trash …" without "100 collisions" — the note stays put; ask the vault's owner to fix .trash/ (e.g. a plain file blocks a needed folder), then retry

  • "cannot delete …" (other than a protected path) — the note stays put; ask the vault's owner to fix the cause (e.g. permissions), then retry

  • "ENAMETOOLONG: …" or another filesystem error — the message says what to do; the note stays put

  • "cannot read trash config from .obsidian/app.json" — ask the vault's owner to repair it, then retry

  • "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

Returns: Confirmation message naming the outcome — "Deleted " for permanent removal, "Moved to trash (<.trash/ path>)" when the note landed in .trash/. Notes how many empty folders were pruned when any were.

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": {
      "path": "<path>"
    },
    "name": "vault_delete_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesVault-relative path of the note to delete, including the ".md" extension. Use the exact letter case.
prune_empty_foldersNoWhen true, also remove parent folders the delete leaves empty. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed2 schema fields changedv0.54.7
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path of the note to delete, including the \".md\" extension"New value: +"Vault-relative path of the note to delete, including the \".md\" extension. Use the exact letter case."
    • changedInput schema / properties / prune_empty_folders / description
      Previous value: -"When true, remove the note's parent folder(s) if deleting it 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 — a folder still holding any file, including a hidden one like .DS_Store, is left alone."New value: +"When true, also remove parent folders the delete leaves empty. Default false."
  3. Changed1 schema field changedv0.23.10
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path of the note to delete"New value: +"Vault-relative path of the note to delete, including the \".md\" extension"
  4. Changed1 schema field changedv0.20.2
    • addedInput schema / properties / prune_empty_folders
      Added value: +{
      +  "default": false,
      +  "description": "When true, remove the note's parent folder(s) if deleting it 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 — a folder still holding any file, including a hidden one like .DS_Store, is left alone.",
      +  "type": "boolean"
      +}
  5. 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, so the description's job is to add context, and it does: the caller cannot choose or predict the trash outcome, retention (TRASH_RETENTION_DAYS default 30, never when none), broken backlinks, protected paths (About Me/, daily notes folder), and best-effort pruning. The dense error catalogue adds further operational detail. A minor deduction because the interplay of the three Deleted-files modes could be summarized more crisply, but the disclosure is well beyond annotation coverage.

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 the purpose, then Example, When to use, Behavior, Parameters, Errors, Returns — an agent can scan to what it needs. The error section is long, but each entry maps an actionable failure to a remedy; a few entries (concurrent write, ENAMETOOLONG) could be condensed but still earn their place.

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 a destructive tool with no output schema, the definition covers outcomes, permissions/protected paths, link side effects, parameter edge cases, return strings, and recovery paths for every listed error. An agent has everything needed to invoke it and 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 100%, so 3 is the baseline, but the description adds real semantics for prune_empty_folders: it preserves folders holding any file including hidden .DS_Store, and pruning is best-effort and never fails the call. That is behavior the schema does not convey.

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 resource ("Delete a markdown note") and immediately qualifies the outcome (trash vs. permanent) that is governed by the vault setting. It is clearly distinguishable from siblings such as vault_delete_memory, vault_move_note, and vault_write_note.

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?

Includes an explicit "When to use" line plus three named alternatives with the conditions that select them: memory entries go to vault_delete_memory, relocation to vault_move_note, content replacement to vault_write_note with overwrite: true. Nothing about tool selection 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.