Obsidian MCP Server - Enhanced

Simultaneous access to multiple Obsidian vaults through a single MCP server:

- Multiple Vault Management: Connect to multiple Obsidian instances on different ports simultaneously
- Vault-Specific Routing: Tools automatically route to the correct vault based onvaultparameter
- Individual Authentication: Separate API keys for each vault with centralized MCP authentication
- Backwards Compatible: Existing single-vault configurations continue to work unchanged
- Dynamic Configuration: JSON-based vault configuration with validation and error handling

Perfect integration with Claude.ai's Remote MCP feature:

- Stateless HTTP Mode: Dedicated stateless transport for Claude.ai compatibility (MCP_HTTP_STATELESS=true)
- Session-Based Mode: Traditional session management for other MCP clients
- Simplified Authentication: Uses dedicated MCP_AUTH_KEY for server access
- Zero Configuration: Works out-of-the-box with Claude.ai Remote MCP servers
- Production Ready: Enterprise-grade stability and error handling

Access your Obsidian vault securely from anywhere:

- Tailscale Funnel Integration: Secure HTTPS endpoints with automatic certificates
- End-to-End Encryption: All traffic encrypted through Tailscale network
- No Port Forwarding: Zero network configuration required
- Access Control: Built-in Tailscale ACL support for enterprise security

Advanced querying capabilities beyond the original:

- Tasks Plugin Integration: Deep integration with Obsidian Tasks plugin
- Advanced Date Parsing: Natural language date recognition
- Priority Detection: Visual and text-based priority parsing
- Multiple Output Formats: Table, list, and summary views

🔧Production Monitoring & Reliability

Enterprise-grade monitoring and auto-restart capabilities:

- Health Check Script: Comprehensive component validation (scripts/health-check.sh)
- Intelligent Monitoring: Auto-restart with process lifecycle management (scripts/monitor-mcp.sh)
- macOS Auto-Start: Launch agent configuration for system startup (scripts/setup-autostart.sh)
- Dynamic Port Management: Automatic port conflict resolution (3010-3013 range)
- Enhanced Logging: Detailed connection debugging and API key validation

This server equips your AI with specialized tools to interact with your Obsidian vault:

The Obsidian MCP Server acts as a bridge, allowing applications (MCP Clients) that understand the Model Context Protocol (MCP) – like advanced AI assistants (LLMs), IDE extensions, or custom scripts – to interact directly and safely with your Obsidian vault.

Instead of complex scripting or manual interaction, your tools can leverage this server to:

- Automate vault management: Read notes, update content, manage frontmatter and tags, search across files, list directories, and delete files programmatically.
- Integrate Obsidian into AI workflows: Enable LLMs to access and modify your knowledge base as part of their research, writing, or coding tasks.
- Build custom Obsidian tools: Create external applications that interact with your vault data in novel ways.

Leverages the robust utilities provided by themcp-ts-template:

- Logging: Structured, configurable logging (file rotation, console, MCP notifications) with sensitive data redaction.
- Error Handling: Centralized error processing, standardized error types (McpError), and automatic logging.
- Configuration: Environment variable loading (dotenv) with comprehensive validation.
- Input Validation/Sanitization: Useszodfor schema validation and custom sanitization logic.
- Request Context: Tracking and correlation of operations via unique request IDs.
- Type Safety: Strong typing enforced by TypeScript and Zod schemas.
- HTTP Transport Option: Native Node.js HTTP server with session management, CORS support, and API key authentication.

git clone https://github.com/BoweyLou/obsidian-mcp-server-enhanced.git cd obsidian-mcp-server-enhanced

Configure the server using environment variables.

These variables must be set in the MCP client configuration (e.g.,cline_mcp_settings.json) or in your environment before starting the server (if running directly).

If running directly, they can be set in a.envfile in the project root or directly in your environment.

The server supports both single-vault (backwards compatible) and multi-vault modes:

