Skip to main content
Glama
maxkuminov

Obsidian MCP (pgvector + Ollama, self-hosted)

edit_note

Edit an existing note with four modes: full replace, append, find & replace, or section replacement. Supports dry run and atomic writes.

Instructions

Edit an existing note in the Obsidian vault. Requires a readwrite API key.

See get_vault_guide for Obsidian syntax and any vault-specific conventions (naming, folder placement, frontmatter, tags).

Four mutually exclusive modes (set at most one of append/find/section):

  1. Full replace (default): provide only content; the entire file is overwritten.

  2. Append: append=True; content is added at the end (preceded by a single newline).

  3. Find & replace: find=<exact text>; replaced with content. Must match exactly once unless replace_all=True.

  4. Section: section=<heading>; replaces the body under the named ATX heading. Use the path-style form Parent/Child to disambiguate when the same heading appears more than once. Setext (====/----) headings are not matched.

Flags:

  • replace_all=True: with find, replace every occurrence rather than failing on multiple matches. Ignored when find is unset.

  • dry_run=True: compute the would-be result and return a unified diff without writing. Works for all four modes.

Writes are atomic (tmp file + os.replace) so a crash mid-write cannot truncate the destination. Frontmatter mutation is better done via set_frontmatter — PyYAML serialization there discards YAML comments.

Args: path: Vault-relative path to the note. content: New full content, replacement text, text to append, or section body. append: If True, append content to the end of the note. find: Exact text to find and replace. section: ATX heading text identifying the section whose body to replace. Use Parent/Child to disambiguate repeated headings. replace_all: With find, replace every match instead of requiring uniqueness. dry_run: Return a unified diff and do not write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes
appendNo
findNo
sectionNo
replace_allNo
dry_runNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: atomic writes via tmp file + os.replace, dry_run returning a unified diff without writing, replace_all behavior, and PyYAML comment discarding (directing to set_frontmatter). This is comprehensive.

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?

The description is well-structured with bullet points, numbered modes, and clearly separated sections. It is front-loaded with the core purpose and each sentence adds value without redundancy.

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 tool's complexity (7 parameters, 4 modes, flags) and the presence of an output schema (so return values need not be explained), the description is complete. It covers atomicity, dry_run output, and all parameter interactions.

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?

The input schema has 0% description coverage, but the description explains each parameter in detail, including constraints (e.g., find must match exactly once, section uses Parent/Child, append adds a newline). This adds significant meaning beyond the schema.

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 'Edit an existing note in the Obsidian vault' and distinguishes itself from siblings by referencing `set_frontmatter` for frontmatter mutation and `get_vault_guide` for conventions. The four modes are explicitly listed, making the tool's purpose unambiguous.

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?

The description provides explicit when-to-use guidance for each of the four modes (full replace, append, find & replace, section) and flags like `dry_run`. It also advises using `set_frontmatter` for frontmatter changes, offering clear alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maxkuminov/obsidian-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server