Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Write Note

vault_write_note
Destructive

Create a Markdown note in an Obsidian vault or replace an existing note's body with overwrite, while merging properties to preserve unmentioned keys.

Instructions

Create a markdown note, or with overwrite: true replace an existing note's body. Properties merge with any existing properties when overwriting (new keys added, matching keys overwritten, keys set to null removed, unmentioned keys preserved); overwriting without properties keeps the existing property values. A new note leaves out keys set to null.

Example: vault_write_note({ path: "Projects/notes.md", body: "# Notes\n\nProject notes here.", properties: { tags: ["project"], type: "project" } }) Example: vault_write_note({ path: "Projects/notes.md", body: "Updated content.", overwrite: true })

When to use: Creating a new note, or replacing a whole note's body. Prefer vault_patch_note or vault_replace_in_note to change part of a note. Prefer vault_update_properties for property-only edits (no body round-trip). Prefer vault_update_memory for appending dated entries to About Me/ memory files.

Errors:

  • "note already exists" — set overwrite: true to replace it

  • "path must end in …" — add the .md extension

  • "cannot write note …: that path is not a file" — a folder already has this name; choose another path

  • "absolute path blocked" / "path traversal blocked" / "hidden path blocked" — pass a vault-relative path with no dot-prefixed part

  • "concurrent write in progress" — a write to this note is in flight; re-read it and retry

  • "body contains a control character" — remove the character the message names

  • "ENAMETOOLONG: …" or another filesystem error — the message says what to do

  • "properties block …" — with overwrite: true, the note's properties block can't be read, or a rewrite would lose it; the error says how to repair it

  • "the note would open with a properties block …" — a note without properties would start with --- lines around text that can't be properties; the error says how to avoid it

Obsidian syntax: Body is Obsidian Flavored Markdown (no escaping applied). Watch for: #word = tag (escape with #), [[ = wikilink, %% = comment block. In properties: quote wikilink values ("[[Note]]"), use YAML lists for tags, keep property types consistent (string/number/list mismatches cause silent query failures).

Returns: "Wrote ".

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>",
      "body": "<body>"
    },
    "name": "vault_write_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesMarkdown body content — do not include a properties block (the --- lines); use the properties parameter instead.
pathYesVault-relative path including the ".md" extension (e.g. "Projects/notes.md"). Parent folders are created as needed. Use the exact letter case; a different case can create a duplicate note or folder.
overwriteNoAllow overwriting an existing note (default: false).
propertiesNoThe note's properties.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.56.3
    • changedInput schema / properties / body / description
      Previous value: -"Markdown body content — do not include frontmatter fences (---); use the properties parameter instead."New value: +"Markdown body content — do not include a properties block (the --- lines); use the properties parameter instead."
    • changedInput schema / properties / properties / description
      Previous value: -"Properties to merge."New value: +"The note's properties."
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed2 schema fields changedv0.54.13
    • changedInput schema / properties / overwrite / description
      Previous value: -"Allow overwriting an existing note (default: false — errors if file exists)."New value: +"Allow overwriting an existing note (default: false)."
    • changedInput schema / properties / properties / description
      Previous value: -"Optional properties to merge; a null value deletes that key."New value: +"Properties to merge."
  4. Changed1 schema field changedv0.54.9
    • changedInput schema / properties / properties / description
      Previous value: -"Optional properties to merge. New keys are added; existing keys with matching names are overwritten; a null value deletes that key; unmentioned keys are preserved from the existing file."New value: +"Optional properties to merge; a null value deletes that key."
  5. Changed1 schema field changedv0.54.7
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path including the \".md\" extension (e.g. \"Projects/notes.md\"). Parent folders are created as needed."New value: +"Vault-relative path including the \".md\" extension (e.g. \"Projects/notes.md\"). Parent folders are created as needed. Use the exact letter case; a different case can create a duplicate note or folder."
  6. Changed1 schema field changedv0.50.0
    • addedInput schema / properties / overwrite / default
      Added value: +false
  7. Addedv0.32.1
  8. Removedv0.32.0
  9. Changed1 schema field changedv0.27.2
    • addedInput schema / properties / overwrite
      Added value: +{
      +  "description": "Allow overwriting an existing note (default: false — errors if file exists).",
      +  "type": "boolean"
      +}
  10. Changed1 schema field changedv0.23.10
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path (e.g. \"Projects/notes.md\"). Parent folders are created as needed."New value: +"Vault-relative path including the \".md\" extension (e.g. \"Projects/notes.md\"). Parent folders are created as needed."
  11. Changed2 schema fields changedv0.23.5
    • changedInput schema / properties / body / description
      Previous value: -"Markdown body content (no frontmatter fences)"New value: +"Markdown body content — do not include frontmatter fences (---); use the properties parameter instead."
    • changedInput schema / properties / path / description
      Previous value: -"Vault-relative path for the note"New value: +"Vault-relative path (e.g. \"Projects/notes.md\"). Parent folders are created as needed."
  12. Changed1 schema field changedv0.15.23
    • changedInput schema / properties / properties / description
      Previous value: -"Optional properties to merge. New keys are added; existing keys with matching names are overwritten; unmentioned keys are preserved from the existing file."New value: +"Optional properties to merge. New keys are added; existing keys with matching names are overwritten; a null value deletes that key; unmentioned keys are preserved from the existing file."
  13. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the standard annotations, the description offers massive behavioral context: it details property merge behavior, lists numerous actionable errors (like path traversal blocks), and provides specific Obsidian syntax rules.

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

Conciseness4/5

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

While the description is exceptionally long due to the tool's complexity, it is highly structured. It logically flows from purpose/examples to usage guidance, detailed error handling, and finally syntax rules.

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?

Given the high complexity of managing markdown note properties, merging logic, and specific file system constraints, the definition is exceptionally complete. It provides a full operational reference for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema coverage is 100%, the description adds critical semantics that the schema misses. It warns users not to include properties blocks within the body parameter and precisely describes how `properties` and `overwrite` affect existing note state.

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?

The description clearly states the tool's function: creating a markdown note or replacing an existing one. It adds technical depth by explaining the complex property merging logic, which distinguishes it from simpler write operations.

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?

It provides excellent guidance on when to use this tool versus its siblings. By explicitly listing alternatives like vault_patch_note and vault_update_properties, it guides the agent to use the minimally invasive tool first.

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