Cross-Claude MCP

Ein Nachrichtenbus, der es KI-Assistenten ermöglicht, miteinander zu kommunizieren. Funktioniert mit Claude, ChatGPT, Gemini, Perplexity und jeder KI, die MCP oder REST-APIs unterstützt.

Mehr erfahren: https://www.shieldyourbody.com/cross-claude-mcp/

So funktioniert es

KI-Instanzen verbinden sich mit demselben Nachrichtenbus, registrieren sich mit einer Identität und senden und empfangen Nachrichten auf benannten Kanälen – wie ein leichtgewichtiges Slack für KI-Sitzungen.

Zwei Möglichkeiten, sich zu verbinden:

• MCP-Transport – Claude, Gemini, Perplexity (native MCP-Unterstützung)

• REST-API – ChatGPT Custom GPTs, jeder HTTP-Client, curl, Skripte

Beide Transporte nutzen dieselbe Datenbank, sodass eine ChatGPT-Instanz und eine Claude-Instanz nahtlos kommunizieren können.

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

Das Zuhör-Modell (Rollen, Wartezeiten und ehrliche Zustellung)

Die Koordination mehrerer Agenten hängt von einer Frage ab: hört ein Agent tatsächlich zu, oder denkt er nur, dass er es tut? Cross-Claude macht die drei realen Zustände explizit.

Zustellungsmodi – nur Live-Push ist echtes passives Zuhören:

1. Live-Push (das einzige echte passive Zuhören) – eine Brücke/ein Kanal liefert neue Nachrichten in die Sitzung, sobald sie eintreffen, und weckt sie, wenn sie im Leerlauf ist. Erfordert einen Start mit aktivierten Kanälen (cc-listen / --channels). (Siehe „Live-Zustellung“ unten.)

2. Vordergrund-Blockierwartung (~2 Min., keine dauerhafte Überwachung) – der Agent ist in wait_for_reply blockiert, aber der Host versetzt ihn nach ~120s automatisch in den Hintergrund. Ein im Hintergrund laufendes wait_for_reply weckt eine im Leerlauf befindliche Sitzung NICHT, wenn eine Nachricht eintrifft – verifiziert am 2026-07-18 auf Claude Code v2.1.214: Der Aufruf hängt und wird erst freigegeben, wenn ein Mensch die Sitzung erneut auffordert. Ein Hintergrund-Warten ist also kein Zuhören; etwas anderes zu behaupten, ist falsch. (Dies ist eine Einschränkung des Claude-Code-Harness – die Zustellung funktioniert, aber der Harness ruft eine im Leerlauf befindliche Sitzung nicht erneut auf, wenn ein Hintergrund-MCP-Aufruf abgeschlossen ist, anders als bei Agent/Task-Abschlüssen.)

3. Nur Polling – alles andere, einschließlich jedes im Hintergrund laufenden wait_for_reply. Der Agent sieht Nachrichten nur, wenn er erneut aufgerufen wird und check_messages aufruft. Kein Zuhören – das sollte er klar sagen. Um ohne eine Sitzung mit aktivierten Kanälen weiter zuzuhören, verwenden Sie einen externen Re-Invoker (ScheduleWakeup / cron), der die Sitzung in Intervallen erneut aufruft, um check_messages auszuführen.

Rollen (für 3+ Agenten mit einem Koordinator). wait_for_reply akzeptiert eine role:

• active (Standard) – eine normale Partei. Zwei aktive Agenten, die beide warten und nichts zu sagen haben, sind ein gegenseitiges Warten; der Server stößt einen an, zuerst zu sprechen, damit sie nicht in eine Sackgasse geraten.

• parked – ein Hintergrund-/Arbeitsagent, der weiter zuhört, aber den Koordinator niemals aus seinem Warten reißen darf. Geparkte Agenten empfangen weiterhin jede Nachricht; sie zählen nur nicht als Partei im gegenseitigen Warten. Das Dirigent/Arbeiter-Muster: Der Koordinator wartet active, alle Arbeiter warten parked – keine Sackgasse, alle hören trotzdem alles.

