evc-team-relay-mcp

Аутентификация с Relay Control Plane. В режиме agent-key (установлена RELAY_AGENT_KEY): логин не требуется: каждый запрос напрямую содержит X-Agent-Key. В режиме email/пароль: используются переменные окружения RELAY_EMAIL и RELAY_PASSWORD. Токен управляется внутренне; последующие вызовы инструмента используют его автоматически.

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

Перечисляет файлы в общей папке. В режиме agent-key (установлены RELAY_AGENT_KEYS или RELAY_AGENT_KEY): используется endpoint agent-key; share_id может быть UUID или веб-слагом. В режиме email/password: share_id должен быть UUID. Аргументы: share_id: UUID или веб-слаг общей папки. Возвращает: JSON с share_id и картой файлов (path -> file).

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

НЕ РЕАЛИЗОВАНО - нет бэкенд-маршрута ни в одном режиме аутентификации, всегда вызывает исключение. Управляющая плоскость не имеет REST-маршрута для чтения живого содержимого документа по ID ни для ресурсов типа DOC, ни для doc_id файла в общей папке (этой концепции нет в текущей модели синхронизации папок на основе CAS). Это реальный пробел в бэкенде, а не ограничение, обусловленное конкуренцией агент-ключа и JWT. Для общих папок используйте read_file (работает как в режиме агент-ключа, так и в режиме JWT). Смотрите TR-05 (дополнение). Аргументы: share_id: UUID ресурса (для проверки ACL). doc_id: UUID документа. По умолчанию равен share_id для ресурсов типа doc. key: Ключ общего типа Yjs. По умолчанию "contents".

Читает файл из общей папки по его пути. В режиме ключа агента (установлен RELAY_AGENT_KEY): загружает через точку скачивания ключа агента; share_id может быть UUID или веб-слагом. В режиме email/пароль: автоматически преобразует путь в doc_id; share_id должен быть UUID. Параметры: share_id: UUID или веб-слаг общей папки. file_path: Путь к файлу внутри папки (например "Marketing/plan.md"). Возвращает: JSON с содержимым, форматом и типом.

Поиск документов TR по пути/имени в общей папке. В режиме агент-ключа (установлен RELAY_AGENT_KEY): share_id может быть UUID или web slug. В режиме email/пароль: 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-сервере. См. TR-05 (#0cdd5328) и последующее обсуждение (#0a74769a) для ознакомления с решением. Режим ключа агента (переменная RELAY_AGENT_KEY задана): - share_id может быть UUID общей папки или веб-алиасом (например, "research-vault") - Для папок (folder shares) используется /sync-upload: файл попадает в CRDT-синхронизатор и появляется в локальных хранилищах Obsidian у подписчиков при следующем цикле синхронизации - Для документов (doc shares) используется /upload (только веб-публикация) - list_files, read_file и tr_search также работают с тем же ключом агента Режим email/пароль (JWT) — всегда вызывает ошибку; намеренно только для чтения. В JWT нет ни одного маршрута записи для произвольной (не опубликованной в вебе) общей папки, и даже если бы он существовал, политика оставляет JWT-режим только для чтения. Для записи используйте режим ключа агента. Аргументы: share_id: UUID общей папки (режим email/пароль) или веб-алиас (режим ключа агента). file_path: Путь к файлу внутри общей папки (например, "notes/todo.md"). content: Полное текстовое содержимое для записи. Возвращает: JSON с path, size/operation и опциональным public_url (режим ключа агента).

НЕ РЕАЛИЗОВАНО — нет маршрута на бэкенде ни в одном режиме аутентификации, всегда вызывает исключение. В control-plane нет REST-маршрута для записи живого содержимого документа по идентификатору (содержимое doc-share доступно только через CRDT/WebSocket). Это настоящий пробел в бэкенде КАК в режиме agent-key, так и в режиме JWT, а не ограничение одного режима по сравнению с другим — но если бы маршрут когда-либо добавили, согласно утверждённой политике записи (только agent-key имеет право на запись), режим JWT всё равно оставался бы доступным только для чтения. См. дополнение TR-05. Args: share_id: UUID шары (для проверки ACL). doc_id: UUID документа. content: полный текст для записи (заменяет весь документ). key: ключ общего типа Yjs. По умолчанию "contents".