Skip to main content
Glama
dharmikbhesaniya

Obsidian Remote MCP Server

obsidian_prepend_note

Prepends text below frontmatter in an existing Obsidian note, using an optional revision check to prevent overwriting newer edits.

Instructions

Prepends text content below frontmatter in an existing note with revision check

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes
expectedRevisionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the 'revision check' behavior, signalling a concurrency/optimistic-locking concern, which is real value beyond structured fields. However it does not say what happens on a revision mismatch, whether the write is atomic, or what permissions are needed, so the mutation's failure semantics remain opaque.

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?

A single, front-loaded sentence with no filler; the most important fact (prepend, below frontmatter, existing note) comes first and the qualifier (revision check) trails it.

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

Completeness3/5

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

For a 3-parameter mutation tool with no annotations and no output schema, the description covers the operation and the revision guard but omits error behavior on revision mismatch, return value, and any frontmatter-preservation caveats. Adequate but with clear gaps.

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 description coverage is 0%, so the description must compensate. It loosely maps all three parameters ('text content', 'existing note', 'revision check'), which is better than nothing, but it gives no format for expectedRevision (hash? integer?) or any content constraints such as frontmatter handling or newline insertion, so the gap is only partially closed.

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?

The description gives a specific verb (prepends), resource (note), and a precise insertion point ('below frontmatter'), which distinguishes it from the sibling obsidian_append_note purely by the verb semantics. It does not explicitly name append_note as the counterpart, but the verb pair is self-evident to an agent reading the sibling list.

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

Usage Guidelines2/5

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

There is no statement of when to use prepend versus append_note, update_note, or create_note, and no prerequisites are given. The only implied constraint is 'existing note', which rules out creation but leaves the choice among the four writing tools to inference.

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