Skip to main content
Glama

EVC Team Relay - MCP Server

PyPI Docker Hub License: MIT MCP Smithery Install via Spark

Give your AI agent read/write access to your Obsidian vault.

Your agent reads your notes, creates new ones, and stays in sync — all through the Team Relay API.

Works with Claude Code, Codex CLI, OpenCode, and any MCP-compatible client.


Quick Start

1. Install

Option A — from PyPI (recommended):

No installation needed — uvx downloads and runs automatically. Skip to step 2.

Option B — from source:

git clone https://github.com/entire-vc/evc-team-relay-mcp.git
cd evc-team-relay-mcp
uv sync   # or: pip install .

2. Configure your AI tool

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.

Add to .mcp.json in your project root or ~/.claude/.mcp.json:

{
  "mcpServers": {
    "evc-relay": {
      "command": "uvx",
      "args": ["evc-team-relay-mcp"],
      "env": {
        "RELAY_CP_URL": "https://cp.yourdomain.com",
        "RELAY_AGENT_KEY": "tr_agent_your_key_here"
      }
    }
  }
}
{
  "mcpServers": {
    "evc-relay": {
      "command": "uvx",
      "args": ["evc-team-relay-mcp"],
      "env": {
        "RELAY_CP_URL": "https://cp.yourdomain.com",
        "RELAY_EMAIL": "agent@yourdomain.com",
        "RELAY_PASSWORD": "your-password"
      }
    }
  }
}

Add to your codex.json:

{
  "mcp_servers": {
    "evc-relay": {
      "type": "stdio",
      "command": "uvx",
      "args": ["evc-team-relay-mcp"],
      "env": {
        "RELAY_CP_URL": "https://cp.yourdomain.com",
        "RELAY_AGENT_KEY": "tr_agent_your_key_here"
      }
    }
  }
}

Add to opencode.json:

{
  "mcpServers": {
    "evc-relay": {
      "command": "uvx",
      "args": ["evc-team-relay-mcp"],
      "env": {
        "RELAY_CP_URL": "https://cp.yourdomain.com",
        "RELAY_AGENT_KEY": "tr_agent_your_key_here"
      }
    }
  }
}

If you installed from source instead of PyPI, replace "command": "uvx" / "args": ["evc-team-relay-mcp"] with:

"command": "uv",
"args": ["run", "--directory", "/path/to/evc-team-relay-mcp", "relay_mcp.py"]

Environment variables:

Variable

Required

Description

RELAY_CP_URL

Yes

Control plane base URL

RELAY_AGENT_KEY

One of

Agent key from plugin settings — read + write (recommended)

RELAY_EMAIL

One of

Account email (email/password mode)

RELAY_PASSWORD

One of

Account password (email/password mode)

Ready-to-copy config templates are also in config/.

3. Use it

Your AI agent now has these tools:

Tool

Description

authenticate

Authenticate with credentials (auto-managed)

list_shares

List accessible shares (filter by kind, ownership)

list_files

List files in a folder share

read_file

Read a file by path from a folder share

read_document

Not implemented — no backend route in any auth mode, always raises

upsert_file

Create or update a file by path — agent-key mode only; raises in email/password (JWT) mode

write_document

Not implemented — no backend route in any auth mode, always raises

delete_file

Not implemented — no backend route in any auth mode, always raises

Typical workflow: list_shares -> list_files -> read_file / upsert_file

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 requires an agent key: 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.


Related MCP server: Obsidian Knowledge Management MCP Server

Remote Deployment (HTTP Transport)

For shared or server-side deployments, run as an HTTP server:

# 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:

{
  "mcpServers": {
    "evc-relay": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:8888/mcp"
    }
  }
}

If your MCP client runs on a different machine than the server, tunnel to the localhost-bound port instead of exposing it publicly:

# 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:

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.


How It Works

┌─────────────┐      MCP        ┌──────────────┐     REST API     ┌──────────────┐     Yjs CRDT      ┌──────────────┐
│  AI Agent   │ ◄────────────► │  MCP Server  │ ◄─────────────► │  Team Relay  │ ◄──────────────► │   Obsidian   │
│ (any tool)  │  stdio / HTTP  │ (this repo)  │    read/write   │   Server     │    real-time     │    Client    │
└─────────────┘                └──────────────┘                 └──────────────┘      sync         └──────────────┘

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.


