v1.5 — переработка MCP для Cursor

Зачем отдельный трек

В v1.4 добавлены type: "stdio" в генерируемые .mcp.json и .cursor/mcp.json (bootstrap). Это соответствует документации Cursor для stdio-транспорта, но не снимает наблюдаемую проблему: инструменты TAUSIK по-прежнему не попадают в тот контур, через который Composer / файловое зеркало MCP (mcps/ в проекте Cursor) получает список доступных серверов.

Гипотеза «сломан bootstrap или сервер» для этого кейса не подтверждается: venv, импорт пакета mcp, наличие .cursor/scripts/, ручной запуск server.py без немедленного traceback.

Что показало расследование (2026-05-08)

1. workbench.mcp.oauth.log

Все записи с префиксом project-0-claude-* помечаются как disconnected, тогда как cursor-ide-browser — connected. Файл лога назван oauth; для чистых stdio-процессов статус в этом канале не является надёжным индикатором «процесс не стартовал».

2. Mcp FileSystem Writer.log (ключевой)

На каждом старте окна повторяется цепочка:

1. cursor_mcp_lease_server_status — в списке есть четыре сервера (в т.ч. project-0-claude-tausik-project).
2. Сразу затем cursor_mcp_lease_snapshot_store — в списке остаётся только cursor-ide-browser.
3. fetchAndWrite: lease returned 26 tools across 1 clients — в зеркало попадает один клиент (браузер, 26 tools).

То есть реестр MCP «знает» про TAUSIK на уровне lease status, но слой snapshot для FS-writer не включает проектные stdio в тот же поток, что и браузер.

3. Сравнение с более ранней сессией (2026-05-06)

В том же логе для user-* (глобальные серверы из пользовательского профиля) при успешном подключении cursor_mcp_lease_snapshot_store включал user-codebase-rag, user-raven и т.д., и счётчики инструментов росли. Это опровергает идею «Cursor принципиально не умеет stdio» — умеет, но проектный префикс project-0-claude-* в наблюдаемых логах не проходит в snapshot так же, как глобальные user-*.

4. Разрыв с allowlist

workbench.mcp.allowlist.log иногда фиксирует вызовы tausik_* с ALLOWED. Это другой контур (разрешения), не эквивалентный наполнению каталога mcps/ для выбранного режима агента.

Цели для v1.5 (минимум)

1. Зафиксировать контракт хоста — таблица «что обещает Cursor docs» vs «что реально попадает в agent FS mirror» для проектного .cursor/mcp.json и корневого .mcp.json, обновлять по мере релизов Cursor.
2. Варианты обхода продукта (на выбор, не исключают друг друга):
   • локальный HTTP/SSE-адаптер поверх существующего stdio-сервера (отдельный процесс + URL в mcp.json), если хост стабильнее поднимает remote-транспорт;
   • использование Extension API Cursor (vscode.cursor.mcp.registerServer() — см. официальную документацию MCP), если поддерживается в целевых версиях;
   • скрипт диагностики в репозитории: проверка handshake MCP вне IDE (JSON-RPC initialize) + отчёт для issue в Cursor.
3. Документация пользователя: явная секция «Cursor + Composer vs CLI», без требования глобального ~/.cursor/mcp.json, если политика проекта это запрещает.
4. Upstream: один воспроизводимый отчёт в Cursor / форум с логами уровня FileSystem Writer (без раскрытия секретов).

Негативные сценарии (AC будущей реализации)

• При недоступности Cursor MCP CLI всё ещё возможен полный цикл .tausik/tausik (регрессия недопустима).
• Любой «обход» не должен ломать bootstrap-тесты и не должен требовать секретов в репозитории.

Связанные артефакты

• Epic / parity: v15-cross-ide-parity (упоминание в CHANGELOG 1.4).
• Bootstrap: bootstrap/bootstrap_generate.py (generate_mcp_json, generate_cursor_mcp_json).