Obsidian Web Mcp

obsidian-web-mcp

A secure, remote-accessible MCP server that gives LLMs read/write access to your Obsidian vault from anywhere -- your desktop, your phone, a hotel Wi-Fi network. Unlike local-only Obsidian MCP servers, this one runs over HTTPS with real authentication, so Claude (or any MCP client) can reach your vault whether you're at your desk or not.

It reads and writes markdown files on disk, parses YAML frontmatter, maintains an in-memory frontmatter index for fast queries, and handles full-text search -- all behind OAuth 2.0 authentication and a Cloudflare Tunnel that never exposes your machine directly to the internet.

Why This Exists

There are many Obsidian MCP servers. Most are local stdio servers -- they work when Claude Code is running on the same machine as your vault. That's useful, but it means:

• Claude.ai (web) can't reach your vault. The browser-based Claude has no way to connect to a local stdio server.
• Claude on your phone can't reach your vault. Same problem.
• If you use Obsidian Sync, local MCP servers can corrupt files. Non-atomic writes create partial files that Sync propagates to every device.

This server solves all three. It runs as a persistent HTTP service on the machine where your vault lives, tunneled securely through Cloudflare, and authenticates via OAuth 2.0 -- the same protocol Claude uses for Gmail, Google Calendar, and other integrations. The result: your vault becomes a first-class MCP connector available everywhere Claude is.

Architecture

+----------+     +------------+     +-----------------+     +------------------+
| Obsidian |  | Filesystem |  | obsidian-web-mcp|  | Cloudflare       |
| (app)    |     | (*.md)     |     | (MCP over HTTPS)|     | Tunnel           |
+----------+     +------------+     +-----------------+     +------------------+
                                                                   |
                                                            +------+-------+
                                                            | Claude       |
                                                            | (web/desktop/|
                                                            |  mobile)     |
                                                            +--------------+

Your vault files never leave your machine. Cloudflare Tunnel creates an outbound-only connection from your server to Cloudflare's edge -- no inbound ports opened, no public IP exposed, no port forwarding. Claude connects to the Cloudflare edge, which relays requests through the tunnel to your server.

Obsidian and the MCP server both operate on the same directory of markdown files. The server uses atomic writes (write-to-temp-then-rename) so Obsidian Sync and the server never conflict.

Security Model

This is a server that provides network access to your personal notes. Security is not optional.

A human logs in before any client is authorized. Connecting a client uses the OAuth 2.0 authorization-code + PKCE flow, which opens a browser at /oauth/authorize. There, you must sign in with VAULT_OAUTH_USERNAME / VAULT_OAUTH_PASSWORD before the server issues an authorization code -- the password is required on every authorization. Every subsequent MCP tool call is then validated against a bearer token. No authorization code is issued to an unauthenticated visitor, and no request reaches a tool function without a valid token. If VAULT_OAUTH_PASSWORD is not set, the server fails closed and refuses to authorize anyone -- there is no anonymous auto-approve.

Your vault is never exposed directly to the internet. The recommended deployment uses a Cloudflare Tunnel -- an outbound-only encrypted connection. Your machine opens no inbound ports, and the server itself binds to loopback (127.0.0.1) by default. The login above is the authentication boundary; you can additionally layer Cloudflare Access (SSO, device posture, IP restrictions) on top for defense in depth.

Path traversal is blocked at the filesystem layer. Every file operation resolves paths against the vault root directory and rejects any attempt to escape it -- .. traversal, symlink following, null byte injection, and dotfile access (.obsidian, .git, .trash) are all caught before they reach the filesystem. The server will never read or write outside your vault directory.

Writes are atomic. Every file write goes to a temporary file first, then atomically replaces the target via os.replace(). This guarantees that neither Obsidian nor Obsidian Sync ever sees a partially-written file -- the operation either completes fully or doesn't happen at all.

Safety limits prevent abuse. Writes are capped at 1MB per file, batch operations at 20 files per request, and search results at 50 matches. Deletions are soft -- files move to .trash/ rather than being permanently removed, matching Obsidian's own behavior. The delete tool also requires an explicit confirm=true parameter as a safety gate.

Reporting Security Issues

Found a vulnerability? Please report it privately rather than opening a public issue or pull request. This repository has private vulnerability reporting enabled: open the repo's Security tab and click Report a vulnerability. I'll acknowledge the report, coordinate a fix, and credit you in the resulting advisory. Please hold public disclosure until a patch is available.

Tools

