Move note

Move or rename a note inside the vault. Requires write permission — a readwrite API key, or an OAuth token carrying the readwrite scope.

Arguments: from_path, to_path (must not exist; parent directories are created), rewrite_links (default False) and the optional expected_hash precondition. The index follows the move, so backlinks keep working without rewriting source notes. Every refusal the server raises ends with one machine-readable MCP-REFUSAL {"code":…} line; an undeclared or mistyped argument is rejected by protocol validation before the tool runs and carries no such line.

expected_hash binds from_path's own bytes and nothing else: pass the content_hash a read returned, verbatim, and the move is refused with nothing written if that note changed since. It is compared at preflight, before the rename and before any rewrite; the rename then pins inode identity but does not compare the bytes again, so an in-place edit landing after that comparison is still moved. The backlink sources a rewrite_links=True move rewrites are not bound, because you never read them. Optional by default — omitted, the move proceeds — unless the deployment requires it, when an omitted hash is refused precondition_required. Codes: stale_precondition, concurrent_write, no_incumbent, malformed_precondition, precondition_unavailable, precondition_required.

With rewrite_links=True, every source note that links to this note is rewritten in place — wikilinks, embeds, path-style links, and bare-href markdown links [text](Old.md), whose new href is written relative to the linking note's own folder; angle-bracket hrefs [text](<Old.md>) are not rewritten. Aliases and anchors survive. The moved note's own body is rewritten as well, so a self-reference does not end up pointing at the old path. The rewrites are planned before anything changes: if one would push a source past the note size limit, or the planning would exceed the aggregate memory bound, the whole move is refused before any file is touched, naming the source or the count.

The same preflight refuses the whole move, before the rename, when any source it would rewrite — the moved note's own body included — contains a fence opener indented by one to three spaces that nothing below it closes. The refusal names each such source and where its opener sits. Move with rewrite_links=False (unaffected by this refusal) and fix the links yourself, or close the fences first.

A rewrite can still fail after the move has committed. The move is one rename and the rewrites follow it, so an I/O failure or a lost vault assignment stops the remaining rewrites and the result reads partial success: …, naming the sources that still link to the old path. The move is not rolled back; treat the link graph as agreeing with the vault bytes only on plain success, and fix the named sources with edit_note.

Success reports the content_hash of the bytes actually published at to_path — the moved bytes for a plain move, the post-rewrite bytes when the moved note's own body was rewritten — and that value binds a following edit_note(to_path, …, expected_hash=…). A failed rewrite stays a partial success and never claims nothing was written; if another writer changed to_path in between, no hash is reported and the result says to re-read to_path first.

Writes are atomic; a symlinked final component on either path is refused. See get_vault_guide for vault folder conventions.

Args: from_path: Vault-relative path of the existing note. to_path: Vault-relative path of the destination. rewrite_links: Also rewrite incoming links in source notes (off by default). expected_hash: from_path's content_hash as you last read it.