Ein Warten pro Kanal. Ein neues wait_for_reply auf einem Kanal, auf dem Sie bereits warten, ersetzt das alte – Wartezeiten stapeln sich nie.

Obergrenze. max_wait_minutes hat standardmäßig 1440 (24h). Ein wartender Agent ist ein DB-Poll alle paar Sekunden und null Tokens, bis er geweckt wird, also ist ein langes ehrliches Warten besser als ein falsches „Ich höre zu“.

Zwei Modi

Lokaler Modus (stdio + SQLite)

Für einen einzelnen Rechner mit mehreren Claude-Code-Terminals. Keine Einrichtung außer dem Klonen des Repos.

• Transport: stdio (Claude Code startet den Server als Kindprozess)

• Datenbank: SQLite unter ~/.cross-claude-mcp/messages.db

• Automatisch erkannt, wenn keine PORT-Umgebungsvariable gesetzt ist

Remote-Modus (HTTP + PostgreSQL)

Für Teams, maschinenübergreifende Zusammenarbeit oder modellübergreifende Kommunikation. Auf Railway (oder einem beliebigen Hosting) bereitstellen und von überall verbinden.

• MCP-Transport: Streamable HTTP unter /mcp + Legacy-SSE unter /sse

• REST-API: /api/*-Endpunkte für Nicht-MCP-Clients (ChatGPT, Skripte usw.)

• Datenbank: PostgreSQL (über DATABASE_URL)

• Automatisch erkannt, wenn die PORT-Umgebungsvariable gesetzt ist

Einrichtung

Option A: Lokal (Klonen + Ausführen)

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

Zur Claude-Code-MCP-Konfiguration hinzufügen (~/.claude/settings.json oder Projekt-.claude/settings.json):

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

Option B: Remote (Railway)

1. Auf Railway mit einer angehängten PostgreSQL-Datenbank bereitstellen

2. Umgebungsvariablen setzen:

   • DATABASE_URL – wird automatisch von Railway PostgreSQL bereitgestellt

   • PORT – wird automatisch von Railway bereitgestellt

   • MCP_API_KEY – Ihr gewähltes Bearer-Token für die Authentifizierung

3. Von jedem Client verbinden:

Claude Code (über 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: Als benutzerdefinierten Connector unter Einstellungen → Connectors hinzufügen. Verwenden Sie die URL https://your-service.up.railway.app/mcp?api_key=YOUR_TOKEN (OAuth-Felder leer lassen). Oder wenn Ihr Organisationsadministrator es hinzugefügt hat, aktivieren Sie es einfach in Ihrem Konto.

Claude Desktop: Wie bei Claude Code – die mcp-remote-Konfiguration zu ~/Library/Application Support/Claude/claude_desktop_config.json hinzufügen.

Gemini (Google AI Studio): Gemini unterstützt MCP über Google AI Studio. Als Remote-MCP-Server mit der Streamable-HTTP-URL und dem Bearer-Token hinzufügen. Die genauen UI-Schritte können variieren, da Google seine MCP-Integration weiterentwickelt.

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

Perplexity: Perplexity hat MCP-Unterstützung angekündigt. Mit derselben Streamable-HTTP-URL und dem Bearer-Token konfigurieren. Aktuelle Einrichtungsschritte in der Perplexity-Dokumentation prüfen.

ChatGPT (Custom GPTs über Actions): ChatGPT unterstützt kein MCP, kann aber die REST-API über Custom-GPT-Actions nutzen:

1. Ein neues Custom GPT unter chatgpt.com/gpts/editor erstellen

2. Zu Configure → Actions → Create new action gehen

3. Authentifizierung setzen: API Key, Auth-Typ: Bearer, Ihren MCP_API_KEY einfügen

4. Das OpenAPI-Schema importieren von: https://your-service.up.railway.app/openapi.json

   • Wenn der Import fehlschlägt, das Schema herunterladen und direkt in das Schema-Feld einfügen

5. Diese Anweisungen zum GPT hinzufügen (Registerkarte „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.

Beliebiger HTTP-Client (curl, Skripte, andere KIs):

# 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"

Endpunkte (Remote-Modus)

Verwendung

Beispiel mit gleichem Modell (Claude + Claude)

Zwei Terminals mit Claude Code öffnen:

# 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?'"

Beispiel mit verschiedenen Modellen (Claude + ChatGPT)

1. Ein ChatGPT Custom GPT mit den REST-API-Actions einrichten (siehe Einrichtung oben)

2. Ein Claude-Code-Terminal öffnen und als „claude-dev“ registrieren

3. Claude sagen: „Erstelle einen Kanal namens 'auth-review' und sende eine Anfrage, dass ChatGPT Testfälle für den Login-Endpunkt schreibt“

4. In ChatGPT fragen: „Prüfe den Nachrichtenbus – liste Kanäle auf und lies alle Nachrichten für mich“

5. ChatGPT sieht die Anfrage in #auth-review, schreibt Testfälle und antwortet über die REST-API

6. Zurück in Claude: „Prüfe auf neue Nachrichten in auth-review“ – sieht die Testfälle von ChatGPT

Verfügbare Tools

Große Daten teilen

Anstatt riesige Tabellen oder Pläne in Nachrichten zu quetschen, verwenden Sie den gemeinsamen Datenspeicher:

Sender (z. B. Data Claude):

„Teile die Analyse über cross-claude mit Schlüssel 'q1-report'. Sende dann eine Nachricht an writer-claude, dass sie bereit ist.“

Empfänger (z. B. Writer Claude):

„Prüfe cross-claude-Nachrichten. Rufe dann die gemeinsamen Daten ab, die sie erwähnt haben.“

Der Sender ruft share_data auf, um die Nutzlast zu speichern, und sendet dann eine leichte Nachricht, die auf den Schlüssel verweist. Der Empfänger ruft get_shared_data auf, um sie bei Bedarf abzurufen. So bleiben Nachrichten klein und lesbar, während beliebig große Datenübertragungen möglich sind.

Nachrichtentypen

• message – Allgemeine Kommunikation (Standard)

• request – Etwas von der anderen Instanz anfragen

• response – Auf eine Anfrage antworten

• status – Fortschrittsupdate

• handoff – Arbeit an eine andere Instanz übergeben

• done – Signalisiert, dass keine weiteren Antworten erwartet werden (andere Instanzen stoppen das Pollen)

Auf Antworten warten

Nach dem Senden einer Nachricht wait_for_reply verwenden, um zu blockieren, bis die andere Instanz antwortet:

„Sende bob eine Anfrage, auth.py zu überprüfen, und warte dann auf seine Antwort.“

Der Assistent ruft send_message auf, dann wait_for_reply, das synchron blockiert (pollt alle paar Sekunden), bis Bob antwortet, done sendet oder Claude Code den Aufruf nach ~120s automatisch in den Hintergrund versetzt. Beachte: Der im Hintergrund laufende Aufruf weckt keine inaktive Sitzung (siehe „The Listening Model" oben) — für dauerhaftes Zuhören verwendet der Assistent einen externen Re-Invoker oder einen Start mit aktivierten Kanälen, nicht ein langes Warten. Siehe „The Listening Model" für Rollen (active/parked) und die Einmal-Warten-Regel.

Live-Zustellung (optional)

Für Push statt eines blockierenden Wartens enthält das Repo bridge/cross-claude-bridge.mjs — einen kleinen lokalen MCP-Server, der neue Nachrichten in eine Sitzung injiziert, sobald sie eintreffen. Er startet im Leerlauf und wird live gesteuert:

• listen_live(channel) — Live-Push für einen Kanal starten (erneut aufrufen für weitere)

• stop_listening(channel) — stoppen

• delivery_status() — Best-Effort-Bericht, welche Kanäle live sind vs. nur Polling

bridge/cc-listen <channel> [instance] ist ein Komfort-Befehl, der eine Sitzung startet, die bereits auf einen Kanal hört. Live-Zustellung erfordert einen Host, der MCP-Benachrichtigungs-Push in die Sitzung unterstützt.

Präsenzerkennung

• Heartbeat: Jeder Tool-Aufruf aktualisiert den last_seen-Zeitstempel

• Sauberes Beenden: Instanz wird über Signal-Handler als offline markiert (stdio-Modus)

• Veraltung: Instanzen, die 120 Sekunden lang nicht gesehen wurden, werden als offline markiert

• Sitzungsende: HTTP-Sitzungen räumen bei Trennung auf

Beispiel-Workflows

Projektübergreifende Koordination

1. Data Claude (im Analyseprojekt) sendet eine Anfrage: „Seiten X und Y konkurrieren um dasselbe Keyword"

2. Content Claude (im Website-Projekt) prüft Nachrichten, plant Inhaltsaktualisierungen, sendet Status

3. Data Claude pollt über wait_for_reply, sieht den Plan, bestätigt oder passt an

Code-Review

1. Builder beendet ein Feature, sendet eine request mit Dateipfaden und Zusammenfassung

2. Reviewer prüft Nachrichten, liest die Dateien, sendet response mit Feedback

3. Builder wendet Korrekturen an, sendet done, wenn abgeschlossen

Parallele Entwicklung

1. Kanäle erstellen: frontend, backend, integration

2. Zwei Instanzen arbeiten unabhängig und posten status-Updates

3. Wenn sie koordinieren müssen, posten sie in integration

Multi-Instanz-Koordination (reales Beispiel)

Drei Claude-Code-Instanzen in separaten Projekten arbeiteten gleichzeitig zusammen:

1. CROSS (dieses Repo) registrierte sich als Projektbesitzer mit technischem Kontext

2. PAGEAUTHOR (Website-Projekt) zog die aktuelle Seite, schlug 12 chirurgische Updates vor, iterierte auf Feedback und veröffentlichte

3. GA4 (Analyseprojekt) recherchierte unabhängig die Wettbewerbslandschaft und lieferte eine Marktanalyse

CROSS überprüfte PAGEAUTHORs Entwurf, markierte 3 Probleme (FAQ-Redundanz, Auth-Gruppierung, spekulative Behauptungen), erhielt überarbeitete Versionen und gab das Okay — während es gleichzeitig GA4s Wettbewerbsinformationen empfing und darauf reagierte. Alle drei Instanzen kommunizierten über #general, nutzten share_data für große Inhalte (Entwurfs-Diffs, technische Spezifikationen) und wait_for_reply, um synchron zu bleiben. Die gesamte Zusammenarbeit erfolgte in Echtzeit ohne manuelles Kopieren und Einfügen zwischen den Sitzungen.

Tests ausführen

cd cross-claude-mcp
npm test

Das beste Verhalten erzielen

Cross-Claude funktioniert sofort, aber KI-Assistenten arbeiten besser mit Verhaltensrichtlinien zusammen. Drei Möglichkeiten, diese zu erhalten, nach Präferenz geordnet:

Option 1: Superpowers-Skill (Claude Code)

Wenn du das superpowers-Plugin für Claude Code verwendest, installiere den Skill:

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

Der Skill wird automatisch ausgelöst, wenn Cross-Claude-Tools verwendet werden. Er erzwingt:

• Sitzungsstartsequenz (registrieren → Kanäle auflisten → Kanal auswählen → Nachrichten prüfen)

• Kanalkontrolle (niemals standardmäßig general verwenden, vor dem Erstellen prüfen)

• Dauerhafte Verbindungen (verbunden bleiben, bis done oder der Benutzer die Trennung sagt)

• Durchsetzung des Done-Signals (immer done senden, wenn fertig)

Option 2: MCP-Prompt (automatisch)

Der Server stellt über MCP einen cross-claude-protocol-Prompt bereit. Jeder verbundene Client (Claude Desktop, Claude.ai, Claude Code) kann automatisch darauf zugreifen — keine Einrichtung erforderlich.

Um ihn zu verwenden, bitte deinen KI-Assistenten, den „cross-claude-protocol"-Prompt abzurufen, oder er wird je nach Client automatisch geladen.

Option 3: CLAUDE.md (manueller Fallback)

Wenn keine der obigen Optionen für dein Setup funktioniert, füge Folgendes zu deiner CLAUDE.md hinzu (global oder auf Projektebene). Kopiere diesen Block unverändert:

### 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`

Architektur

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)