Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Replace Span

vault_replace_span
Destructive

Replace a contiguous block of whole lines in an Obsidian note body by matching short start/end anchors, avoiding error-prone exact old-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. Properties are kept as written, and body line breaks are saved as LF. A repeated call can write the content again, or with first_match: true replace the next match, so after a timeout or lost response, re-read the note before retrying.

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. Prefer vault_replace_in_note for small in-place text changes (typos, renaming). Prefer vault_delete_span when removing without replacement.

Parameters:

  • An anchor matches a body line (any line below the properties block).

  • end_anchor is searched at or after the start line and must be unique among those lines. If start_anchor and end_anchor 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 (```): 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.

Behavior:

  • Each line break at content's start or end becomes an empty line on that side, so content ending in one ("| X |\n") leaves an empty line after it, which splits a table.

  • Where the note already has empty lines next to content's start or end, the wider run (the note's or content's) is kept, so blank lines never double. At the note's end, content's trailing line breaks count one fewer ("| X |\n" leaves no empty line).

  • Empty lines inside content are kept as written, and a line holding only spaces or tabs counts as text, not as an empty line.

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 body line holds the fragment; 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" — pass a vault-relative path with no dot-prefixed part

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

  • "content contains a control character" — remove the character the message names

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

  • "the note would open with a properties block …" — a note without properties would start with --- lines around text that can't be 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 line(s) with line(s) in " — N counts the lines the span covered, M the lines in content as sent (its line breaks plus one).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "start_anchor": "<start_anchor>",
      "content": "<content>"
    },
    "name": "vault_replace_span"
  }
}

Input 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).
end_anchorNoShort substring of the block's LAST line, a body line (case-sensitive). 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 of the block's first line, a body line (case-sensitive).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.55.4
    • changedInput schema / properties / content / description
      Previous value: -"Replacement content (one or more lines) — replaces every line of the matched span. Must be non-empty."New value: +"Replacement content (one or more lines)."
    • changedInput schema / properties / end_anchor / description
      Previous value: -"Short substring that identifies the LAST line of the block (case-sensitive). Omit to replace just the single line containing start_anchor."New value: +"Short substring of the block's LAST line, a body line (case-sensitive). Omit to replace just the single line containing start_anchor."
    • changedInput schema / properties / start_anchor / description
      Previous value: -"Short, unique substring that identifies the first line of the block (case-sensitive). Pick a brief fragment — do not paste the whole block."New value: +"Short, unique substring of the block's first line, a body line (case-sensitive)."
  2. Changed3 schema fields changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / end_anchor / description
      Previous 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."New value: +"Short substring that identifies the LAST line of the block (case-sensitive). Omit to replace just the single line containing start_anchor."
    • changedInput schema / properties / start_anchor / description
      Previous value: -"Short, 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."New value: +"Short, unique substring that identifies the first line of the block (case-sensitive). Pick a brief fragment — do not paste the whole block."
  3. 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."
  4. 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."
  5. Changed1 schema field changedv0.50.0
    • addedInput schema / properties / first_match / default
      Added value: +false
  6. Addedv0.41.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag the tool as destructive and non-idempotent, and the description adds substantial context beyond that: properties are preserved, body line endings are saved as LF, repeated calls rewrite content, and retries should begin with a re-read. It also documents line-break merging behavior and detailed error messages, giving the agent a clear operational picture.

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 long but well structured, with purpose up front, examples, usage guidance, parameter notes, behavior, errors, and return format. Most sentences earn their place, though the exhaustive error list and repeated parameter details make it longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description explains the confirmation return value and covers the major behavioral and error cases. It is nearly complete for a destructive anchor-based replacement tool, though an agent may still need to consult the note contents to choose unique anchors.

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?

Although schema coverage is 100%, the description adds meaning beyond the schema: anchors must match body lines, end_anchor is searched at or after start, matching the same line replaces only that line, and first_match controls ambiguity handling. It also explains how content line breaks affect blank lines around the replacement, which is not captured by the schema alone.

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 specific verb and resource: replacing a contiguous block of whole lines in a note body using anchor substrings rather than full old text. It explicitly distinguishes itself from vault_replace_in_note and vault_delete_span, so an agent can select it without opening sibling 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?

Provides an explicit "When to use" section, names the preferred alternatives for smaller text changes and deletions, and supplies concrete examples for table-row and callout replacement. It also explains when to avoid it, such as code blocks whose closing fence would be ambiguous.

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