Obsidian Scoped-write MCP

MCP service for accessing a designated Obsidian Vault. The entire Vault is readable; creating and updating Markdown is allowed only in two ChatGPT-specific directories:

• 00-ChatGPT系统入口

• 01-ChatGPT策略主脑

No deletion, move, rename, or non-Markdown write tools are provided.

Tools

• list_directory: List the directory.

• read_markdown: Read Markdown.

• search_markdown: Search Markdown.

• get_file_info: View size, modification time, SHA-256, and writable status.

• create_directory: Create a first-level ordinary subfolder within an allowed directory; the parent directory must already exist.

• create_markdown: Create a new file in an allowed directory; overwriting is forbidden.

• update_markdown: Update an existing file using the expected SHA-256, with a backup made outside the Vault before the update.

Related MCP server: obsidian-mcp

Local verification

npm ci
npm test

Tests create a temporary Vault and a temporary backup directory by default and do not touch personal Obsidian data. When a real Vault path is passed in, only read tests are run; no writes are performed.

Security boundaries

• Write directories are controlled by a fixed server-side allowlist; tool parameters cannot expand the scope.

• Creating folders only allows one-level operations; duplicate names, hidden directories, missing parent directories, out-of-bounds paths, and symlink escapes are all rejected.

• Rejected when the creation target already exists.

• Before updating, call get_file_info and use the returned sha256 as expected_sha256; the update is rejected if the file has changed.

• Before updating, back up to the current Windows user's local application data directory; the backup is not inside the Vault or the Git repository.

• Absolute paths, out-of-bounds paths, symlink escapes, and non-Markdown files are all rejected.

Development workflow

• main always remains releasable.

• All repository changes use short-lived branches and Pull Requests.

• Merge only after CI passes; squash merge is used by default.

• Architecture, security boundaries, data formats, long-term dependencies, or large features spanning multiple independent PRs: parent Issue, Sub-issues, ADR, PR, CI, and rollback records.

• Small patches: a single Issue or PR, minimal changes, minimal tests, and rollback notes.

Lightweight patch acceptance

• Acceptance: run npm test, and merge after the Pull Request's CI checks pass.

• Rollback: revert the corresponding squash commit on GitHub.