| Tool | Description | |------|-------------| | vault_read | Read a file, returning content, metadata, and parsed YAML frontmatter | | vault_batch_read | Read multiple files in one call; handles missing files gracefully | | vault_write | Write a file with optional frontmatter merging; creates parent dirs | | vault_write_binary | Write an allowed binary file (image/PDF) to the vault from base64 content; enforces a media-type allowlist (declared type/extension, not byte-sniffed) and size cap, writes atomically | | vault_edit | Patch a file with ordered exact text replacements (token-efficient partial edits); supports dry-run diff previews | | vault_append | Append content to the end of a file without resending the existing body; creates the file when missing | | vault_batch_frontmatter_update | Update YAML frontmatter fields on multiple files without touching body content | | vault_search | Full-text search across vault files (uses ripgrep if available, falls back to Python) | | vault_search_frontmatter | Query the in-memory frontmatter index by field value, substring, or field existence | | vault_list | List directory contents with recursion depth, glob filtering, and file/dir toggles | | vault_move | Move or rename a file or directory within the vault | | vault_delete | Soft-delete a file by moving it to .trash/ (requires explicit confirmation) | | vault_canvas_read | Read an Obsidian .canvas file and return its parsed nodes and edges | | vault_canvas_add_node | Append a node to a .canvas file (created if missing); generates an id when omitted and preserves unknown node fields | | vault_canvas_add_edge | Append an edge to an existing .canvas file; both endpoints must reference existing node ids | | vault_daily_note_path | Resolve today's daily-note path from the configured folder/format | | vault_daily_note_read | Read today's daily note; returns an error (does not create it) when missing | | vault_daily_note_append | Append to today's daily note, creating it from the template when missing | | vault_analytics_summary | Compact vault-hygiene summary: counts and examples of missing frontmatter, broken wikilinks, near-duplicate tag variants, and non-UTF-8 files | | vault_analytics_findings | Detailed findings for one analytics category (frontmatter_missing, required_frontmatter_missing, broken_wikilinks, suspicious_tag_variants, encoding_issues, oversized_files) |

Prerequisites

• Python 3.12+
• uv (recommended) or pip
• An Obsidian vault (any directory of markdown files)
• cloudflared (only needed for remote access)
• A domain managed by Cloudflare (only needed for remote access)

Quick Start

Local development

# Clone and enter the project
git clone https://github.com/jimprosser/obsidian-web-mcp.git
cd obsidian-web-mcp

# Generate the MCP bearer token
export VAULT_MCP_TOKEN=$(python -c "import secrets; print(secrets.token_hex(32))")

# Set the login the OAuth browser step requires. REQUIRED -- without a password
# the server fails closed and refuses to authorize any client.
export VAULT_OAUTH_USERNAME="you"
export VAULT_OAUTH_PASSWORD="$(python -c "import secrets; print(secrets.token_urlsafe(24))")"   # or a passphrase you'll remember

# Point at your vault
export VAULT_PATH="$HOME/Obsidian/MyVault"

# Run the server
uv run vault-mcp

The server starts on port 8420 by default and serves MCP over Streamable HTTP at / (the root path — MCP clients connect to the base URL directly). It binds to 127.0.0.1 -- reachable locally and through a Cloudflare Tunnel, but not exposed on your LAN. Set VAULT_MCP_HOST=0.0.0.0 only if you deliberately want direct network exposure.

Configuration

All configuration is via environment variables:

