Skip to main content
Glama
rps321321

obsidian-mcp-pro

by rps321321
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Append to Note

append_to_note

Add text to the end of an existing Obsidian note without changing prior content. Preserves existing text and starts appended content on its own line, ideal for log entries and running lists.

Instructions

Append text to the end of an existing note without altering prior content. By default, inserts a leading newline if the file does not already end in one, so appended content starts on its own line. Use for log entries, running lists, or adding new sections. Fails if the note does not exist — use create_note to make a new note first.

Input Schema

NameRequiredDescriptionDefault
pathYesRelative path from vault root to the target note (e.g., 'journal/2026-04-15.md'). Extension optional.
contentYesMarkdown text to append to the end of the note. A leading newline is auto-inserted when the file does not already end in one.

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. Changed3 schema fields changedv0.1.2
    • changedInput schema / properties / content / description
      Previous value: -"Content to append"New value: +"Markdown text to append to the end of the note"
    • changedInput schema / properties / ensureNewline / description
      Previous value: -"Ensure content starts on a new line (default: true)"New value: +"If true, ensures appended content begins on a new line when the file does not already end in a newline (default: true)"
    • 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., 'journal/2026-04-15.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?

Adds real behavior beyond the annotations: the auto-inserted leading newline (a side effect on the file), the guarantee that prior content is preserved, and the fail-when-missing error mode. The safety profile (non-destructive, non-idempotent) is already carried by the hints, and the description doesn't explain what repeated appends accumulate to or what is returned, so it is strong but not exhaustive.

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, each doing distinct work: core semantics, default newline behavior, then use cases and the failure/alternative. The critical non-destructive guarantee is front-loaded rather than buried.

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 append tool with full schema coverage and safety annotations, this covers the essentials: what changes, what doesn't, the default newline, and the not-found failure. The only gap is that, with no output schema, it never says what the call returns (e.g., bytes written, resulting length), which an agent verifying the append might need.

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 both parameters are documented with examples and length limits, so the schema does the heavy lifting and the baseline of 3 applies. The description's newline note merely restates what the 'content' schema field already says; it adds no new path or content semantics.

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 ('append text to the end of an existing note') and immediately pins down the distinguishing semantics: prior content is untouched. It also names the sibling it is often confused with ('use create_note to make a new note first'), so an agent can separate append semantics from creation.

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 (log entries, running lists, new sections) and the failure precondition with a redirect to create_note. It does not, however, distinguish against the other mutating siblings it most overlaps with — prepend_to_note, insert_at_section, update_section, replace_in_note — leaving that routing to inference.

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