Skip to main content
Glama

Delete Note

vault_delete_note
Destructive

Permanently delete a markdown note from the vault, directly removing it from disk without trash or undo. Optionally prune empty parent folders after deletion.

Instructions

Permanently delete a markdown note — removed from disk directly (no trash, no undo). After deletion, links to it from other notes become broken (detectable via vault_get_backlinks). Protected paths (About Me/ and the daily notes folder (read from DAILY_NOTES_FOLDER or .obsidian/daily-notes.json, defaulting to Daily Notes/)) are refused.

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.

Behavior: With prune_empty_folders, pruning is best-effort and runs after the delete — it never fails the call, so the note is always removed even if a folder can't be removed.

Errors:

  • "cannot delete protected path" — the path sits under a protected folder; use vault_delete_memory for memory entries

  • "path traversal blocked" — path escapes the vault root; use a vault-relative path

  • "hidden path blocked" — the path targets a hidden (dot-prefixed) file or folder like ".obsidian/"; hidden paths are not deletable, matching Obsidian

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

  • "note not found: …" — the note does not exist; verify the path with vault_list_notes before deleting

Returns: Confirmation message, noting how many empty folders were pruned when any were.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesVault-relative path of the note to delete, including the ".md" extension
prune_empty_foldersNoWhen 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.
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

While annotations already declare destructiveHint=true, the description adds substantial behavioral context: no trash/undo, link breakage detectable via vault_get_backlinks, protected path refusal, best-effort folder pruning that never fails the delete, concurrent write errors, and hidden path blocking. This far exceeds what annotations alone convey.

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?

The description is long but tightly structured and front-loaded: key destructive behavior first, then examples, usage guidance, error handling, and return value. Every section earns its place, especially for a destructive tool where edge cases and failure modes are critical for safe invocation.

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?

The description covers invocation, examples, protected paths, error conditions with remedies, pruning semantics, and the return value. Given the destructive nature and lack of an output schema, this is a complete and well-rounded definition that leaves little ambiguity for an agent.

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% with strong descriptions for both parameters, so the baseline is 3. The description adds value beyond the schema through concrete invocation examples and clarifies that prune_empty_folders is best-effort and never causes the deletion to fail. This is useful extra meaning, though not dramatically more than the schema already provides.

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 opens with a specific verb and resource: 'Permanently delete a markdown note', and immediately clarifies the destructive scope (removed from disk, no trash, no undo). It also distinguishes itself from vault_delete_memory by noting that memory entries should go through that sibling tool instead.

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 'When to use' section explicitly states the intended use case and names the preferred sibling alternative (vault_delete_memory) for memory entries. The errors section also routes remediation, such as using vault_delete_memory for protected About Me paths and vault_list_notes to verify paths before deleting.

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

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