Skip to main content
Glama
Sign In
obsidian-mcp-pro

obsidian-mcp-pro

by rps321321
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Prepend to Note

prepend_to_note

Insert content at the top of an existing note's body, right after any YAML frontmatter so metadata stays on top. Use it to prepend list items, pin context, or add TL;DR sections; fails if the note is missing.

Instructions

Insert content at the top of an existing note's body, immediately after the YAML frontmatter block if one is present (so metadata stays at the top of the file). Use for adding new items to the front of a running list, pinning context, or inserting TL;DR sections. Fails if the note does not exist.

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>",
      "content": "<content>"
    },
    "name": "prepend_to_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesRelative path from vault root to the target note (e.g., 'notes/log.md'). Extension optional.
contentYesMarkdown text to insert at the top of the body, after any frontmatter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv2.0.0
  3. Removedv1.9.0
  4. Addedv0.1.6
  5. Removedv0.1.4
  6. Changed2 schema fields changedv0.1.2
    • changedInput schema / properties / content / description
      Previous value: -"Content to prepend"New value: +"Markdown text to insert at the top of the body, after any frontmatter"
    • changedInput schema / properties / path / description
      Previous value: -"Relative path to the note"New value: +"Relative path from vault root to the target note (e.g., 'notes/log.md'). Extension optional."
  7. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description contributes the non-obvious behaviors: frontmatter is preserved at the top and the call errors when the note is missing. It does not state whether repeated calls duplicate content (relevant given idempotentHint=false) or whether the vault index is updated.

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?

Three short sentences, front-loaded with the operation and its placement rule, followed by use cases and the failure condition. No redundancy or filler.

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?

For a two-parameter mutation tool with full annotation coverage and no output schema, this covers placement, when to use it, and the failure mode. It could go further on idempotency/duplication behavior given idempotentHint=false, but nothing needed to invoke it correctly is absent.

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 the schema already documents both path and content, including the 'after any frontmatter' wording the description repeats. The description adds no format, size, or encoding detail beyond the schema, so the baseline 3 applies.

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 ('Insert content at the top of an existing note's body') plus the placement rule relative to YAML frontmatter, which is the exact semantic that separates it from append_to_note and insert_at_section. An agent can identify the operation without opening the schema.

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

Usage Guidelines4/5

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

Gives concrete use cases (prepending to a running list, pinning context, TL;DR sections) and a precondition ('Fails if the note does not exist'). It stops short of naming the sibling alternatives append_to_note or insert_at_section that an agent should consider instead when the target position differs.

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

Deploy Server

Other Tools