Tetiva
Войти
Все разделы

Продвинутое

MCP-сервер

На этой странице

Внутри Tetiva работает MCP-сервер «Tetiva DevTools»: он публикует 32 инструмента, через которые ИИ-агент читает ваши воркспейсы, коллекции, запросы и окружения, создаёт новые и выполняет сохранённый запрос — с теми же окружениями, скриптами и историей, что и при нажатии Send. Ничего копировать в чат не нужно: агент подключается к приложению по адресу 127.0.0.1:9300.

Сервер объявляет только инструменты (tools). Ресурсов и промптов у него нет, и работает он ровно столько, сколько открыто окно приложения.

Включение#

Откройте настройки (Cmd/Ctrl+, или шестерёнка внизу панели слева) и найдите секцию MCP / DevTools:

  1. Переключатель Enable.
  2. Поле Port / address — по умолчанию 127.0.0.1:9300.
  3. Перезапустите приложение: под секцией появляется «Restart required to apply», сервер поднимается на старте.

После перезапуска строка Status показывает ● Running, а рядом — адрес SSE-эндпоинта.

MCP можно задать и переменными окружения: TETIVA_MCP=1 включает сервер, TETIVA_MCP_ADDR задаёт адрес. Старые имена GOPHERCOURIER_MCP и GOPHERCOURIER_MCP_ADDR продолжают работать. Если переменные заданы, поля в настройках блокируются, и там написано «Managed by environment variables».

Подключение агента#

Сервер требует токен доступа. Кнопка Copy config в настройках кладёт в буфер готовый фрагмент для выбранного клиента — Claude Desktop, Cursor или просто URL — уже с токеном. Там, где в конфиге есть только URL, токен едет в строке запроса:

{
  "mcpServers": {
    "tetiva": {
      "url": "http://127.0.0.1:9300/sse?token=ВАШ_ТОКЕН"
    }
  }
}

Cursor умеет заголовки — так токен не попадает в URL:

{
  "mcpServers": {
    "tetiva": {
      "url": "http://127.0.0.1:9300/sse",
      "headers": { "Authorization": "Bearer ВАШ_ТОКЕН" }
    }
  }
}

Claude Code принимает тот же адрес одной командой:

claude mcp add --transport sse tetiva http://127.0.0.1:9300/sse \
  --header "Authorization: Bearer ВАШ_ТОКЕН"

Кнопка копирования рядом с токеном в настройках кладёт в буфер само значение — именно оно нужно этой команде; Copy config отдаёт целый сниппет.

Конфиги, написанные до появления токена, после обновления перестают работать: сервер отвечает 401, пока токен не добавлен. Скопируйте свежий конфиг из настроек и замените им старую запись.

Приложение при этом должно быть запущено — агент разговаривает с живым окном, а не с файлом базы.

32 инструмента#

Воркспейсы (3). list_workspaces, get_workspace, create_workspace. Список отдаёт активный, удалённый и синхронизационный статус каждого воркспейса; создаётся всегда локальный.

Коллекции (6). list_collections, get_collection, create_collection, update_collection, move_collection, delete_collection. Вложенность задаётся через parent_id, перемещение проверяется на циклы, удаление мягкое и каскадное. Обновление использует оптимистичную блокировку: передайте текущую версию.

Запросы (7). list_requests, get_request, create_request, update_request, move_request, send_request, delete_request. Создание и обновление принимают HTTP, gRPC и GraphQL вместе с заголовками, авторизацией и скриптами. send_request бьёт по вашему API по-настоящему: подставляет переменные окружения, выполняет скрипты, возвращает статус, заголовки и тело и дописывает запись в историю.

Окружения (4). list_environments, get_environment, create_environment, delete_environment.

Переменные (3). list_variables, create_variable, delete_variable. Запись значений не ограничена, чтение — ограничено, см. ниже.

Синхронизация (9). sync_status, sync_push, sync_pull, sync_queue_list, sync_queue_clear, sync_resync, sync_pause, sync_resume, sync_disconnect_stream. Это отладочный набор для Tetiva Cloud: посмотреть состояние движка и очередь, форсировать отправку или приём, поставить воркспейс на паузу и снять с неё, оборвать поток событий один раз, чтобы проверить переподключение с backoff.

