Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

Replace Span

vault_replace_span
Destructive

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.

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. 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:

  • end_anchor is searched at or after the start line, so the span can never run backward; it must be unique among those lines. If both match the same line, only that one line is replaced. A span that includes a code block's opening fence can't end at a plain closing fence (```): every fragment of the closing fence also appears in the opening fence, so the end anchor is ambiguous, and first_match: true would end the span at the opening fence; to replace such a block, use vault_replace_in_note.

  • content: empty lines at its start and end join the empty lines around the replaced lines, and each joined gap keeps the larger of the two counts (only at the end of the note, the count above drops by one). So content can widen a gap but not narrow it: a trailing newline leaves at least one empty line after the new block unless the block ends the note. Content made only of empty lines joins both sides into one gap. Empty lines inside content are written as given, and no other empty line in the note changes. A line holding only spaces or tabs counts as text, not as an empty line.

  • first_match applies to both anchors independently.

Errors:

  • "note not found" — verify path with vault_list_notes

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

  • "start anchor not found" / "end anchor not found" — no line contains the fragment (for end_anchor, none at or after the start 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" / "path traversal blocked" / "hidden path blocked" — use a vault-relative path with no hidden (dot-prefixed) file or folder in it

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

  • "ENAMETOOLONG: …" — the path, or a name in it, is longer than the filesystem allows; check the path. If the quoted name ends in ".tmp", the note exists but its name is too long to save; rename it at least 41 bytes shorter

  • "EACCES: …" or another filesystem error code — the note's file can't be read or written (permissions, a full or read-only disk); ask the vault's owner to fix it

  • "properties block …" — the note's properties block can't be read, or a rewrite would lose it; the error says how to repair it

  • "the note would open with a properties block …" — the edit would leave --- lines at the top of a note with no properties, around text that can't be kept as properties; the error says how to avoid it

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 line breaks in content plus one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesVault-relative path to the note, including the ".md" extension (e.g. "Tracker.md", "Notes/Plan.md"). Use the exact letter case.
contentYesReplacement content (one or more lines) — replaces every line of the matched span. Must be non-empty.
end_anchorNoShort substring that identifies the LAST line of the block. 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. Changed2 schema fields changedv0.54.9
    • changedInput schema / properties / content / description
      Previous value: -"Replacement content (one or more lines) — replaces every line of the matched span. Must be non-empty; use vault_delete_span to delete without replacement."New value: +"Replacement content (one or more lines) — replaces every line of the matched span. Must be non-empty."
    • changedInput schema / properties / end_anchor / description
      Previous value: -"Short, 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."New value: +"Short substring that identifies the LAST line of the block. The entire line is selected. Omit to replace just the single line containing start_anchor."
  2. Changed1 schema field changedv0.54.7
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path to the note, including the \".md\" extension (e.g. \"Tracker.md\", \"Notes/Plan.md\")"New value: +"Vault-relative path to the note, including the \".md\" extension (e.g. \"Tracker.md\", \"Notes/Plan.md\"). Use the exact letter case."
  3. Changed1 schema field changedv0.50.0
    • addedInput schema / properties / first_match / default
      Added value: +false
  4. Addedv0.41.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive=true and idempotent=false, but the description goes well beyond them: properties are preserved and YAML may be normalized to block style, the edit operates on the body only, matching is case-sensitive, and the exact empty-line joining rules for content are spelled out. It also discloses failure modes (concurrent write, control characters, name-length limits) that annotations cannot express.

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, two concrete examples, when-to-use, then parameters/errors/returns — a logical order with clear demarcation. It is on the long side, particularly the exhaustive error enumeration, but nearly every sentence carries distinct operational value rather than restating structured fields.

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 anchor-based span replacement with no output schema, the description covers the entire call surface: anchor semantics and ambiguity, empty-line reconstruction, Obsidian Markdown hazards (tags, wikilinks, comments), the return string format, and a full error catalog with recovery steps.

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 already 100%, so the schema documents each parameter. The description still adds real meaning beyond it — end_anchor is searched at or after the start line and must be unique among those lines, first_match applies to both anchors independently, and content's empty-line behavior can widen but not narrow gaps.

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 precise verb+resource+mechanism: 'Replace a contiguous block of whole lines in a note's body ... identified by short anchor substrings instead of the block's full text.' It also names the alternatives (vault_replace_in_note, vault_delete_span), so an agent can distinguish it from siblings without reading schemas.

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?

Has an explicit 'When to use' clause naming the scenarios (already-read table row, callout, run of list items) plus two exclusions with their selecting conditions: 'Prefer vault_replace_in_note for small in-place text changes' and 'Prefer vault_delete_span when removing without replacement.' Nothing 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.