Most servers list every tool as if they all function. This one separates two unrelated facts and refuses to conflate them: some tools are restricted by auth mode, and three others have no backend route in any mode and always raise. It even explains why — CRDT content has no REST bridge, per-file delete has no route — and says plainly that switching credentials will not fix it. That saves the exact debugging session where you assume you have the wrong key.
An MCP server that wraps the Team Relay REST API, giving an agent access to an Obsidian vault synced through a self-hosted or hosted Relay instance. Team Relay stores documents as Yjs CRDTs and syncs them to Obsidian clients in real time, so a change the agent makes appears in Obsidian immediately, and the reverse.
- The working path: `list_shares` to find accessible shares, `list_files` to list a folder share, `read_file` to read one by path, and `upsert_file` to create or update one
- `tr_search` for searching in email/password mode, and `authenticate`, which is managed for you — the server logs in and refreshes tokens internally, so the agent never touches a raw token
- An explicit availability matrix rather than a flat tool list: with an agent key you get list, read and write on folder shares, which is the only write path in the server; with email and password you get list, search and read, read-only by design
- Three tools documented as not implemented in either mode — `read_document`, `write_document` and `delete_file` always raise, because the control plane has no backend route for them. Doc-share live content is CRDT and WebSocket only with no REST bridge, and per-file delete has no server-side route yet. Switching to an agent key will not make them work
- Security properties that come from being an MCP server rather than a shell wrapper: no shell execution and so no command injection, no credentials passed as process arguments where `ps` can see them, typed inputs validated against JSON Schema, and one persistent process instead of a spawn per call
A running Team Relay instance, self-hosted or hosted, and an account on its control plane. `RELAY_CP_URL` is always required. Then one of two auth modes: `RELAY_AGENT_KEY` — created in the Obsidian plugin under Team Relay settings → Agent Keys — which is the recommended path and the only one that can write; or `RELAY_EMAIL` and `RELAY_PASSWORD` for a dedicated agent account, which stays read-only. `RELAY_AGENT_KEYS` takes comma-separated share-and-key pairs for multi-share access. Python 3.10 or newer with `uv`; nothing to install ahead of time, since `uvx evc-team-relay-mcp` fetches and runs it. For shared deployments there is an HTTP transport that binds to `127.0.0.1` by default — the MCP HTTP endpoint has no built-in authentication, so reaching it from another machine should go through an SSH tunnel rather than binding it publicly. MIT licensed.
One command plus a key — uvx evc-team-relay-mcp, then supply credentials