Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

Delete Memory Entry

vault_delete_memory
Destructive

Delete a single dated entry from an Obsidian memory file in About Me/ to remove a mistake or prune an expired entry from a living-policy file.

Instructions

Delete a single dated entry from a memory file in About Me/.

Example: vault_delete_memory({ file: "Opinions", section: "Tools and workflows (newest first)", date: "2026-05-01", entry: "Prefer X over Y" }) Example: vault_delete_memory({ file: "Routines", section: "Daily/weekly rhythm (newest first)", date: "2026-03-10", entry: "Gym Tue/Thu at 7am" }) — prune an expired entry from an entry-policy: living file

When to use: Removing an entry that was wrong when it was written — a mistake, a misattribution, or something never true. Memory files are append-only by default, so do NOT delete to reflect a change: append the new state via vault_update_memory instead (newest-first naturally supersedes). The exception is a file whose frontmatter declares entry-policy: living (check via vault_list_memory_files) — a current-state file where deleting an expired entry is the intended maintenance. Call vault_get_memory(file, section) first to see exact entry text for matching. Prefer vault_delete_note for deleting entire non-protected notes.

Parameters:

  • date + entry together pick the bullet line within the given section; identical copies make the match ambiguous.

  • section scopes the match — an identical entry under a different heading is not found.

Errors:

  • "memory file not found" — file does not exist in About Me/; call vault_list_memory_files to discover valid names.

  • "memory file must not start with a dot" / "memory file must be a bare name without path separators" / "memory file must be named without .md" — pass the file's bare name: no folder or slash, no leading dot, and no .md.

  • "date must be YYYY-MM-DD" — pass the entry's date exactly as the file shows it, zero-padded.

  • "section not found: …" — no H2 heading matches; the error lists the file's available sections

  • "no entry matching …" — no bullet matched the given date and entry text; verify exact text via vault_get_memory(file, section).

  • "ambiguous: N entries match …" — more than one identical bullet exists in the section. Remove the extra copy with vault_delete_span (pass first_match: true — identical lines make every anchor ambiguous) or a manual edit, then retry.

  • "refusing memory write: … would shrink content" — safety guard blocked a write that would remove more than half the file. Re-read with vault_get_memory to confirm current content; an entry that really is that large needs vault_delete_span or a manual edit.

  • "cannot read memory file …" — the file can't be read: check file against vault_list_memory_files (a name longer than the filesystem allows fails here); otherwise its permissions need the vault's owner

  • "ENAMETOOLONG: …", "EACCES: …" or another filesystem error code — the message says what to do

  • "memory file …: the note would open with a properties block …" — saving would turn the file's opening lines into a properties block the server can't keep; the error says how to avoid it

Returns: "Deleted entry from About Me/.md → ## ".

Input Schema

NameRequiredDescriptionDefault
dateYesISO YYYY-MM-DD date of the entry (e.g. "2026-05-01").
fileYesMemory file name without .md (e.g. "Principles"). Use the exact letter case.
entryYesExact entry text, without the "- **YYYY-MM-DD**: " prefix or bullet.
sectionYesH2 section heading containing the entry. Matched case-insensitively, with or without the "(newest first)" suffix.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.55.1
    • changedInput schema / properties / date / description
      Previous value: -"ISO YYYY-MM-DD date of the entry (e.g. \"2026-05-01\"). Must match the date shown by vault_get_memory."New value: +"ISO YYYY-MM-DD date of the entry (e.g. \"2026-05-01\")."
    • changedInput schema / properties / entry / description
      Previous value: -"Exact entry text as shown by vault_get_memory — without the \"- **YYYY-MM-DD**: \" prefix or bullet."New value: +"Exact entry text, without the \"- **YYYY-MM-DD**: \" prefix or bullet."
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changedv0.54.9
    • changedInput schema / properties / entry / description
      Previous value: -"Exact entry text as shown by vault_get_memory — without the \"- **YYYY-MM-DD**: \" prefix or bullet. Both date and entry must match for deletion."New value: +"Exact entry text as shown by vault_get_memory — without the \"- **YYYY-MM-DD**: \" prefix or bullet."
  4. Changed2 schema fields changedv0.54.7
    • addedInput schema / properties / entry / minLength
      Added value: +1
    • changedInput schema / properties / file / description
      Previous value: -"Memory file name without .md (e.g. \"Principles\")"New value: +"Memory file name without .md (e.g. \"Principles\"). Use the exact letter case."
  5. Changed2 schema fields changedv0.26.0
    • addedInput schema / properties / file / minLength
      Added value: +1
    • addedInput schema / properties / section / minLength
      Added value: +1
  6. Changed2 schema fields changedv0.23.5
    • changedInput schema / properties / date / description
      Previous value: -"ISO YYYY-MM-DD date of the entry"New value: +"ISO YYYY-MM-DD date of the entry (e.g. \"2026-05-01\"). Must match the date shown by vault_get_memory."
    • changedInput schema / properties / entry / description
      Previous value: -"Exact entry text (no date prefix or bullet)"New value: +"Exact entry text as shown by vault_get_memory — without the \"- **YYYY-MM-DD**: \" prefix or bullet. Both date and entry must match for deletion."
  7. Changed1 schema field changedv0.22.1
    • addedInput schema / properties / date / minLength
      Added value: +1
  8. Changed1 schema field changedv0.19.2
    • changedInput schema / properties / section / description
      Previous value: -"H2 section heading containing the entry"New value: +"H2 section heading containing the entry. Matched case-insensitively, with or without the \"(newest first)\" suffix."
  9. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructive annotation, the description discloses append-only default behavior, the living-file exception, ambiguity around identical entries, safety-guard shrink protection, and a detailed error catalog. It clearly explains failure modes and the expected return value.

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 front-loaded with a clear purpose sentence and examples, followed by structured usage, parameter, error, and return sections. It is somewhat long due to the error catalog, but that detail is justified for a destructive operation with tricky matching.

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 four-parameter memory-deletion tool with no output schema, the description covers purpose, prerequisites, alternatives, matching rules, error behavior, and return format. An agent should have everything needed to invoke it correctly or recover from failure.

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 the baseline is 3, but the description adds non-obvious matching semantics: date and entry jointly select a bullet, identical copies make the match ambiguous, and section scoping means the same entry under another heading is not found. It also clarifies file naming through error messages.

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 states a specific verb, resource, and scope: 'Delete a single dated entry from a memory file in About Me/'. It also explicitly distinguishes this operation from vault_update_memory, vault_delete_note, and vault_delete_span in context.

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?

It gives explicit 'When to use' guidance for removing entries that were wrong when written, warns not to delete merely to reflect a change, names vault_update_memory as the alternative, and carves out an entry-policy: living exception. It also tells the agent to call vault_get_memory first and to prefer vault_delete_note for entire notes.

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