Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

Replace Span

vault_replace_span
Destructive

Replace a block of whole lines in an Obsidian note using short start/end anchors, avoiding error-prone full-text reproduction for table rows, callouts, or list runs.

Instructions

Replace a contiguous block of whole lines in a note's body with new content, identified by short anchor substrings instead of the block's full text. Each anchor locates a full line — the entire line is selected, not just the matching substring. Same anchor semantics as vault_delete_span. Case-sensitive matching. Properties are preserved; YAML formatting may be normalized to block style on first edit. Operates on the body only.

Example: vault_replace_span({ path: "Tracker.md", start_anchor: "| 2024-03-02 | Acme", content: "| 2024-03-02 | Acme Corp | Updated |" }) — replaces the one table row whose line contains that fragment. Example: vault_replace_span({ path: "Notes/Plan.md", start_anchor: "> [!warning] Stale", end_anchor: "remove after launch", content: "> [!info] Current\n> Updated for v2." }) — replaces the callout block with a new one.

When to use: Replacing 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 text changes (typos, renaming). Prefer vault_delete_span when removing without replacement.

Parameters:

  • start_anchor + end_anchor define a line range, not a text range — each anchor locates a full line, and the entire line from start to end is replaced (never cuts mid-line). Omit end_anchor for a single-line replace.

  • 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 replaced.

  • content replaces the entire matched span and must be non-empty. A trailing newline adds a blank line after the new block.

  • 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 replacement are collapsed to a single blank line.

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

  • "absolute path blocked" — the path starts at the filesystem 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 editable, matching Obsidian

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

  • "content contains a control character" — content includes a non-printable control byte; remove it before writing

Obsidian syntax: content is Obsidian Flavored Markdown (no escaping applied). Watch for: #word = tag, [[ = wikilink, %% = comment block.

Returns: Confirmation message "Replaced lines with lines in " — N counts the lines the span covered, M the lines content supplied.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesVault-relative path to the note, including the ".md" extension (e.g. "Tracker.md", "Notes/Plan.md")
contentYesReplacement content (one or more lines) — replaces every line of the matched span. Must be non-empty; use vault_delete_span to delete without replacement.
end_anchorNoShort, unique substring that identifies the LAST line of the block, searched at or after the start_anchor line. The entire line is selected. Omit to replace just the single line containing start_anchor.
first_matchNoIf an anchor matches more than one line, use the first match instead of erroring (default: false — ambiguity is an error).
start_anchorYesShort, unique substring that identifies the first line of the block (case-sensitive). The entire line is selected, not just the substring. Pick a brief fragment — do not paste the whole block.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.50.0
    • addedInput schema / properties / first_match / default
      Added value: +false
  2. Addedv0.41.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover the safety profile (destructiveHint=true, readOnlyHint=false), and the description adds substantial context beyond them: line-granular (never mid-line) replacement, property preservation with YAML normalization to block style, blank-line collapse, concurrency retry behavior, hidden/absolute path blocking, and control-character rejection. It also documents the return confirmation string.

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, then worked examples, usage routing, parameter behavior, errors, and syntax warnings in a scannable order. It is on the long side — the error catalogue and Obsidian syntax note could be trimmed — but nearly every line carries actionable information for a destructive, anchor-based edit.

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 5-parameter destructive mutation with no output schema, the description covers trigger conditions, anchor semantics, edge cases, failure modes and their remedies, escaping hazards, and the exact return string. An agent has everything needed to call it correctly and recover from errors.

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 coverage is 100%, so baseline is 3, but the description adds cross-parameter semantics the schema cannot express: end_anchor is searched at or after the start line (span cannot run backward), same-line matches collapse to one line, first_match applies independently to each anchor, and a trailing newline in content adds a blank line. This is genuine added meaning, not restatement.

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?

Names a specific verb (replace) and resource (a contiguous span of whole lines in a note's body) and immediately differentiates its anchor-based identification scheme from full-text matching. It also names sibling alternatives (vault_replace_in_note, vault_delete_span), so an agent can place it precisely in the tool family.

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?

A dedicated 'When to use' section states the triggering condition (replacing a block you already read where reproducing old_text exactly would be error-prone) and explicitly routes to vault_replace_in_note for typo/rename edits and vault_delete_span for removal-without-replacement. Error entries add recovery guidance (verify with vault_read_note / vault_list_notes, retry on concurrent write).

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