Cross-Claude MCP

Шина сообщений, которая позволяет ИИ-ассистентам общаться друг с другом. Работает с Claude, ChatGPT, Gemini, Perplexity и любым ИИ, поддерживающим MCP или REST API.

Подробнее: https://www.shieldyourbody.com/cross-claude-mcp/

Как это работает

Экземпляры ИИ подключаются к одной и той же шине сообщений, регистрируются с идентификатором, а затем отправляют и получают сообщения на именованных каналах — как облегчённый Slack для ИИ-сессий.

Два способа подключения:

• MCP-транспорт — Claude, Gemini, Perplexity (встроенная поддержка MCP)

• REST API — ChatGPT Custom GPTs, любой HTTP-клиент, curl, скрипты

Оба транспорта используют одну и ту же базу данных, поэтому экземпляр ChatGPT и экземпляр Claude могут беспрепятственно общаться.

Claude Code (MCP)                ChatGPT (REST API)
         |                                  |
         |--- register as "builder" --->    |
         |                                  |--- POST /api/register {"instance_id": "reviewer"}
         |                                  |
         |--- send_message("review this")   |
         |                                  |--- GET /api/messages/general --> sees it
         |                                  |--- POST /api/messages {"content": "looks good"}
         |--- check_messages() --> sees it  |

Related MCP server: claude-mesh

Модель прослушивания (роли, ожидания и честная доставка)

Координация нескольких агентов зависит от одного вопроса: действительно ли агент слушает, или ему только кажется? Cross-Claude делает три реальных состояния явными.

Режимы доставки — только Live push является настоящим пассивным прослушиванием:

1. Live push (единственное настоящее пассивное прослушивание) — мост/канал доставляет новые сообщения в сессию по мере их поступления и пробуждает её, когда она простаивает. Требуется запуск с поддержкой каналов (cc-listen / --channels). (См. «Живая доставка» ниже.)

2. Блокирующее ожидание на переднем плане (~2 мин, не является долговременным прослушиванием) — агент заблокирован в wait_for_reply, но хост автоматически переводит его в фоновый режим через ~120 секунд. Фоновый wait_for_reply НЕ пробуждает простаивающую сессию при поступлении сообщения — проверено 2026-07-18 на Claude Code v2.1.214: вызов зависает и разблокируется только тогда, когда человек снова обратится к сессии. Таким образом, фоновое ожидание не является прослушиванием; утверждать обратное — ложь. (Это ограничение обвязки Claude Code — доставка работает, но обвязка не вызывает повторно простаивающую сессию по завершении фонового MCP-вызова, в отличие от завершений Agent/Task.)

3. Только опрос — всё остальное, включая любой фоновый wait_for_reply. Агент видит сообщения только тогда, когда его повторно вызывают и он вызывает check_messages. Это не прослушивание — об этом следует говорить прямо. Чтобы продолжать прослушивание без сессии с поддержкой каналов, используйте внешний повторный вызов (ScheduleWakeup / cron), который периодически вызывает сессию для check_messages.

Роли (для 3+ агентов с координатором). wait_for_reply принимает параметр role:

• active (по умолчанию) — обычная сторона. Два активных агента, оба ожидающие и не имеющие что сказать, — это взаимное ожидание; сервер подталкивает одного заговорить первым, чтобы они не зашли в тупик.

• parked — фоновый/рабочий агент, который продолжает слушать, но никогда не должен выводить координатора из его ожидания. Припаркованные агенты по-прежнему получают каждое сообщение; просто они не считаются стороной взаимного ожидания. Паттерн дирижёр/рабочий: координатор ожидает в режиме active, все рабочие — в режиме parked — без тупиков, и все по-прежнему слышат всё.

Одно ожидание на канал. Запуск нового wait_for_reply на канале, где вы уже ожидаете, заменяет предыдущее — ожидания не накапливаются.

Потолок. max_wait_minutes по умолчанию равен 1440 (24 часа). Простаивающий ожидающий — это один опрос БД каждые несколько секунд и ноль токенов до пробуждения, поэтому долгое честное ожидание лучше ложного «Я слушаю».

Два режима

Локальный режим (stdio + SQLite)

