MCP server for AI agent read/write access to Obsidian vaults via EVC Team Relay.
io.github.entire-vc/evc-team-relay-mcp MCP Server
The io.github.entire-vc/evc-team-relay-mcp Model Context Protocol (MCP) server provides AI agent read/write access to Obsidian vaults via EVC Team Relay. It is distributed with community-visible references such as PyPI and Docker Hub and is associated with the MCP-server ecosystem.
🛠️ Key Features
MCP server for AI agent access to Obsidian vaults
Read/write capability for vault content
Integration path described as “via EVC Team Relay”
🚀 Use Cases
Use AI agents to read from Obsidian vaults
Use AI agents to write/update Obsidian vault data
Coordinate vault access through EVC Team Relay
⚡ Developer Benefits
Supports the Model Context Protocol (MCP)
Aligns with Obsidian and Obsidian-plugin tooling concepts
Published for installation via Spark (spark.entire.vc) as referenced
⚠️ Limitations
Available information does not enumerate specific tools, permissions, authentication methods, or supported vault operations beyond read/write access.
Add the MCP server to your tool's config. Choose one authentication method:
Agent key (recommended) — create a key in the Obsidian plugin → Team Relay settings → Agent Keys. Supports read and write: list_files, read_file, tr_search, and upsert_file all work with a single key. Quickstart →
Email + password — use a dedicated agent account on your Relay instance.
Claude Code — agent key
Add to .mcp.json in your project root or ~/.claude/.mcp.json:
Authentication is automatic — the server logs in and refreshes tokens internally.
Tool availability matrix
Not every tool works in every auth mode, and one group doesn't work in
either mode — these are two unrelated facts, so don't conflate them:
Group
Tools
Status
Agent key, folder shares
list_files, read_file, upsert_file
Working — the only write path in this MCP server
JWT (email/password)
list_files, tr_search, read_file
Working, read-only by design
No backend route in either mode
read_document, write_document, delete_file
Always raise ValueError — not an auth restriction
Write access is agent-key-only, by sanctioned policy (see
TR-05 (#0cdd5328)):
upsert_file is the only write tool with a working backend route, and it
only writes when an agent key (RELAY_AGENT_KEY / RELAY_AGENT_KEYS) is
configured. JWT mode calling upsert_file raises a clear ValueError
naming agent-key mode as the fix, instead of a confusing 404.
read_document, write_document, and delete_file are a separate,
independent gap — the control plane has no backend route for them at
all, in agent-key mode either. Switching to an agent key will not
make them work: doc-share live content is CRDT/WebSocket-only (no REST
bridge), and per-file delete has no DELETE route server-side yet. If
routes for these are ever added, they'd still follow the agent-key-only
write policy above — JWT would stay read-only.
Remote Deployment (HTTP Transport)
For shared or server-side deployments, run as an HTTP server:
bash
# Direct
uv run relay_mcp.py --transport http --port 8888
# Docker (pulls from Docker Hub automatically)
RELAY_CP_URL=https://cp.yourdomain.com \
RELAY_EMAIL=agent@yourdomain.com \
RELAY_PASSWORD=your-password \
docker compose up -d
# Or pull explicitly
docker pull deadalusevc/evc-team-relay-mcp:latest
By default the server binds to 127.0.0.1 (localhost-only) — the endpoint is not
reachable over the network even if the host has a public IP. This matches the common
case of a single MCP client on the same machine as the server.
Then configure your MCP client to connect via HTTP:
If your MCP client runs on a different machine than the server, tunnel to the
localhost-bound port instead of exposing it publicly:
bash
# From the client machine, forward local 8888 to the server's localhost:8888
ssh -N -L 8888:127.0.0.1:8888 user@your-server
Then point the client config at http://127.0.0.1:8888/mcp as above — traffic
goes through the SSH tunnel, and the server's bind address never needs to change.
Public / reverse-proxy binding (opt-in)
If you genuinely need the server to accept connections from other hosts directly
(e.g. it sits behind a reverse proxy that terminates TLS and handles auth), pass
--host explicitly:
bash
uv run relay_mcp.py --transport http --port 8888 --host 0.0.0.0
Only do this behind a reverse proxy or firewall — the MCP HTTP endpoint itself
has no built-in authentication, so binding it to 0.0.0.0 on an open network
exposes every relay tool call to anyone who can reach the port.
Security
The MCP server provides significant security advantages over shell-based integrations:
No shell execution — all operations are Python function calls via JSON-RPC, eliminating command injection risks
No CLI arguments — credentials and tokens are never passed as process arguments (invisible in ps output)
Automatic token management — the server handles login, JWT refresh, and token lifecycle internally; the agent never touches raw tokens
Typed inputs — all parameters are validated against JSON Schema before execution
Single persistent process — no per-call shell spawning, no environment leakage between invocations
Note: If you're using the OpenClaw skill (bash scripts), consider migrating to this MCP server for a more secure and maintainable integration.
The MCP server wraps Team Relay's REST API into standard MCP tools. Team Relay stores documents as Yjs CRDTs and syncs them to Obsidian clients in real-time. Changes made by the agent appear in Obsidian instantly — and vice versa.
