Skip to main content
Glama

Delete Span

vault_delete_span
Destructive

Delete a contiguous block of lines from a note by giving short anchor fragments for the start and end lines, avoiding the need to reproduce the full text. Preserves note properties.

Instructions

Delete a contiguous block of whole lines from a note's body by referencing short anchor substrings instead of reproducing the full block text. Case-sensitive matching. Properties are preserved; operates on the body only.

Example: vault_delete_span({ path: "Tracker.md", start_anchor: "| 2024-03-02 | Acme" }) — deletes the one table row whose line contains that fragment. Example: vault_delete_span({ path: "Notes/Plan.md", start_anchor: "> [!warning] Stale", end_anchor: "remove after launch" }) — deletes from the start anchor line through the end anchor line.

When to use: Removing a block you have already read — a table row, callout, or run of list items — where reproducing it exactly as old_text would be error-prone. Pick a short, unique fragment of the first line for start_anchor and, for a multi-line block, the last line for end_anchor. Prefer vault_replace_in_note for small in-place edits (this tool only deletes). To replace a block, delete it here, then vault_patch_note to add the new content.

Parameters:

  • start_anchor + end_anchor define a line range, not a text range — each anchor locates a full line, and entire lines are removed (never cuts mid-line). Omit end_anchor for a single-line delete.

  • end_anchor is searched at or after the start line, so the span can never run backward. If both match the same line, only that one line is deleted.

  • first_match applies to both anchors independently — when an anchor matches multiple lines, takes the first instead of erroring. Blank-line runs left by the deletion are collapsed automatically.

Errors:

  • "note not found" — verify path with vault_list_notes

  • "anchor not found" — fragment not on any line; verify with vault_read_note

  • "ambiguous start anchor …" / "ambiguous end anchor …" — the anchor matches multiple lines; use a longer fragment or set first_match: true

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

Returns: Confirmation with lines removed and a truncated preview of the deleted text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesVault-relative path to the note, including the ".md" extension (e.g. "Tracker.md", "Notes/Plan.md")
end_anchorNoShort, unique substring on the LAST line of the block, searched at or after the start_anchor line. Omit to delete just the single line containing start_anchor.
first_matchNoIf an anchor matches more than one line, delete using the first match instead of erroring (default: false — ambiguity is an error).
start_anchorYesShort, unique substring on the first line of the block to delete (case-sensitive). Pick a brief fragment — do not paste the whole block.
Behavior5/5

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

Annotations already declare destructiveHint=true, and description adds behavior: properties preserved, line-range operation, case-sensitive matching, blank-line collapse, and error handling. No contradiction.

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?

Well-structured with sections, examples, bullet points. Efficiently conveys all needed info without fluff. Front-loaded with main action.

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 tool with no output schema, description explains return value and common errors. Covers all aspects: usage, parameters, behavior, edge cases. Completely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters at 100%, but description adds rich context: examples, anchor usage rules, line-range behavior, first_match explanation, and error conditions. Adds significant value beyond schema.

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?

Description clearly states the tool deletes a contiguous block of whole lines using anchor substrings, and distinguishes itself from sibling tools like vault_replace_in_note for small edits and vault_patch_note for adding content.

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?

Explicitly tells when to use (removing a block already read where reproducing text is error-prone) and when not to (small in-place edits), and provides alternatives like vault_replace_in_note and vault_patch_note.

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