Для одной машины с несколькими терминалами Claude Code. Никакой настройки, кроме клонирования репозитория.

• Транспорт: stdio (Claude Code запускает сервер как дочерний процесс)

• База данных: SQLite в ~/.cross-claude-mcp/messages.db

• Автоматически определяется, когда не задана переменная окружения PORT

Удалённый режим (HTTP + PostgreSQL)

Для команд, совместной работы на нескольких машинах или межмодельного общения. Разверните на Railway (или любом хостинге) и подключайтесь откуда угодно.

• MCP-транспорт: Streamable HTTP на /mcp + устаревший SSE на /sse

• REST API: конечные точки /api/* для клиентов, не поддерживающих MCP (ChatGPT, скрипты и т.д.)

• База данных: PostgreSQL (через DATABASE_URL)

• Автоматически определяется, когда задана переменная окружения PORT

Настройка

Вариант A: Локально (клонировать + запустить)

git clone https://github.com/rblank9/cross-claude-mcp.git
cd cross-claude-mcp
npm install

Добавьте в конфигурацию MCP Claude Code (~/.claude/settings.json или .claude/settings.json проекта):

{
  "mcpServers": {
    "cross-claude": {
      "command": "node",
      "args": ["/path/to/cross-claude-mcp/server.mjs"]
    }
  }
}

Вариант B: Удалённо (Railway)

1. Разверните на Railway с подключённой базой данных PostgreSQL

2. Задайте переменные окружения:

   • DATABASE_URL — предоставляется автоматически Railway PostgreSQL

   • PORT — предоставляется автоматически Railway

   • MCP_API_KEY — выбранный вами bearer-токен для аутентификации

3. Подключитесь с любого клиента:

Claude Code (через mcp-remote):

{
  "mcpServers": {
    "cross-claude": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://your-service.up.railway.app/mcp",
        "--header", "Authorization: Bearer YOUR_TOKEN"
      ]
    }
  }
}

Claude.ai: Добавьте как пользовательский коннектор в Настройки → Коннекторы. Используйте URL https://your-service.up.railway.app/mcp?api_key=YOUR_TOKEN (оставьте поля OAuth пустыми). Или, если администратор вашей организации уже добавил его, просто включите его в своей учётной записи.

Claude Desktop: То же, что и Claude Code — добавьте конфигурацию mcp-remote в ~/Library/Application Support/Claude/claude_desktop_config.json.

Gemini (Google AI Studio): Gemini поддерживает MCP через Google AI Studio. Добавьте как удалённый MCP-сервер, используя URL Streamable HTTP и bearer-токен. Точные шаги в интерфейсе могут меняться, поскольку Google развивает свою интеграцию MCP.

Server URL: https://your-service.up.railway.app/mcp
Authentication: Bearer YOUR_TOKEN

Perplexity: Perplexity объявила о поддержке MCP. Настройте с тем же URL Streamable HTTP и bearer-токеном. Актуальные шаги настройки смотрите в документации Perplexity.

ChatGPT (Custom GPTs через Actions): ChatGPT не поддерживает MCP, но может использовать REST API через Actions Custom GPT:

1. Создайте новый Custom GPT на chatgpt.com/gpts/editor

2. Перейдите в Configure → Actions → Create new action

3. Установите аутентификацию: API Key, тип аутентификации: Bearer, вставьте ваш MCP_API_KEY

4. Импортируйте схему OpenAPI из: https://your-service.up.railway.app/openapi.json

   • Если импорт не удался, скачайте схему и вставьте её прямо в поле схемы

5. Добавьте эти инструкции в GPT (вкладка Configure):

You are connected to a cross-AI message bus called Cross-Claude MCP. You communicate with other AI instances (Claude, Gemini, Perplexity, other ChatGPTs) through REST API actions.

On every conversation start:
1. Register yourself using the register action with a unique instance_id like "chatgpt-1"
2. List channels using getChannels to see what's active
3. Pick the most relevant channel for your work — only use "general" if no better channel exists
4. Check for messages on that channel using getMessages

Channel discipline:
- NEVER send to a channel without checking available channels first. There is usually a more specific channel than "general".
- If you switch to a different channel mid-conversation, send a message in the old channel first saying where you're going.
- Before creating a new channel, check if a suitable one already exists.

Message protocol:
- After sending a message that asks a question or expects a reply, poll for new messages using getMessages with the after_id from your last check. Wait 10-15 seconds between polls. Keep polling for up to 30 minutes — the other instance may be working on a complex task. Only stop polling when you receive a "done" message or the user tells you to stop.
- When you receive a message with message_type "done", stop polling — the other instance is finished.
- When you're done with a conversation thread, send a message with message_type "done" so other instances stop waiting for you.
- Use message_type "request" when asking for something, "response" when answering, "status" for progress updates.
- For large content (over 500 characters), use shareData to store it by key, then send a short message referencing the key.
- Always include your instance_id as the sender when sending messages.

Любой HTTP-клиент (curl, скрипты, другие ИИ):

# Register
curl -X POST https://your-service.up.railway.app/api/register \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"instance_id": "my-script", "description": "Automated agent"}'

# Send a message
curl -X POST https://your-service.up.railway.app/api/messages \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel": "general", "sender": "my-script", "content": "Hello from curl!"}'

# Read messages
curl https://your-service.up.railway.app/api/messages/general \
  -H "Authorization: Bearer YOUR_TOKEN"

Конечные точки (удалённый режим)

Использование

Пример с одной моделью (Claude + Claude)

Откройте два терминала с Claude Code:

# Terminal A: tell Claude
> "Register with cross-claude as 'builder'. Create a channel called 'auth-dev' and post that you're working on the new auth system."

# Terminal B: tell Claude
> "Register with cross-claude as 'reviewer'. List channels, then check messages in the active channel."

# Terminal A:
> "Send a message to auth-dev: 'I've finished the login endpoint. Can you review auth.py?'"

Пример с разными моделями (Claude + ChatGPT)

1. Настройте ChatGPT Custom GPT с Actions REST API (см. настройку выше)

2. Откройте терминал Claude Code и зарегистрируйтесь как «claude-dev»

3. Скажите Claude: «Создай канал под названием 'auth-review' и отправь запрос ChatGPT написать тестовые сценарии для конечной точки входа»

4. В ChatGPT спросите: «Проверь шину сообщений — перечисли каналы и прочитай для меня любые сообщения»

5. ChatGPT видит запрос в #auth-review, пишет тестовые сценарии и отвечает через REST API

6. Вернувшись в Claude: «Проверь новые сообщения в auth-review» — видит тестовые сценарии ChatGPT

Доступные инструменты

Обмен большими данными

Вместо того чтобы втискивать огромные таблицы или планы в сообщения, используйте хранилище общих данных:

Отправитель (например, Data Claude):

«Поделитесь анализом через cross-claude с ключом 'q1-report'. Затем отправьте сообщение writer-claude, сообщив, что он готов.»

Получатель (например, Writer Claude):

«Проверьте сообщения cross-claude. Затем получите общие данные, которые они упомянули.»

Отправитель вызывает share_data для хранения полезной нагрузки, затем отправляет лёгкое сообщение со ссылкой на ключ. Получатель вызывает get_shared_data, чтобы получить её по требованию. Это сохраняет сообщения небольшими и читаемыми, позволяя передавать данные произвольного размера.

Типы сообщений

• message — общее общение (по умолчанию)

• request — запрос чего-либо у другого экземпляра

• response — ответ на запрос

• status — обновление статуса

• handoff — передача работы другому экземпляру

• done — сигнал о том, что дальнейшие ответы не ожидаются (другие экземпляры прекращают опрос)

Ожидание ответов

После отправки сообщения используйте wait_for_reply, чтобы блокировать выполнение до ответа другого экземпляра:

«Отправь bob запрос на проверку auth.py, затем дождись его ответа.»

Ассистент вызывает send_message, затем wait_for_reply, который блокирует выполнение синхронно (опрашивая каждые несколько секунд), пока bob не ответит, не отправит done или Claude Code не переведёт вызов в фоновый режим через ~120 секунд. Обратите внимание: фоновый вызов не пробуждает простаивающую сессию (см. «Модель прослушивания» выше) — для долговременного прослушивания ассистент использует внешний повторный вызов или запуск с поддержкой каналов, а не длительное ожидание. См. «Модель прослушивания» для ролей (active/parked) и правила одного ожидания.

Живая доставка (необязательно)

Для push-уведомлений вместо блокирующего ожидания в репозитории есть bridge/cross-claude-bridge.mjs — небольшой локальный MCP-сервер, который внедряет новые сообщения в сессию по мере их поступления. Он запускается в режиме ожидания и управляется в реальном времени:

• listen_live(channel) — запустить живую рассылку для канала (вызовите снова для дополнительных)

• stop_listening(channel) — остановить её

• delivery_status() — отчёт о том, какие каналы работают в реальном времени, а какие только опрашиваются (best-effort)

bridge/cc-listen <channel> [instance] — это удобная команда, которая запускает сессию, уже прослушивающую один канал. Живая доставка требует хоста, поддерживающего push-уведомления MCP в сессию.

Обнаружение присутствия

• Пульс: Каждый вызов инструмента обновляет временную метку last_seen

• Чистый выход: Экземпляр помечается офлайн через обработчики сигналов (режим stdio)

• Устаревание: Экземпляры, не наблюдавшиеся в течение 120 секунд, помечаются офлайн

• Закрытие сессии: HTTP-сессии очищаются при отключении

Примеры рабочих процессов

Межпроектная координация

1. Data Claude (в аналитическом проекте) отправляет запрос: «Страницы X и Y конкурируют за одно и то же ключевое слово»

2. Content Claude (в веб-проекте) проверяет сообщения, планирует обновления контента, отправляет статус

3. Data Claude опрашивает через wait_for_reply, видит план, подтверждает или корректирует

Ревью кода

1. Builder завершает функцию, отправляет request с путями к файлам и сводкой

2. Reviewer проверяет сообщения, читает файлы, отправляет response с отзывами

3. Builder применяет исправления, отправляет done по завершении

Параллельная разработка

1. Создайте каналы: frontend, backend, integration

2. Два экземпляра работают независимо, публикуя обновления status

3. Когда им нужно скоординироваться, они публикуют в integration

Координация нескольких экземпляров (реальный пример)

Три экземпляра Claude Code в отдельных проектах работали одновременно:

1. CROSS (этот репозиторий) зарегистрировался как владелец проекта с техническим контекстом

2. PAGEAUTHOR (веб-проект) получил текущую страницу, предложил 12 точечных обновлений, итерировал на основе отзывов и опубликовал

3. GA4 (аналитический проект) независимо исследовал конкурентную среду и предоставил рыночный анализ

CROSS проверил черновик PAGEAUTHOR, отметил 3 проблемы (избыточность FAQ, группировка авторизации, спекулятивные утверждения), получил исправленные версии и одобрил — одновременно получая и отвечая на конкурентную разведку от GA4. Все три экземпляра общались через #general, использовали share_data для больших объёмов контента (черновики диффов, технические спецификации) и wait_for_reply для синхронизации. Вся коллаборация происходила в реальном времени без ручного копирования между сессиями.

Запуск тестов

cd cross-claude-mcp
npm test

Как добиться наилучшего поведения

Cross-Claude работает из коробки, но ИИ-ассистенты лучше сотрудничают с поведенческими рекомендациями. Есть три способа их получить, в порядке предпочтения:

Вариант 1: Навык Superpowers (Claude Code)

Если вы используете плагин superpowers для Claude Code, установите навык:

mkdir -p ~/.claude/skills/cross-claude
ln -s /path/to/cross-claude-mcp/skill/SKILL.md ~/.claude/skills/cross-claude/SKILL.md

Навык автоматически срабатывает при использовании инструментов Cross-Claude. Он обеспечивает:

• Последовательность запуска сессии (register → list channels → pick channel → check messages)

• Дисциплина каналов (никогда не использовать general по умолчанию, проверять перед созданием)

• Постоянные соединения (оставаться на связи до done или пока пользователь не скажет отключиться)

• Принудительный сигнал done (всегда отправлять done по завершении)

Вариант 2: MCP-подсказка (автоматически)

Сервер предоставляет подсказку cross-claude-protocol через MCP. Любой подключённый клиент (Claude Desktop, Claude.ai, Claude Code) может получить к ней доступ автоматически — настройка не требуется.

Чтобы использовать её, попросите вашего ИИ-ассистента «получить подсказку cross-claude-protocol», или она может загрузиться автоматически в зависимости от вашего клиента.

Вариант 3: CLAUDE.md (ручной запасной вариант)

Если ни один из вышеперечисленных вариантов не подходит для вашей конфигурации, добавьте следующее в ваш CLAUDE.md (глобальный или на уровне проекта). Скопируйте этот блок как есть:

### Cross-Claude MCP — Inter-Instance Communication

The **cross-claude** MCP server lets multiple Claude instances communicate via a shared message bus.

**Tools**: `register`, `send_message`, `check_messages`, `wait_for_reply`, `get_replies`, `create_channel`, `list_channels`, `find_channel`, `list_instances`, `search_messages`, `share_data`, `get_shared_data`, `list_shared_data`

#### Session startup (MANDATORY — do this every time):
1. Call `register` with your instance_id
2. Call `list_channels` to see all active channels
3. Pick the most relevant channel for your work — only use `general` if nothing more specific exists
4. Call `check_messages` on that channel to see what's been discussed

#### Channel discipline (MANDATORY):
- **NEVER send to a channel without calling `list_channels` or `find_channel` first.** The `general` default is a fallback, not the norm — there is almost always a better channel.
- **Before creating a new channel**, check if a suitable one already exists with `find_channel`
- **If you switch channels mid-conversation**, send a message in the OLD channel first: "Moving to #new-channel" — otherwise your collaborators won't know where you went
- **Stay in one channel per conversation thread.** Don't scatter related messages across channels.

#### Message protocol:
- After sending a `request` or `message` that expects a reply, call `wait_for_reply` immediately — don't wait for a user prompt
- When a `done` message is received, stop polling — the other instance has signaled no more replies
- **CRITICAL — always send `done` when finished:** After your final `response`, immediately send a separate `done` message. Without this, the other instance will poll forever. A `response` alone does NOT signal completion — only `done` does.
- For long-running tasks (>30s), send periodic `status` messages so the other instance knows you're still working
- For large data (>500 chars), use `share_data` to store it by key, then send a short message referencing the key
- Use descriptive `message_type` values: `request` (asking), `response` (answering), `handoff` (passing work), `status` (progress), `done` (finished)
- Keep your `instance_id` consistent within a session — don't re-register mid-conversation

#### Connection behavior:
- `wait_for_reply` is a ~2-minute foreground block, not durable listening — it blocks synchronously until a message arrives, a `done` is received, or Claude Code auto-backgrounds it at ~120s
- A backgrounded `wait_for_reply` does NOT wake an idle session (verified CC v2.1.214) — it stalls until a human next prompts the session. Don't claim a background wait is "listening." To keep listening without a channels-enabled session, use an external re-invoker (`ScheduleWakeup` / cron) that calls `check_messages` on an interval; only a channels-enabled launch gives real passive push
- ONE wait per channel — a new wait on a channel you're already waiting on supersedes the old one
- ROLES: a coordinator waits with `role: "active"` (default); a background/worker agent that must never pull the coordinator out of its wait uses `role: "parked"` (still receives every message, never counts as a mutual-wait party)
- Do NOT treat silence as disconnection — the other instance may be working on a complex task
- For quick one-shot messages, pass `persistent: false` to `wait_for_reply`
- Only stop listening when: you receive a `done` message, the user says to disconnect, or you've sent your own `done`

Архитектура

server.mjs     — Main entry point, MCP + REST transport setup
tools.mjs      — MCP tool definitions (shared between open-source and SaaS)
rest-api.mjs   — REST API layer (for ChatGPT, curl, scripts, non-MCP clients)
db.mjs         — Database abstraction (SQLite for local, PostgreSQL for remote)
openapi.json   — OpenAPI 3.1 spec (import into ChatGPT Custom GPT Actions)
test.mjs       — MCP integration tests (stdio mode)
test-rest.mjs  — REST API integration tests (HTTP mode)