markdown-vault-mcp

Append to Note

append

Add text to the end of an existing note without reading it first, ideal for log entries and incremental updates. Creates the note if missing when configured.

Instructions

Add text to the end of an existing note without reading it first.

Prefer it over edit when the change only adds at the end, such as a log entry. The text starts on a new line; begin it with a blank line or a heading to start a paragraph or section.

Input Schema

Name	Required	Description
`path`	Yes	Path of the note, such as `"Journal/2026.md"`.
`content`	Yes	Non-empty text to add after everything the note holds.
`if_match`	No	Etag from read; the text is then added only to that version. Omit to append regardless.
`create_if_missing`	No	Create the note with content as its body when path does not exist. Default false, so a mistyped path creates nothing.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv6.1.0Nov 2, 2026

changedInput schema / properties / content / description

Previous value: -"Text to append (must be non-empty). Added at the end\nof the file, after frontmatter and all existing content."New value: +"Non-empty text to add after everything the note holds."

changedInput schema / properties / create_if_missing / description

Previous value: -"When true, a missing note is created with\n'content' as its body instead of failing. Default false —\na typo in 'path' fails loudly rather than silently creating\na new note."New value: +"Create the note with content as its body when path does\nnot exist. Default false, so a mistyped path creates nothing."

changedInput schema / properties / if_match / description

Previous value: -"Optional etag obtained from a previous 'read' call.\nWhen provided, the append only proceeds if the file has not\nbeen modified since that read (optimistic concurrency).\nOmit to append unconditionally."New value: +"Etag from read; the text is then added only to that version. Omit\nto append regardless."

changedInput schema / properties / path / description

Previous value: -"Relative path to the document (e.g. \"Journal/2026.md\")."New value: +"Path of the note, such as `\"Journal/2026.md\"`."

Addedv4.0.0Aug 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral detail: the appended text lands on a new line and the agent must prefix a blank line or heading to control paragraph/section formatting. It stops short of describing conflict behavior or what happens on a path collision, but if_match and create_if_missing carry that in the schema.

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 core action, followed by the alternative and the formatting rule. No sentence is redundant and nothing is 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 simple append tool with full schema coverage, annotations and an output schema, the description covers purpose, alternative and formatting behavior. The only remaining gap is concurrency or failure behavior, which is reasonably delegated to the if_match and create_if_missing schema docs.

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 100%, so the baseline applies and the description need not restate path, content, if_match or create_if_missing. It mentions no parameter by name, so it adds nothing beyond the schema's own documentation.

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 ("Add text to the end of an existing note") plus a distinguishing constraint ("without reading it first") that separates it from edit/write siblings. 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 Guidelines5/5

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

Explicitly names the alternative ("Prefer it over edit") and the selecting condition ("when the change only adds at the end, such as a log entry"). The exclusion is implied by the same clause, so routing between append and edit requires no inference.

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