evc-team-relay-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RELAY_EMAIL | Yes | The email address for your Team Relay agent account | |
| RELAY_CP_URL | Yes | The URL of your Relay control plane (e.g., https://cp.yourdomain.com) | |
| RELAY_PASSWORD | Yes | The password for your Team Relay agent account |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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. |
| 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}). |
| 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. |
| 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. |
| upsert_fileA | Create or update a file in a folder share. Automatically detects whether the file exists:
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"). |
| 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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
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.
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.
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.
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.