evc-team-relay-mcp

Проверяет, какой режим аутентификации активен (agent key или email/password), и авторизуется, если нужно. Не принимает аргументов; вызовите его первым, один раз, перед любым другим инструментом. В режиме agent key (задана переменная RELAY_AGENT_KEY или RELAY_AGENT_KEYS): вход не нужен, каждый запрос передаёт X-Agent-Key напрямую, этот инструмент просто сообщает, какой режим активен. В режиме email/password: авторизуется с помощью переменных окружения RELAY_EMAIL и RELAY_PASSWORD. Полученный токен хранится внутри инструмента; последующие вызовы инструментов используют его автоматически - вам никогда не придётся передавать его самостоятельно.

Зарезервировано для удаления отдельных файлов; пока недоступно на сервере. Всегда выбрасывает исключение: у control-plane нет маршрута DELETE для отдельного файла folder-share НИ В ОДНОМ режиме аутентификации (agent-key или JWT). Дело не в разнице между JWT и agent-key, удаление отдельных файлов просто ещё не реализовано на стороне сервера. Учтите, это не связано с политикой записи только для agent-key, которая управляет upsert_file: даже когда (или если) маршрут удаления появится, он будет следовать той же политике (только agent-key, JWT только для чтения). Аргументы: share_id: UUID folder-share. file_path: Путь к файлу внутри папки (например, "old-note.md").

Перечисляет все файлы в общей папке с их метаданными. Только чтение; не загружает содержимое файлов (для этого используйте read_file). В режиме agent-key (заданы RELAY_AGENT_KEYS или RELAY_AGENT_KEY): использует endpoint agent-key; share_id может быть UUID или веб-слагом. В режиме email/пароль: share_id должен быть UUID. Args: share_id: UUID или веб-слаг общего доступа к папке, например "a1b2c3d4-..." или "research-vault". Returns: Объект с share_id и картой файлов (path -> metadata). Точный набор ключей метаданных для каждого файла управляется сервером, поэтому здесь используется свободная структура dict[str, Any], а не строгая схема с фиксированными полями.

Перечисляет общие папки и документы, к которым есть доступ у этого ключа или аккаунта. Перечисляет только то, на что выдан режим авторизации или ключ - доступ не создаёт и не меняет. Пример: list_shares(kind="folder"). В режиме нескольких ключей (задан RELAY_AGENT_KEYS): возвращает метаданные по каждому share, для которого настроен ключ; данные берутся через авторизацию по agent-key отдельно для каждого share. RELAY_AGENT_KEYS обычно строится по UUID share, но endpoint с чистыми метаданными share (/v1/web/shares/{ref}) разрешает только веб-слаги: UUID там всегда отдаёт 404. В таком случае инструмент переключается на files-index endpoint, адресуемый по UUID. Он доказывает, что share настоящий и доступный, но не может сообщить kind/path/visibility (вернётся kind="unknown" и file_count вместо них). Сбой по отдельному share (плохой ключ, не тот share, share действительно пропал) НИКОГДА не отбрасывается молча - он попадает в поле errors ответа. «Не удалось проверить этот share» и «проверил, его не существует» должны оставаться различимыми; именно схлопывание обоих случаев в пустой список и приводило к тому, что проблема с конфигом или авторизацией читалась как «у вас нет share». В режиме одного ключа (только RELAY_AGENT_KEY): возвращает пустой список - единственный ключ привязан к одному share, но к какому именно, неизвестно; вызывайте list_files или tr_search напрямую с известным share_id. В режиме email/password: возвращает все share, к которым у пользователя есть доступ. Аргументы: kind: Фильтр по типу share - "doc" или "folder". Пусто - значит все. owned_only: Если true, возвращает только share, принадлежащие пользователю (только в режиме email/password). Возвращает: При полном успехе: голый JSON-массив share (id, kind, path, visibility, user_role - или id/kind="unknown"/file_count для записей, разрешённых по UUID). Если какой-то share не удалось разрешить: JSON-объект {"shares": [...], "errors": {share_ref: "reason"}} вместо молча укороченного массива.

Зарезервировано для живого содержимого документа; пока недоступно на сервере, используйте read_file. Всегда выбрасывает исключение: у control-plane нет REST-маршрута для чтения живого содержимого документа по ID ни для общих ресурсов типа DOC, ни для doc_id файла в общем ресурсе-папке (этого понятия нет в текущей модели синхронизации папок на основе CAS). Это реальный пробел в бэкенде, а не ограничение agent-key против JWT. Вместо этого используйте read_file для общих ресурсов-папок: он работает и в режиме agent-key, и в режиме JWT. Аргументы: share_id: UUID общего ресурса (для проверки ACL). doc_id: UUID документа. По умолчанию равен share_id для общих ресурсов документов. key: ключ общего типа Yjs. По умолчанию "contents".

Читает один файл из общей папки по его пути. Только чтение. Возвращает полное содержимое файла одним ответом, частичного или диапазонного чтения нет. В режиме agent-key (когда задан RELAY_AGENT_KEY): получает через endpoint загрузки agent-key; share_id может быть UUID или web slug. В режиме email/пароль: получает через тот же CAS endpoint загрузки, что и режим agent-key, через Bearer JWT вместо X-Agent-Key; share_id должен быть UUID. Аргументы: share_id: UUID или web slug общей папки. file_path: путь к файлу внутри папки (например, "Marketing/plan.md"). Возвращает: {"path", "content", "format"} при успехе или {"error": ...}, если файл не существует. Это две разные формы ответа при одном и том же результате, эквивалентном HTTP-статусу 200, поэтому используется dict[str, Any], а не строгая схема по полям (более строгая схема отклонила бы форму ошибки как недопустимый вывод).

Находит файлы в общей папке по совпадению без учёта регистра в пути или имени. Только чтение; не скачивает содержимое файлов (для этого используйте read_file). Пример: tr_search(share_id="research-vault", query="roadmap"). В режиме agent-key (RELAY_AGENT_KEY задан): share_id может быть UUID или web slug. В режиме email/password: share_id должен быть UUID. Аргументы: share_id: UUID или web slug общей папки. query: Строка поиска, которая сопоставляется с путями файлов без учёта регистра. limit: Максимальное число возвращаемых результатов (по умолчанию 20). Возвращает: JSON-список совпавших файлов: [{"id": doc_id_or_null, "title": filename_without_ext, "path": full_path, "relay_url": "relay://<slug>/<path>", "updated_at": null}]

Создаёт или перезаписывает файл в общей папке; он синхронизируется в хранилища подписчиков. Только с ключом агента. Доступ на запись только с ключом агента, так и задумано - это санкционированная постоянная политика (а не временный пробел): режим ключа агента - единственный разрешённый путь записи в этом MCP-сервере. Режим ключа агента (задан RELAY_AGENT_KEY): - share_id может быть UUID общей папки или веб-слагом (например, "research-vault") - Для общих папок используется /sync-upload → файл попадает в хранилище синхронизации CRDT и появляется в локальных хранилищах Obsidian у подписчиков на следующем цикле синхронизации - Для общих документов происходит откат к /upload (только веб-публикация) - list_files, read_file и tr_search тоже работают с тем же ключом агента Режим email/пароль (JWT) - всегда выбрасывает исключение; намеренно только для чтения. Для произвольной (не опубликованной в вебе) общей папки нет маршрута записи, доступного по JWT, и даже если бы он существовал, режим JWT по политике остаётся только для чтения. Для записи используйте режим ключа агента. Аргументы: share_id: UUID общей папки (режим email/пароль) или веб-слаг (режим ключа агента). file_path: Путь к файлу внутри общей папки (например, "notes/todo.md"). content: Полное текстовое содержимое для записи. Возвращает: Объект с path, size/operation и необязательным public_url (режим ключа агента). Точный набор ключей задаёт сервер (плюс добавленный здесь ключ "operation"), отсюда dict[str, Any].

Зарезервировано для записи живых документов; на сервере пока недоступно, используйте upsert_file. Всегда вызывает исключение: у control-plane нет REST-маршрута для записи живого содержимого документа по ID (содержимое doc-share доступно только через CRDT/WebSocket). Это реальный пробел в бэкенде в ОБОИХ режимах (agent-key и JWT), а не ограничение agent-key против JWT. Но если бы такой маршрут когда-либо добавили, то согласно принятой политике записи (только через agent-key) режим JWT всё равно остался бы только для чтения. Аргументы: share_id: UUID общего ресурса (для проверки ACL). doc_id: UUID документа. content: Полное текстовое содержимое для записи (заменяет весь документ). key: Ключ общего типа Yjs. По умолчанию "contents".