Prerequisites

  • Python 3.10+ with uv (recommended) or pip

  • A running EVC Team Relay instance (self-hosted or hosted)

  • A user account on the Relay control plane


Part of the Entire VC Toolbox

Product

What it does

Link

Team Relay

Self-hosted collaboration server

repo

Team Relay Sync

Obsidian plugin for Team Relay

install / repo

Relay MCP

MCP server for AI agents

this repo

OpenClaw Skill

OpenClaw agent skill (bash)

repo

Local Sync

Vault <-> AI dev tools sync

repo

Spark MCP

MCP server for AI workflow catalog

repo

Community

MCP Badge Glama Smithery

License

MIT

Available Tools

8 tools
authenticateA

Authenticate with the Relay Control Plane.

Uses RELAY_EMAIL and RELAY_PASSWORD env vars. Returns a status message. The token is managed internally — subsequent tool calls use it automatically.

Inputs: no named parameters. Returns: result

delete_fileA

Delete a file from a folder share.

Removes the file from the folder's metadata registry. The file disappears from Obsidian on next sync.

Args: share_id: UUID of the folder share. file_path: File path within the folder (e.g. "old-note.md").

Returns: JSON with path and status.

Inputs: share_id (required), file_path (required). Returns: result

list_filesA

List files in a folder share.

Args: share_id: UUID of the folder share.

Returns: JSON with doc_id and files map (path -> {doc_id, type}).

Inputs: share_id (required). Returns: result

list_sharesA

List all accessible shares.

Args: kind: Filter by share type — "doc" or "folder". Empty for all. owned_only: If true, only return shares owned by the user.

Returns: JSON array of shares with id, kind, path, visibility, user_role.

Inputs: kind, owned_only. Returns: result

read_documentA

Read document content by doc_id (low-level).

For doc shares, omit doc_id — it defaults to share_id. For folder shares, pass the file's doc_id from list_files. Prefer read_file for folder shares.

Args: share_id: UUID of the share (for ACL check). doc_id: Document UUID. Defaults to share_id for doc shares. key: Yjs shared type key. Default "contents".

Returns: JSON with doc_id, content, format.

Inputs: share_id (required), key, doc_id. Returns: result

read_fileA

Read a file from a folder share by its path.

Resolves path -> doc_id automatically. This is the recommended way to read files from folder shares.

Args: share_id: UUID of the folder share. file_path: File path within the folder (e.g. "Marketing/plan.md").

Returns: JSON with doc_id, content, format, path.

Inputs: share_id (required), file_path (required). Returns: result

upsert_fileA

Create or update a file in a folder share.

Automatically detects whether the file exists:

  • Existing file -> updates content (PUT)

  • New file -> creates file and registers in folder metadata (POST)

This is the recommended way to write files to folder shares.

Args: share_id: UUID of the folder share. file_path: File path within the folder (e.g. "notes/todo.md"). content: Full text content to write.

Returns: JSON with doc_id, path, length, operation ("created" or "updated").

Inputs: content (required), share_id (required), file_path (required). Returns: result

write_documentA

Write content to a document by doc_id (doc shares only).

For folder shares, use upsert_file instead.

Args: share_id: UUID of the share (for ACL check). doc_id: Document UUID. content: Full text content to write (replaces entire document). key: Yjs shared type key. Default "contents".

Returns: JSON with doc_id, length.

Inputs: doc_id (required), content (required), share_id (required), key. Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 8 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose: authentication, managing shares, listing files, reading/writing via path or doc_id, and deleting files. No two tools overlap in functionality.

    Naming Consistency5/5

    All tools follow a consistent verb_noun snake_case pattern (e.g., list_files, upsert_file, read_document). There are no deviations or mixed conventions.

    Tool Count5/5

    With 8 tools, the set is well-scoped for managing files within shares. Each tool serves a specific operation, and the count is suitable for the domain without being excessive or insufficient.

    Completeness5/5

    The tool surface covers all core operations: authentication, listing shares and files, reading, writing (create/update), and deleting files. There are no obvious gaps for the intended purpose of managing files in folder and doc shares.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers