Skip to main content
Glama
maxkuminov

Obsidian MCP (pgvector + Ollama, self-hosted)

edit_note

Modify an existing Obsidian note by replacing content, appending, or using find-and-replace. Supports section-specific edits and dry-run previews.

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?

Discloses atomic writes, dry-run behavior, mode exclusivity, and flags. Covers important edge cases like setext headings not being matched and replace_all behavior. No annotations present to contradict.

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?

Well-structured with bullet points and clear sections, but slightly lengthy. Each sentence adds value, though some redundancy could be trimmed.

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?

Comprehensively covers all aspects of the tool: modes, flags, edge cases, atomicity, and cross-references to other tools. No missing details given the complexity.

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?

With 0% schema description coverage, the description fully explains all 7 parameters, including their interactions and defaults (e.g., append, find, section, replace_all, dry_run).

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?

Clearly states it edits an existing note and outlines four distinct modes (full replace, append, find/replace, section). Differentiates from sibling tools like set_frontmatter.

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?

Provides explicit when-to-use guidance for each mode and advises against using it for frontmatter mutation, referencing set_frontmatter. Also recommends get_vault_guide for conventions.

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

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