# .env file MCP_AUTH_KEY=your-generated-mcp-auth-key OBSIDIAN_API_KEY=your-obsidian-plugin-api-key OBSIDIAN_BASE_URL=http://127.0.0.1:27123 MCP_TRANSPORT_TYPE=http MCP_HTTP_STATELESS=true

For local MCP clients (e.g., Cline), add to your settings (e.g.,cline_mcp_settings.json):

Configure Environment: Set up your.envfile with the generated key:

MCP_AUTH_KEY=your-generated-auth-key MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 MCP_HTTP_STATELESS=true

npm run build && npm run start:http

Get Your Public URL: Check your Tailscale device URL:

tailscale status --self | grep "Funnel on"

Add to your Claude.ai Remote MCP servers using your MCP authentication key:

{ "url": "https://your-device.your-tailnet.ts.net/mcp?api_key=your-mcp-auth-key", "name": "Obsidian Vault" }

{ "url": "https://your-device.your-tailnet.ts.net/mcp?api_key=your-mcp-auth-key", "name": "Obsidian Multi-Vault" }

Authentication Note: Claude.ai Remote MCP uses theMCP_AUTH_KEYfor server authentication. Individual vault operations use the vault-specific API keys configured in your environment.

- Dual Authentication: MCP server authentication via MCP_AUTH_KEY, vault authentication via individual API keys
- Tailscale Encryption: All traffic is encrypted end-to-end by Tailscale
- Private Network: Only you can access the server through your Tailscale network
- Automatic SSL: Tailscale Funnel provides automatic HTTPS certificates
- Vault Isolation: Each vault uses its own API key for secure access control

Once set up, you can use tools remotely from Claude.ai:

Single-vault commands (uses default vault):

Use obsidian_task_query to show me tasks due today with format="table"

Use obsidian_task_query with vault="work" to show me work tasks due today

Use obsidian_read_file with filePath="daily-note.md" and vault="personal"

Use obsidian_dataview_query with vault="work" to run: TABLE file.name FROM #meeting WHERE file.cday = date(today)

Claude and local MCP clients can connect directly to/mcp. Hosted ChatGPT connectors should use the separateobsidian-chatgptfacade instead. The facade reuses the existing vault, search, and task logic internally, but it has its own process, port, OAuth/PKCE authorization flow, scoped capabilities, and write audit log.

Use the facade for public HTTPS or Tailscale Funnel routes. Keep the full MCP server on localhost or private tailnet-only routes unless you are doing an explicit local/dev test.

Configure a public resource URL and admin approval secret, then start the facade:

export CHATGPT_FACADE_PUBLIC_URL="https://your-device.your-tailnet.ts.net" export CHATGPT_FACADE_ADMIN_SECRET="$(openssl rand -hex 24)" npm run build npm run start:chatgpt

If the same Funnel hostname also exposes another ChatGPT connector, give this facade a path-scoped resource URL such ashttps://your-device.your-tailnet.ts.net/obsidianand route the/obsidianprefix to the facade port. The facade serves both root and path-qualified well-known metadata paths for that setup. In that shared-host setup, create the connector withhttps://your-device.your-tailnet.ts.net/obsidian/mcp.

curl "http://127.0.0.1:3020/health"

For facade HTTP-surface tests without a live Obsidian API, setCHATGPT_FACADE_SKIP_OBSIDIAN_CHECK=true. Leave it unset for normal operation.

The facade publishes OAuth discovery metadata:

- /.well-known/oauth-protected-resource
- /.well-known/oauth-authorization-server
- /.well-known/openid-configuration

It stores authorization-code, access-token, and refresh-token hashes locally underCHATGPT_FACADE_STORE_PATH, not raw tokens. It requires PKCE S256 for initial token exchange, supports refresh-token rotation, and validates bearer tokens by resource, expiry, and scope before executing actions.

- obsidian:read:search,fetch,task_query,latest_note
- obsidian:write:create_task,update_task,append_note,create_note,create_daily_note
- obsidian:dangerous-write:overwrite_note

Read-only connector setup is the default and is supported by granting onlyobsidian:read.overwrite_noteis not available unlessobsidian:dangerous-writeis explicitly granted.