Skip to main content
Glama
markdown-vault-mcp

markdown-vault-mcp

by pvliesdonk

Rename Note

rename

Move a note or attachment to a new path and rewrite links in other notes so references follow; missing parent folders are created automatically.

Instructions

Rename or move a note or attachment; with update_links, links to it in other notes follow it.

For a note, always pass update_links=True. Parent folders are created as needed.

Input Schema

NameRequiredDescriptionDefault
if_matchNoEtag from read of old_path; still accepted when the only changes since are link rewrites the server made.
new_pathYesNew path, such as `"projects/idea.md"`, where nothing exists yet.
old_pathYesCurrent path, such as `"drafts/idea.md"` or `"assets/old.png"`.
update_linksNoRewrite links to old_path in other notes so they point at new_path; attachment references are not tracked. Default false; pass true for every note.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv6.1.0
    • changedInput schema / properties / if_match / description
      Previous value: -"Optional etag obtained from a previous 'read' call\nfor old_path. When provided, the rename only proceeds if\nthe file has not been modified since that read (optimistic\nconcurrency). Omit to rename unconditionally."New value: +"Etag from read of old_path; still accepted when the only\nchanges since are link rewrites the server made."
    • changedInput schema / properties / new_path / description
      Previous value: -"Target relative path (e.g. \"projects/idea.md\"\nor \"assets/new.png\"). Fails if new_path already exists."New value: +"New path, such as `\"projects/idea.md\"`, where nothing exists yet."
    • changedInput schema / properties / old_path / description
      Previous value: -"Current relative path (e.g. \"drafts/idea.md\"\nor \"assets/old.png\")."New value: +"Current path, such as `\"drafts/idea.md\"` or `\"assets/old.png\"`."
    • changedInput schema / properties / update_links / description
      Previous value: -"When True, all .md documents that link to old_path\nare also updated so their links point to new_path. Replacement\nis best-effort — failures are logged but do not prevent the\nrename. Default False; set True whenever renaming a .md note\n(omitting this leaves backlinks pointing to the old path)."New value: +"Rewrite links to old_path in other notes so they point at\nnew_path; attachment references are not tracked. Default false; pass\ntrue for every note."
  2. Addedv4.0.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations mark the tool as non-destructive and non-idempotent. The description adds that parent folders are auto-created and that links in other notes get rewritten. The schema adds that new_path must not exist and that attachment references are not tracked. The description does not say what happens on a path collision or an etag mismatch.

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?

Two short sentences, front-loaded with the purpose and no filler. The update_links advice is duplicated between the description and the schema.

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?

An output schema exists and the schema documents parameters well, so the description is reasonably complete for a 4-parameter mutation. It is missing failure behavior and folder-move routing.

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

Parameters3/5

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

Schema coverage is 100% and covers if_match, new_path constraints and update_links. The description mostly repeats the update_links recommendation already stated in the schema, adding little new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

It names a specific action on specific resources: "Rename or move a note or attachment," plus link-following. It does not set itself apart from move_folder, which is the sibling most likely to cause confusion, though "note or attachment" implies single-file scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The directive "For a note, always pass update_links=True" is useful invocation guidance. There is no when-to-use versus alternatives, such as using move_folder for folders, or write/delete instead of rename.

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