Skip to main content
Glama
marwansaab

obsidian-modified-mcp-server

by marwansaab

find_and_replace

Replace text across all Markdown files in an Obsidian vault, with a dry-run mode to preview matches before committing changes.

Instructions

Find and replace text vault-wide across every .md file in the targeted vault. DESTRUCTIVE: this tool rewrites notes in-place. Run with dryRun: true first to preview matches; commit with dryRun: false. The vault SHOULD be in a clean git working tree (or otherwise backed up) before mutations — dry-run is the safety net. Concurrency posture is last-write-wins: if Obsidian (or a sync plugin) writes a note in the gap between the tool's read and write, the tool overwrites that external edit without warning. Close Obsidian or pause sync plugins before running mutations on important content. pathPrefix matching is case-sensitive on all platforms (including Windows) and is a directory-segment prefix (no glob expansion). Files in dot-prefixed directories (e.g., .obsidian/, .trash/) are excluded; the per-file size cap is 5 MB on both input and output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regexNoWhen true, `search` is parsed as an ECMAScript regex with flags g+i?+m+u (no s).
dryRunNoWhen true, no writes; the response includes structured per-match previews instead.
searchYesThe literal text or regex pattern to match. Required, non-empty.
vaultIdNoOptional vault ID (defaults to configured default vault).
verboseNoWhen true, the response includes the per-file array. Default false to keep responses bounded for large vaults.
wholeWordNoWhen true, wraps the effective pattern in \b…\b (literal and regex modes).
pathPrefixNoIf set, only files under this vault-relative path-prefix are scoped. Directory-segment match, case-sensitive on all platforms (including Windows), no glob expansion. Trailing slash is normalized away.
replacementYesThe replacement text. Honors $1 / $& / etc. capture-group references when regex mode is on.
caseSensitiveNoWhen false, matching is case-insensitive (ECMAScript Unicode case-folding).
skipCodeBlocksNoWhen true, fenced code blocks (CommonMark line-anchored, triple-backtick) are excluded from the search and preserved byte-for-byte.
skipHtmlCommentsNoWhen true, HTML comments (<!-- … -->) are excluded from the search and preserved byte-for-byte. Critical for preserving audit-trail comments during project-name renames.
flexibleWhitespaceNoWhen true, substitutes any whitespace run in `search` with \s+.
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses in-place rewriting, last-write-wins concurrency overwrites, dot-directory exclusions, case-sensitivity, and the 5MB per-file cap. This is far beyond minimal disclosure.

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?

The description is long but each sentence earns its place for a destructive tool. Safety guidance is front-loaded ('DESTRUCTIVE' warning, dryRun first). Minor redundancy with schema text (e.g., pathPrefix case-sensitivity) costs the fifth point.

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?

The tool has 12 parameters and no output schema, so return behavior must be self-described. The description covers dryRun structured previews and verbose per-file arrays, but does not fully describe the non-dryRun success response or no-match case. Overall it is rich but has a small gap.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds operational meaning beyond the schema: dryRun previews, per-file size cap, dot-directory exclusions, and vault-wide scope, which help the agent interpret parameters like dryRun and pathPrefix.

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 opens with 'Find and replace text vault-wide across every .md file', which names a specific verb, resource, and scope. This clearly distinguishes it from read-only siblings like search, patch_content, and append_content.

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?

The description provides strong context: run dryRun first, ensure clean git tree/backup, close Obsidian/pause sync before mutations. It does not explicitly name alternatives like 'use search for read-only queries', so it stops short of a full when/when-not matrix.

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/marwansaab/obsidian-modified-mcp-server'

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