Skip to main content
Glama
zoeynine

Obsidian Server MCP

by zoeynine

vault_move

Destructive

Move a file to a new path in an Obsidian vault, creating parent folders as needed; overwrites require allowOverwrite or a matching source hash.

Instructions

Move a file; no link/history updates. Creates parents; trailing / retains filename. Overwrite requires allowOverwrite. ifMatch checks source only. No retry or cross-filesystem fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
ifMatchNo
destinationYes
allowOverwriteNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYes
newPathYes
oldPathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the destructive/idempotent annotations, disclosing that links and history are NOT updated, that parent directories are created, that overwrite requires allowOverwrite, that ifMatch validates the source only, and that there is no retry or cross-filesystem fallback. These are exactly the side-effect and failure-mode details an agent needs before a destructive move.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five dense clauses, each conveying a distinct constraint, with the core action front-loaded and no filler. Every sentence earns its place.

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?

An output schema exists, so return values need no explanation. For a destructive move tool the description covers side effects, overwrite conditions, precondition checking, and failure behavior, leaving nothing critical unstated.

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 description coverage is 0%, so the description must carry the parameters. It explains allowOverwrite (required for overwriting), ifMatch (validates source only), and destination semantics via the trailing-slash rule; only the plain path/destination roles are left implicit.

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?

States a specific verb and resource ('Move a file'), which is immediately distinguishable from read/list siblings. It does not explicitly contrast with vault_write + vault_delete, the plausible alternative, so it stops short of a 5.

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 use case (moving a file) is implied clearly, but there is no explicit when-to-use versus siblings such as delete-then-write, and no preconditions stated beyond the conditional overwrite rule. It gives conditional mechanics rather than selection guidance.

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