Безопасность#

Токен

Сервер требует токен. Он генерируется при первом запуске, хранится в базе приложения рядом с остальными настройками MCP и принимается двумя способами — Authorization: Bearer <токен> или ?token=<токен>, потому что не каждый клиент умеет и то и другое. Всё остальное получает 401, в теле которого написано, где взять рабочий конфиг. Проверяются оба эндпоинта — и SSE, и сообщений, так что утёкший идентификатор сессии сам по себе ничего не даёт.

Кнопка Regenerate в настройках меняет токен сразу, на живом сервере: все конфиги агентов со старым значением придётся обновить. Переключатель Require token выключает проверку. Это запасной выход для клиента, который не умеет ни заголовок, ни query, и осознанный шаг: с выключенной проверкой любой процесс на машине — включая вкладку браузера, которая ходит на 127.0.0.1, — читает все коллекции и переменные и выполняет запросы от вашего имени.

Адрес по умолчанию — loopback, адрес без хоста (:9300) приводится к 127.0.0.1:9300 при старте, в том числе в уже сохранённых настройках. Если вы осознанно указываете сетевой адрес, приложение оставляет его, но пишет предупреждение в лог и подсвечивает поле в настройках.

От чего токен не защищает: от того, кто и так читает ~/.tetiva/data.db. В этом файле лежит и сам токен, и всё остальное. Шифрование локальной базы — отдельная история.

Что инструменты маскируют

  • auth_data запросов и коллекций — всегда [redacted], тип авторизации при этом виден.
  • Значения переменных с флагом «секрет» — не возвращаются ни в list_variables, ни в get_environment, ни в ответе на создание переменной.
  • Значения заголовков с учётными данными — и в сохранённых запросах, и в ответе send_request: authorization, proxy-authorization, cookie, set-cookie, x-api-key, api-key, x-auth-token, x-access-token, x-csrf-token, x-session-token.
  • Метаданные gRPC с теми же именами — в gRPC-запросе токен лежит там, а не в заголовке.
  • Параметры запроса в URL: token, access_token, refresh_token, api_key, apikey, key, secret, password, sig, signature.

Значение, которое целиком является подстановкой {{variable}}, остаётся как есть: это имя переменной, а не сам секрет, и агенту нужно видеть, какая переменная в деле. Значение, где подстановка лишь вкраплена — session=abc; theme={{ui}}, — маскируется целиком: буквальная половина всё ещё секрет.

Осознанно не маскируем: тела запроса и ответа — без них send_request бесполезен для отладки, так что токен, вернувшийся в ответе на логин, придёт целиком, — pre- и post-скрипты и переменные без флага «секрет».

Маскирование не стоит вам данных. update_request и update_collection применяют ровно те аргументы, что вы передали, поэтому пропущенное поле сохраняет своё значение. Некоторые поля пропустить нельзя — чтобы изменить один заголовок, приходится присылать весь массив, — поэтому каждый [redacted], вернувшийся на запись, сопоставляется с тем, что хранится под тем же именем, и подменяется настоящим значением до сохранения. Маска, за которой ничего нет, не пишется, а отклоняется: create_request и create_collection отвечают ошибкой на [redacted] сразу, а при обновлении маска под именем, которому нечего сопоставить — например, у только что добавленного заголовка, — возвращается ошибкой с просьбой прислать настоящее значение. С синхронизацией отдельная история — она описана на странице Синхронизация.

Каталог данных#

Инструменты работают с той же базой, что и окно приложения, — ~/.tetiva/data.db. Каталог переопределяется переменной TETIVA_DATA_DIR (старое имя GOPHERCOURIER_DATA_DIR продолжает работать как запасное). Это удобно, когда нужен второй экземпляр Tetiva с отдельной базой и своим портом MCP: тогда агент не заденет рабочие коллекции. Подробнее о расположении данных — на странице Настройки.

обновлено