| Variable | Required | Default | Description | |----------|----------|---------|-------------| | VAULT_PATH | Yes | ~/Obsidian/MyVault | Absolute path to your Obsidian vault directory | | VAULT_MCP_TOKEN | Yes | (none) | 256-bit bearer token validated on every MCP request | | VAULT_OAUTH_PASSWORD | Yes | (none) | Password for the interactive login at /oauth/authorize. If unset, the server refuses to authorize any client (fail-closed). | | VAULT_OAUTH_USERNAME | No | obsidian | Username for the interactive login | | VAULT_MCP_HOST | No | 127.0.0.1 | Bind address. Loopback by default; set 0.0.0.0 only for deliberate LAN exposure | | VAULT_MCP_PORT | No | 8420 | Port the HTTP server listens on | | VAULT_MCP_PATH | No | / | HTTP path the MCP transport mounts at. Default / keeps connector interop (#19) byte-identical. Set to a prefix like /mcp to host the server alongside other services on one hostname behind a reverse proxy that can't rewrite paths. Validated at startup: must be absolute and must not collide with an auth-exempt route (/health, /oauth/*, /.well-known/*), or the server refuses to start (fail-closed) rather than serve the vault on an unauthenticated path. | | VAULT_MCP_ALLOWED_HOSTS | No | (none) | Comma-separated hostnames allowed through the MCP library's DNS-rebinding protection, appended to the loopback defaults (127.0.0.1, localhost, [::1]). Set this to your tunnel/proxy hostname (e.g. vault-mcp.yourdomain.com) for any remote deployment, otherwise requests carrying that Host are rejected. | | VAULT_MCP_FORWARDED_ALLOW_IPS | No | 127.0.0.1 | Client IPs uvicorn trusts to set X-Forwarded-* headers. Loopback-only by default, because a trusted Cloudflare Tunnel / Caddy proxy connects over localhost. Never set this to * -- that lets any caller spoof the advertised OAuth origin via X-Forwarded-Host. Set to ::1 if your proxy connects over IPv6 loopback. | | VAULT_MCP_PUBLIC_URL | No | (none) | Canonical public origin (e.g. https://vault-mcp.yourdomain.com) for every URL the server advertises -- the OAuth discovery metadata and the WWW-Authenticate challenge. When set it pins those URLs so a spoofed Host / X-Forwarded-Host header cannot redirect OAuth discovery to an attacker. When unset, the per-request base URL is used. Recommended for any reverse-proxy deployment. | | VAULT_OAUTH_CLIENT_ID | No | vault-mcp-client | Client ID for the headless client_credentials grant | | VAULT_OAUTH_CLIENT_SECRET | No | (none) | Only required for the headless client_credentials grant. The Claude/ChatGPT browser flow uses dynamic client registration and does not need this. | | VAULT_OAUTH_REDIRECT_URIS | No | (none) | Comma-separated allowlist of redirect URIs for the static VAULT_OAUTH_CLIENT_ID when using the browser flow. Dynamically-registered clients (Claude/ChatGPT) carry their own; leave unset unless you connect a static client through /oauth/authorize. | | VAULT_DAILY_NOTES_FOLDER | No | (none) | Folder for the daily-note tools; empty means the vault root | | VAULT_DAILY_NOTES_FORMAT | No | %Y-%m-%d | strftime pattern for the daily-note filename | | VAULT_DAILY_NOTES_TEMPLATE | No | (none) | strftime template prepended when a daily note is first created | | VAULT_MCP_HEARTBEAT_URL | No | (none) | Optional push URL for an uptime monitor (Uptime Kuma, Healthchecks.io, ...). When set, a daemon thread GETs it on an interval. Must be http(s); redirects are not followed and the URL is treated as a secret (never logged in full). Empty = disabled. | | VAULT_MCP_HEARTBEAT_INTERVAL | No | 60 | Seconds between heartbeat pings. Must be a positive integer; a bad value fails closed at startup. Only used when VAULT_MCP_HEARTBEAT_URL is set. | | VAULT_AUDIT_LOG_PATH | No | (none) | Append-only JSONL audit log of vault mutations. When set, every mutation appends one record; empty disables auditing. The raw bearer token is never written -- only its SHA-256 hash. Must resolve outside the vault and be writable; otherwise the server fails closed at startup. See [Audit logging](#audit-logging). | | VAULT_AUDIT_LOG_INCLUDE_READS | No | false | Also record read/search operations (1/true/yes/on). Off by default; mutations are always logged once the audit log is enabled. |

Generate secrets with: python -c "import secrets; print(secrets.token_hex(32))"

Audit logging

Set VAULT_AUDIT_LOG_PATH to a file path to record every vault mutation as an append-only JSON line. Auditing is off by default; with no path set there is no overhead. Reads and searches are logged too when VAULT_AUDIT_LOG_INCLUDE_READS is on (off by default, since reads are high-volume).

Each record carries: timestamp (UTC), token_id_hash (SHA-256 of the bearer token -- the raw token is never written), client_id (a best-effort User-Agent hint), operation, target_path, size_before/size_after, checksum_before/checksum_after (SHA-256), request_id, operation_status, and error. Example line:

{"checksum_after":"9f86d0…","checksum_before":null,"client_id":"claude","error":null,"operation":"vault_write","operation_status":"success","request_id":"a1b2…","size_after":42,"size_before":null,"target_path":"notes/today.md","timestamp":"2026-06-14T18:30:00+00:00","token_id_hash":"5e88…"}

Put the log outside the vault. VAULT_AUDIT_LOG_PATH must resolve outside VAULT_PATH. A log inside the vault would be just another file the vault tools can reach, so an authenticated caller could overwrite it (vault_write) or move it (vault_delete) and defeat the append-only premise. The server validates this at startup and refuses to start (fail-closed) if the path is not writable or resolves inside the vault.

Threat model — the log is best-effort at runtime, not tamper-evident. A write failure at runtime is logged to the server log but never alters the tool result (the audit trail must not be able to break a write), so a record can be dropped silently; the server log is the only signal. Batch mutations emit one record per file with that file's own status, so a partial failure is never recorded as a whole-batch success. The unauthenticated GET /health endpoint reports only {"status": "ok", "audit": {"enabled": }} — it deliberately does not expose the log path or write counters (which would leak host filesystem layout and a vault-activity side-channel to anonymous callers over the tunnel).

Connecting to Cla

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jimprosser
• Source: jimprosser/obsidian-web-mcp
• License: MIT

Install and usage instructions live in the source repository linked above.