authenticateLABSCO SUMMARY
A tool list that tells you which tools do not work.
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.
What it is
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.
What you get
- The working path:
list_sharesto find accessible shares,list_filesto list a folder share,read_fileto read one by path, andupsert_fileto create or update one tr_searchfor searching in email/password mode, andauthenticate, 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_documentanddelete_filealways 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
pscan see them, typed inputs validated against JSON Schema, and one persistent process instead of a spawn per call
Requirements
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.
Setup effort
One command plus credentials — uvx evc-team-relay-mcp, then supply credentials
USE CASES
Letting an agent read your notes
List the shares, list the files in the folder share you want, and read the one you need by path.
Having an agent write a note back into the vault
Use an agent key rather than email and password — it is the only mode where creating or updating a file works, and the change shows up in Obsidian in real time.
Giving an agent read-only access on purpose
Configure email and password instead; write attempts raise a clear error naming agent-key mode as the fix, rather than a confusing 404.
Running it for a team on a server
Start it with the HTTP transport bound to localhost and reach it over an SSH tunnel, since the endpoint has no authentication of its own.
9 tools
Listed in project docs. Your client may show a different list.
list_shareslist_filesread_filetr_searchupsert_fileread_documentwrite_documentdelete_fileBEFORE YOU INSTALL
What to know first
Tools you get
9 tools named in the project's documentation.
Requires
- uvx on PATH
- Python 3.10+
- RELAY_CP_URL in your environment
- RELAY_AGENT_KEY in your environment, or RELAY_EMAIL and RELAY_PASSWORD (read-only mode)
INSTALLATION
Connect your client
Server setup
uvx evc-team-relay-mcpMCP Clients
Claude Code — agent key
{
"mcpServers": {
"evc-relay": {
"command": "uvx",
"args": [
"evc-team-relay-mcp"
],
"env": {
"RELAY_CP_URL": "<YOUR_RELAY_CP_URL>",
"RELAY_AGENT_KEY": "<YOUR_RELAY_AGENT_KEY>"
}
}
}
}Claude Code — email login
{
"mcpServers": {
"evc-relay": {
"command": "uvx",
"args": [
"evc-team-relay-mcp"
],
"env": {
"RELAY_CP_URL": "<YOUR_RELAY_CP_URL>",
"RELAY_EMAIL": "<YOUR_RELAY_EMAIL>",
"RELAY_PASSWORD": "<YOUR_RELAY_PASSWORD>"
}
}
}
}Codex
[mcp_servers.evc-relay]
type = "stdio"
command = "uvx"
args = ["evc-team-relay-mcp"]
[mcp_servers.evc-relay.env]
RELAY_CP_URL = "<YOUR_RELAY_CP_URL>"
RELAY_AGENT_KEY = "<YOUR_RELAY_AGENT_KEY>"Any MCP client — HTTP
git clone https://github.com/entire-vc/evc-team-relay-mcp.git
cd evc-team-relay-mcp && uv syncWith RELAY_CP_URL and RELAY_AGENT_KEY (or RELAY_EMAIL and RELAY_PASSWORD) set in that shell, start the server over HTTP and leave it running:
uv run relay_mcp.py --transport http --port 8888Then point the client at the local endpoint:
{
"mcpServers": {
"evc-relay": {
"type": "streamable-http",
"url": "http://127.0.0.1:8888/mcp"
}
}
}Clients spell the "type" value differently: Claude Code and VS Code use "http", Cline uses "streamableHttp", and Roo Code uses "streamable-http". Claude Desktop does not accept a URL entry in its config file.